Hallo Team, Config-Anpassung zur Mongo-DB bei FER, OPD, JT und LMX Verantwortlicher: Stefan Rank-Kunitz Zeitpunkt: 31.10.2014 16:00Uhr, 02.11.2014 10:26Uhr Kunden: FER, OPD, JT, LMX Info: In den vergangenen Wochen haben wir teilweise drastische Probleme damit, dass die xRes-Livesysteme die MongoDB zu gewissen Stoßzeiten nicht erreichen können. Marcus' und meine Untersuchungen haben ergeben, dass zu diesen Zeiten (z.B. tgl. zwischen 15 und 17 Uhr) die CSV-MongoDB-Worker die von HBD gelieferten Daten in die MongoDB "prügeln" und diese damit aus-/überlasten. In der Folge kann der Buchungskern seine Logs nicht schnell genug in die MongoDB speichern und führt damit eine recht hohe Anzahl aller Buchungskern-Anfragen ins Timeout. * Als ersten BugFix sitzt Marcus derzeit TÄGLICH davor und startet die CSV-Worker manuell nacheinander. Das ist kein Dauerzustand und bedeutet einen extrem hohen manuellen Aufwand, auch am Wochenende!!! * Als zweiten BugFix habe ich am Freitag in den genannten Kundensystemen wieder die Mongo08 UND die Mongo07 eingetragen, so dass der Buchungskern dynamisch zwischen 2 Mongos wählen und damit das Last-Problem lindern kann. Eine LÖSUNG ist das nicht, Freitag-Abend und Samstag haben gezeigt, dass das Problem weiterhin besteht. * Als dritten BugFix habe ich das MongoDB-Logging des Buchungskerns bei LMX und JT soeben deaktiviert. Nachdem ich in der Minute 10:25Uhr eben über 50 BAs mit runTime > 10 Sekunden gesehen habe ... und um 10:27 Uhr (nach der Deaktivierung) noch 4 sollten wir das auch vorerst so lassen! @Admin: Dieses Problem tritt seit etwa 3-4 Wochen massiv auf. Ich bitte Euch DRINGEND zu untersuchen, ob ggf. ein Hard- oder Konfigurations-Problem eine Ursache für die plötzliche Eskallation des Problems sein kann. Seht Ihr z.B. IO-Waits oder Netzwerk-Überlastungen oder oder oder oder ..., welche eine Ursache für das plötzliche Eintreten sein können? @Oliver: Bitte untersuche schnellstmöglich den Aufwand, die Mongo-Logs des Buchungskerns auch auf die RabbitMQ umzustellen und damit keine Antwort von der Mongo zu benötigen!!! Ist es realistisch, die Mongo-Logs des Buchungskerns einfach an die Rabbit zu schieben und keine Antwort von dort (oder gar von der Mongo) abzuwarten? @Marcus: Was würde die RabbitMQ dazu sagen, eine Masse an Requests und Responses aus dem Buchungskern übergeholfen zu bekommen? Ist dieser Umbau mit unserer aktuellen Struktur möglich / sinnvoll? VG SRK -- Mit freundlichen Grüßen Stefan Rank-Kunitz - Lead Developer - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 909 87 45 E-Mail: s.rank-kunitz@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850
Hallo Stefan, danke für Deine Analyse und Zusammenfassung. @Marcus, danke auch für Deine operative Unterstützung. Aus meiner Sicht ist der Vorschlag das Logging asynchron über die Rabbit-MQ zu machen ein sehr guter Ansatz. - Das Logging darf nicht die Ursache für operative Performance Probleme sein - Außerdem muss das Logging dauerhaft und stabil funktionieren, da wir dieses für aktuelle Problemanalysen brauchen. - Es ist kein nice to have, sondern ein Feature, welches wir dringend sogar in noch größerem Umfang benötigen - Insbesondere vor dem Lastanstieg im Januar, müssen wir das Thema spätestens mit der 2.2.6 lösen. Eine weitere Option der Entlastung sehe ich in der Reduzierung der HBD Last - LMX hat 2.822 HBD Hotels auf erledigt o Aber 4.625 mit Preisen - JT hat 5.906 HBD Hotels auf erledigt o Aber 7.086 mit Preisen o > 1.100 Hotels mit Preisen und einem Status <> erledigt oder Nullverkauf - Wobei dies nur ein kleiner Teil sein kann. Mit freundlichen Grüßen Haiko Gerdes - Geschäftsführer - ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 7 418 // Fax: +49 341 90 98 749 Mobil: +49 172 610 2849 Internet: http://traso.de E-Mail: h.gerdes@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 Von: Hotfix [mailto:hotfix-bounces@lists.traso.de] Im Auftrag von Stefan Rank Kunitz Gesendet: Sonntag, 2. November 2014 10:36 An: hotfix@lists.traso.de Betreff: [Hotfix] massive MongoDB-Probleme, Config-Änderung Hallo Team, Config-Anpassung zur Mongo-DB bei FER, OPD, JT und LMX Verantwortlicher: Stefan Rank-Kunitz Zeitpunkt: 31.10.2014 16:00Uhr, 02.11.2014 10:26Uhr Kunden: FER, OPD, JT, LMX Info: In den vergangenen Wochen haben wir teilweise drastische Probleme damit, dass die xRes-Livesysteme die MongoDB zu gewissen Stoßzeiten nicht erreichen können. Marcus' und meine Untersuchungen haben ergeben, dass zu diesen Zeiten (z.B. tgl. zwischen 15 und 17 Uhr) die CSV-MongoDB-Worker die von HBD gelieferten Daten in die MongoDB "prügeln" und diese damit aus-/überlasten. In der Folge kann der Buchungskern seine Logs nicht schnell genug in die MongoDB speichern und führt damit eine recht hohe Anzahl aller Buchungskern-Anfragen ins Timeout. * Als ersten BugFix sitzt Marcus derzeit TÄGLICH davor und startet die CSV-Worker manuell nacheinander. Das ist kein Dauerzustand und bedeutet einen extrem hohen manuellen Aufwand, auch am Wochenende!!! * Als zweiten BugFix habe ich am Freitag in den genannten Kundensystemen wieder die Mongo08 UND die Mongo07 eingetragen, so dass der Buchungskern dynamisch zwischen 2 Mongos wählen und damit das Last-Problem lindern kann. Eine LÖSUNG ist das nicht, Freitag-Abend und Samstag haben gezeigt, dass das Problem weiterhin besteht. * Als dritten BugFix habe ich das MongoDB-Logging des Buchungskerns bei LMX und JT soeben deaktiviert. Nachdem ich in der Minute 10:25Uhr eben über 50 BAs mit runTime > 10 Sekunden gesehen habe ... und um 10:27 Uhr (nach der Deaktivierung) noch 4 sollten wir das auch vorerst so lassen! @Admin: Dieses Problem tritt seit etwa 3-4 Wochen massiv auf. Ich bitte Euch DRINGEND zu untersuchen, ob ggf. ein Hard- oder Konfigurations-Problem eine Ursache für die plötzliche Eskallation des Problems sein kann. Seht Ihr z.B. IO-Waits oder Netzwerk-Überlastungen oder oder oder oder ..., welche eine Ursache für das plötzliche Eintreten sein können? @Oliver: Bitte untersuche schnellstmöglich den Aufwand, die Mongo-Logs des Buchungskerns auch auf die RabbitMQ umzustellen und damit keine Antwort von der Mongo zu benötigen!!! Ist es realistisch, die Mongo-Logs des Buchungskerns einfach an die Rabbit zu schieben und keine Antwort von dort (oder gar von der Mongo) abzuwarten? @Marcus: Was würde die RabbitMQ dazu sagen, eine Masse an Requests und Responses aus dem Buchungskern übergeholfen zu bekommen? Ist dieser Umbau mit unserer aktuellen Struktur möglich / sinnvoll? VG SRK -- Mit freundlichen Grüßen Stefan Rank-Kunitz - Lead Developer - ________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 Leipzig Tel.: +49 341 909 87 45 E-Mail: s.rank-kunitz@traso.de Internet: http://www.traso.de ________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850
participants (2)
-
Haiko Gerdes -
Stefan Rank Kunitz