Hallo Team. Hier mal ein kleiner Hinweis zu den in der XresConfig konfigurierbaren parallelen Abarbeitungen von bestimmten Xres-Prozessen. zum Beispiel die cache-Berechnung: XresConfig/COMPONENTS/INFX2CACHE/PAC2CACHEMAXTHREADS oder infx-Export: XresConfig/COMPONENTS/INFX2CACHE/CACHE2FILEMAXTRHEADS Allgemein herrscht ja die Einstellung, dass sich die maximal mögliche parallele Verarbeitung an die Verfügbaren CPU-Kernen geknüpft ist. Das ist aber nicht ganz richtig. 1. Es laufen auch andere Prozesse auf den Servern. Ein großes Problem ist mir bei den cache01 Servern aufgefallen. Dort läuft neben der xRes-Software auch die MySQL Datenbank. Wenn die cache-Berechnung alle oder zu viele CPUs nutzt, wird die MySQL Performance negativ beeinflusst. Zur Zeit bin ich dabei, diesem Umstand den vielen "Lock wait timeout exceeded" Fehlern von MySQL zu zuschreiben. Ein Test bei JT läuft gerade. Dort habe ich heute die Anzahl der parallel arbeitenden p2c Prozesse auf 17 runter gestellt. 2. Speicherauslastung Ein noch größeres Problem ist die Speicherauslastung. Bei Systemen, wie FER und FOR ist aufgefallen, dass es durchaus umfangreiche Hotels gibt, die an die 10GB und mehr Speicher benötigen. Dieser Speicher ist bei zu vielen parallel arbeitenden Prozessen schnell aufgebraucht. Dann kann es zu folgenden Effekten kommen. 2.1 Swap: Die Prozesse fangen an ihre Arbeit auf die Platte auszulagern, anstatt den viel schnelleren Arbeitsspeicher zu nutzen, denn der ist ja aufgebraucht. Prozesse wie MySQL, die ständig laufen verbleiben in diesem Modus auch wenn sich die Lage Später beruhigt. 2.2 OOM-Killer. Dieses System-Tool beendet Prozesse, wenn absolut kein Speicher mehr zur Verfügung steht. Dabei wird kein Unterschied zwischen Gut und Böse gemacht. Diesen Umstand hatten wir schon des öfteren auf den cache Servern, wo dann die MySQL Instanz beendet wurde und somit die Datenbank nicht mehr verfügbar war. Fazit Die Einstellung für die parallelen Abarbeitungen ist ziemlich kritisch und sollte nicht auf die leichte Schulter genommen werden. Die oben beschriebenen Effekte sind nicht vorhersagbar und können ganz untypisch zu den angesprochenen Änderungen auftreten. Leider gibt es aber auch Software-Bestandteile die nicht besonders effektiv bis ... naja umgesetzt sind. Die diesen Umstand verstärken. Wir arbeiten daran. @ALL Bevor solche Änderungen gemacht werde, bitte mit dem betroffenen Entwickler absprechen. -- -- Sören Pestner - Entwickler - TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig telefon: +49 341 909 87 509 email: s.pestner@traso.de Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850)
participants (1)
-
Sören Pestner