TM1 Performance verbessern: Warum mehr RAM selten die richtige Antwort ist

Dein TM1-System wird langsamer. Jedes Jahr spürbar mehr. Die naheliegende Antwort: mehr RAM, stärkere Hardware, neuer Server. Manchmal stimmt das. Meistens nicht.

Bevor du in Infrastruktur investierst, lohnt sich ein anderer Schritt zuerst: zu verstehen, wo dein System eigentlich Zeit verliert.

Warum die meisten TM1-Performance-Probleme keine Hardware-Probleme sind

In zehn Jahren TM1-Beratung haben wir Dutzende von Performance-Analysen gemacht. Das Ergebnis ist erstaunlich konsistent: In etwa 80 Prozent der Fälle liegt das Problem nicht in der Hardware. Es liegt in einer dieser drei Stellen:

• Einzelne TI-Prozesse, die unbemerkt länger laufen als sie müssten. Oft, weil sie historisch gewachsen sind und nie optimiert wurden.
• Cubes, in denen sich Daten auf irrelevanten Koordinaten stapeln. Versionen, die längst veraltet sind. Szenarien, die niemand mehr nutzt.
• Rules, die rechenintensiver sind als notwendig, weil sie auf Aggregaten arbeiten oder unnötige Lookups machen.

Der gemeinsame Nenner: Du siehst diese Probleme nicht ohne Daten. Wer rein nach Bauchgefühl optimiert, kauft am Ende neue Hardware. Wer mit Daten arbeitet, optimiert die richtigen Stellen und spart oft Zehntausende Euro Infrastrukturinvestment.

Drei Ebenen, auf denen du TM1 Performance verbessern kannst

Performance-Optimierung im TM1 lässt sich in drei klar getrennte Ebenen einordnen. Jede hat eigene Hebel und eigene Werkzeuge. Wer sie verwechselt, optimiert an der falschen Stelle.

Ebene 1: Prozess-Performance

Hier geht es um die Laufzeit einzelner TI-Prozesse. Forecast-Läufe, Konsolidierungen, Datenexporte. Diese Prozesse laufen oft nachts und niemand schaut drauf, solange das Reporting morgens da ist.

Typische Ursachen für schleichende Verschlechterung: Datenmengen wachsen, ohne dass der Prozess das berücksichtigt. Logiken werden über Jahre erweitert, ohne sie zu refaktorieren. Abhängigkeiten zu anderen Prozessen schleifen sich ein.

Was du brauchst: Laufzeitprotokolle. Für jeden Prozess: wann gestartet, wie lange gelaufen, mit welchen Parametern. Über Wochen oder Monate hinweg. Erst dann siehst du Trends.

Ebene 2: Cube-Performance

Hier geht es um die Datenstruktur im System. Wie viele Daten liegen wo? Welche Cubes sind wirklich groß? Wo sind die meisten Werte konzentriert?

Klassisches Muster: Ein Forecast-Cube hat 10 Versionen, davon werden zwei aktiv genutzt. Die anderen acht belegen RAM und verlangsamen Aggregationen. Niemand löscht sie, weil niemand sicher ist, ob sie noch gebraucht werden.

Was du brauchst: Übersicht, wo Daten liegen. Ein eigener Analyse-Cube, der Datenmengen pro Cube und pro Schlüsseldimension darstellt. Damit identifizierst du Optimierungskandidaten in Minuten.

Ebene 3: Rule-Performance

Die Ebene mit dem höchsten Hebel und der höchsten Komplexität. Eine ungeschickt geschriebene Rule kann ganze Cubes ausbremsen, weil sie bei jedem Wertabruf rechnen muss.

Typische Probleme: Rules, die auf Konsolidierungselementen arbeiten statt auf Blättern. Lookups in andere Cubes ohne Caching. Geschachtelte IF-Konstrukte, die linear langsamer werden mit Datenmenge.

