Hallo Tilo, ja Omid weiß Bescheid. 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 -----Ursprüngliche Nachricht----- Von: team [mailto:team-bounces@lists.traso.de] Im Auftrag von Tilo Werner Gesendet: Dienstag, 8. April 2014 18:13 An: team@lists.traso.de Betreff: Re: [Team] Umstellung DB-Server JT (war: Unserer Besuch im Rechenzentrum und was danach geschah...) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, das Slave-Setup läuft prinzipiell, mir sind noch ein paar Kleinigkeiten aufgefallen, die aber nicht so entscheidend sein sollten. Dazu gehört, dass in der Replikation das Schema xres_jt_logbook ausgenommen ist und wir somit morgen ein frisches/leeres Schema einspielen (mit ksp abgesprochen). Falls das nicht reichen sollte, können wir das von dem dann alten Master ggf. einspielen (TABLE_LOCK - -> Downtime?). Matthias hat den RAM im 2. Anlauf erfolgreich halbiert, wir hatten die korrekte Modulreihenfolge nicht beachtet. Wir (spe & ich) starten morgen schon um 06:00 Uhr und hoffentlich sind wir schnell durch. @Haiko Omid weiß Bescheid, oder? Drückt die Daumen und bis morgen, Tilo Am 07.04.2014 14:56, schrieb Tilo Werner:
Hallo zusammen,
nach den Tests, die sich noch bis Freitag ausdehnten, werden ich heute den db03.jt als Slave an den produktiven Master db01.jt hängen. Morgen Nachmittag werden Matthias und ich 64GB RAM ausbauen, da wir festellten, dass die z.Zt. verbauten 128GB nicht ansatzweise von xRes ausgenutzt werden. Der produktive db01.jt hat z.Zt. 32GB.
Am Mittwoch zwischen 07:00 und 08:00 Uhr wird dann der db03.jt als Master eingesetzt.
@Entwicklung: Einer von euch sollte bitte anwesend sein. @Support: Bitte sagt dem Kunden Bescheid.
Nächste Woche Mittwoch nach dem Meeting werde ich dann allen Entwicklern, Admins und min. einem Supporter den bisherigen Kenntnisstand und unser Vorgehen mitteilen. Hierzu gibt es noch eine seperate Mail. Die Teilnahme ist obligatorisch.
lg, Tilo
Am 04.04.2014 08:14, schrieb Haiko Gerdes:
Hallo Tilo,
danke für Deinen Einsatz und Deine Zusammenfassung.
Aus meiner Sicht ergeben sich da 3 Ergebnisse: 1. Der Airbis Import ist ca. 2 mal so schnell - das kann ja so schlecht nicht sein - Ist vermutlich auch auf andere Bereiche, wobei möglicherweise nicht auf alle, zu übersetzen
2. Der BA-Lasttest - Wie haben trotz Deines Einsatzes es nicht geschafft ein Ergebnis zu erzielen - Komplexität offenbar noch nicht geknackt
:=> Hier müssten / sollten wir noch einmal überlegen, wie wir das Testszenario anpassen können, um zu Ergebnissen zu kommen, insbesondere für die Zukunft
3. Ansätze für Optimierungen - Es gibt verschiedenen Ansätze, in denen Optimierungspotential für die Zukunft liegt, wobei diese im Wesentlichen in der Applikation zu liegen scheinen
Summary: - Ich sehe keine Gründe gegen einen Livegang - Außer dem positiven Ergebnis bei Airbis und dem Fehlen von Problemen/Hinderungsgründen, gibt es aber auch nichts was für/gegen den Einsatz spricht - Ich habe einige Ansätze herausgelesen, die sich möglicherweise lohnen, in einem zweiten Schritt untersucht zu werden, insbesondere der Aufgabe ein solches Testszenario möglich zu machen.
Dir Tilo, viel Spaß beim Wühlen Uns bleibt dann wohl der Montag für weitere Überlegungen und dem Treffen der finalen Entscheidung.
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
-----Ursprüngliche Nachricht----- Von: team [mailto:team-bounces@lists.traso.de] Im Auftrag von Tilo Werner Gesendet: Freitag, 4. April 2014 03:43 An: team@lists.traso.de Betreff: Re: [Team] Unserer Besuch im Rechenzentrum und was danach geschah...
Hallo zusammen,
wir haben heute einige Beispiele wie im Live-Betrieb bei JT getestet:
* Sejour/HSTO Import (spe) * Airbis & Sunexpress Import (swi) * BAs (srk)
Zum Sejour/HSTO Import fehlt noch die letzte Aussage, für Airbis läßt sich vorsichtig sagen, dass er unter diesen Umständen doppelt so schnell war (von ca. 7h auf etwas über 3h).
Bei den BA-Abfragen komme ich nicht auf den Punkt. Getestet wurde auf dem test02.jt.
0. Habe ich fast alle Cron-Jobs deaktiviert (dort gibt es eine root Crontab! WTF) 1. Das Script von SRK habe ich analytisch zerlegt 2. Habe ich eine einzelne Abfrage (SQL) extrahiert, die mir eine gültige Antwort gibt (B möglich) 3. Habe ich dieses SQl-Statement mit unterschiedlichen PHP-Methoden abgefeuert (mysql_connect, mysqli) 4. Habe ich ein PHP-Script entworfen, welches nur "SELECT 1" gegen die DB wirft (mysql_connect) 5. Habe ich das Ganze aus Verzweiflung in fcgi gepackt (was immerhin den Load vom Apache gemildert hat) 6. Bin ich nicht auf zuverlässige Testszenarien gekommen! 7. Bei alldem hat der DB-Server müde gelacht, sprich er war nicht ansatzweise ausgelastet!
Meine Testkonfig liegt auf dem *test02.jt*.
-> /etc/apache2/sites-enabled/sqltest -> /var/www/sqltest/htdocs
Desweiteren habe ich eine Test-VM (sqltest) in der GS etabliert, welche mit Debian Wheezy (PHP5.4) läuft und meine entworfenen Scripte gegen den devil-b.gs.traso.de geworfen. Dort läuft der "ab" (Apache Bench) relativ zuverlässig, bringt den DB-Server zwar zum Schwitzen (Load), aber die Leistung ist mittlemäßig im Vergleich zu den syntetischen Test bzw. dem SQL-Import.
Letzlich bin ich entäuscht, die Test auf dem test02.jt warfen Kernelwarnings "nf_conntrack: table full", d.h. der will keine Connects mehr, daraufhin habe ich alle Register gezogen [1]. Auch das half nichts gegen die schwankenden Ergebnisse.
Auf diesem System kommt man damit auf keine stabilen Ergebnisse. Der Apache geht quasi grundlos in den Wait-Status und der DB-Server macht nichts. Sieht man auch schön im Collectd [2].
*Erschreckend* ist aber die Feststellung, dass trotz der Angabe von localhost in den PHP-Scripten (DB Parameter) auf dem test02.jt der db03.jt angesprochen wird (sieht man u.a. in iftop). Das ließ sich nur durch eine geschickte Manipulation der /etc/hosts (wieder kommentiert) ausgeleichen, aber auch dann sind die Ergebnisse nach mehreren Durchläufen divergent.
Ebenso *fürchterlich* ist die Tatsache, dass während der Test Nagios mehrere Host Down (Flapping) Meldungen verschickte!
Ich habe unsere heutige tmux-Session auf dem test02.jt benutzt und dort kann man auch meine Tests nachvollziehen.
Fazit:
* Entweder wir haben im RZ massive Netzwerkprobleme oder * die PHP-Konfiguration auf dem test02.jt ist völlig durcheinander oder * Kernel 2.6.32 bringts nicht oder * PHP 5.2 ist nicht geeignet für meine Scripte oder * PHP ist allgemein nicht geeignet für DB-Benchmarks
*oder*
Alles gleichzeitig....
Grüße, Tilo
PS: Wer bis hierher gekommen ist, weiß nun auch, dass ich morgen meine Hände in Mutter Erde stecke, für Rückfragen bin ich aber per Telefon/Mail erreichbar.
[1] http://blog.sam-pointer.com/tag/nf_conntrack:tablefull,droppingpacket
[2] http://collector.gs.activate.de/cgp/host.php?h=test02.jt.xres.de&p=ap ache
Am 03.04.2014 00:46, schrieb Tilo Werner:
Hallo,
nachdem heutigen Besuch im RZ mussten Matthias und ich unseren familiären Pflichten nachkommen, weswegen wir anschließend nicht nochmal in der Firma waren.
Der db03.jt, welcher nach unseren Tests dann hoffentlich der db01.jt wird, ist eingebaut, auch hat Matthias zwei Nodes des c2 (Dell C600) vollständig aufgerüstet. Namentlich vmhost-c21 & 22
Ich habe noch das Netzwerk des db03.jt konfiguriert, wobei mir ein Fehler unterlaufen ist!
Zwischen ca. 23:08 und 23:58 Uhr war das gesamte 85.239.120.128/27 Netzwerk nicht erreichbar. Zu meinem Glück tummeln sich dort hauptsächlich Systeme, welche um die Uhrzeit nicht gebraucht werden (_ticket.mailmanager.de_, _mx1.mailmanager.de_, _hlweb0*.vna.de_, _lts-international.com_, _*.traso.de_). Der *service01.lts* gehört sicherlich nicht dazu, auch waren anderer Kunden Testsysteme und unserer VPN-Punkt im RZ betroffen. Genaueres kann ich morgen erläutern.
Abgesehen von diesem verheerenden Malheur, bin ich froh, dass der Datenbankserver morgen bereit ist für eure Tests.
Grüße, gute Nacht und bis morgen früh, Tilo
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
_______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
- -- Mit freundlichen Grüßen Tilo Werner - - Systemadministration - _______________________________________________ TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig E-Mail: t.werner@traso.de Internet: https://www.traso.de _______________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJTRCAeAAoJEFfjOJdKpi1E+iQP/1gfplcPwA7lN8dwupPRCb+v 3sTQLl98JMwn1txxaDxuknzMIKhmNknrMj67RnMhZ8MkMEGDf43Bv21TREpzODhd 1w3WAEzhbD9300tHMtVmaf3qsZ4EwsNSQkXGUkJVmc3WNx0fK1jTeDL4uEMkOJz+ NY+je3TLSVxjQHBD69VSP9/gmJ+UNmmvXdVCcHn+knShI7oWJ8Q2mLbWMK0Qweus PZJqaPfKPj5hh+hElyS0s1MMLchPv/3r7I4v/mSffcqPUKKeB/QRvz7rGM+gwEvV jFaMJqLqmKkxci48lvKq5BXrkNowE3VsxuQQuY6UwvQgnstPZEnf6egQyfWlIGEn CkMixQjei2VeVrSl8I8meqyzAc52SA5NFG8iX5p7hHZvHsTBZUT1WsAbvPG4tBTn CucKdKVPKmrRuLIT670kd7E0Z633Zb2L5goaeFBFHpEMBDygE7EieU6K5uAm3KyG bqJqnVditTxmzSPOxtc5zk8ngR+hDwdBcz8v/P2qRfXFCLna/XHZDqR7WALpRTDl CAKamiQpPsykeb98qyV2arjxehPBdUtqf9SiPGv+4yOmhcU2nt4wjrmRtayA5xxx Ft/6braZKBrDqBV5ytvOkj7fSP+hEppLj2luteGm2o48ay1/pvCBHQ7WD2kdTSLY xgyvWpOLQ/F59faTKbVZ =3Qow -----END PGP SIGNATURE----- _______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team