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.
@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