Was du brauchst: Rule-Trace-Tools, die zeigen, welche Rules wie oft ausgeführt werden. Plus die Disziplin, vor jeder Änderung an Rules ein Performance-Vorher-Nachher zu messen.

So findest du Performance-Engpässe in unter einer Stunde

Bevor du an Optimierung denkst, brauchst du Datentransparenz. Hier der Weg, den wir bei Kunden gehen, wenn das System spürbar langsamer geworden ist:

1. Standardisiertes Prozesslogging einführen, falls noch nicht vorhanden. Jeder TI-Prozess schreibt: wann gestartet, wer hat ihn gestartet, mit welchen Parametern, wie lange gelaufen, mit welchem Ergebnis. Aufwand: 1 bis 2 Tage. Das ist die Basis für alles weitere.
2. Laufzeitdaten der letzten 30 Tage auswerten. Welche Prozesse laufen am längsten? Welche werden am häufigsten ausgeführt? Welche sind beide? Das sind deine Top-Optimierungskandidaten.
3. Datenscan für die zwei oder drei größten Cubes. Wo liegen die Daten? Welche Versionen, Szenarien, Abteilungen sind aktiv, welche tot? Hier findet man oft 10 bis 30 Prozent RAM-Einsparung in einer Stunde.
4. Rule-Performance über TM1 Operations Console oder Server-Logs nachvollziehen. Welche Rules werden am häufigsten getriggert? Sind sie effizient geschrieben? Diese Prüfung braucht Erfahrung, der Hebel ist aber groß.
5. Erst dann über Hardware nachdenken. Wenn du Punkt 1 bis 4 sauber gemacht hast und das System immer noch langsam ist: dann hast du jetzt die Datenbasis, um eine fundierte Hardware-Entscheidung zu treffen. Wahrscheinlich ist sie kleiner, als du gedacht hättest.

Wie das in der Praxis aussieht

Ein Industriekunde kam 2024 mit einem klaren Auftrag: „Wir brauchen mehr RAM, das System ist zu langsam.“ Bevor wir Hardware bestellt haben, haben wir zwei Tage in Logging und Datentransparenz investiert.

Das Tool dahinter heißt bei uns Prozesslogging. Es ergänzt jeden TI-Prozess um eine standardisierte Logzeile. Aufwand: 2 Tage Implementierung, danach automatisch.

Die Auswertung nach 14 Tagen brachte:

• Ein Forecast-Prozess, der seit Monaten von 8 auf 35 Minuten gewachsen war. Ursache: ein Subset, das jede Nacht neu generiert wurde, obwohl es sich kaum geändert hat. Optimierung: 30 Minuten Aufwand.
• Drei Cubes mit Datenleichen. Versionen aus 2019, die niemand mehr brauchte. RAM-Einsparung nach Bereinigung: 12 Prozent.
• Eine Rule, die bei jeder Reportabfrage über 50.000 Zellen rechnete, weil sie unnötig auf einer höheren Aggregationsebene operierte. Nach Refactoring: 70 Prozent schnellere Reports.

Ergebnis: keine Hardware-Investition nötig. Das System läuft schneller als vor zwei Jahren. ROI des Logging-Tools im ersten Jahr: rund 284 Prozent. Plus die nicht getätigte Hardware-Investition, die war noch gar nicht eingerechnet.

Fazit

TM1 Performance zu verbessern ist selten ein Hardware-Thema. Es ist meistens ein Datentransparenz-Thema. Solange du nicht in Zahlen sehen kannst, wo dein System Zeit verliert, optimierst du im Nebel. Mit Logging und gezielten Cube-Analysen findest du die echten Engpässe in wenigen Tagen. Die Optimierung selbst ist dann oft der kleinere Aufwand.

Wer ohne Datenbasis Hardware kauft, löst das Symptom, nicht die Ursache. Und kommt drei Jahre später mit demselben Problem wieder.