-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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=apache
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
- -- 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) iQIcBAEBAgAGBQJTQqBgAAoJEFfjOJdKpi1E9FYP/0hQqalFfcXrb3BtGe39tbUl jgLdU3+WMCxqwM4v8/xoOfbYAMQR7+tt6K8901zZ6j3PsIbnBKpHx8Lpjy3+QOcW zwI50fhQM/kVOfxpxtGLgpMg0Mjenjvt758Jpkasc45g6jz+zCVq5A30ye44UEL4 /+gxTRj3NZVCcOmWNfAnTUherKLD75GIisUl0azj+iEYUrC/ewGmUiylTzSJTOzd IfdRp2hdblgObVOW5l7kjvCgFRJ4w71v9sSr0/3nbSUrqMIn5EvKRjWm7pgGSu+G 39R/eyNKjkdRbDb3Zh3+cLQYoOkU1g873s1EZXn2W2TyoYkzMiSGRO19ygPPVFwA uWugEd/SFym2UOGWbiohvlBAoywApvSFT0exHYn+s+Xd7HNVHbO3rBPXwhEfMASX mYoGMYajhhEhSM6ypwOw0TuXrYr+G4JhUIUqFZbGsC185NawP3hEu9jKNXoOhNLH DX0KPOW5Ds1ol1vfNP2Uum3NT65ELeppzaoegerxujNppUXw9LNiZPLXgCF3Qdq8 XRu1zTOkh8WjuOgOumXOCOMQQlpB24t+YwPhsmXSE1lIeVmzo9vFVkqlP07equCe yvMhYARMGuj8ydqL0pM7cBZzq+zlYhjWhthXdz7DJn9iopqy7ZRhxoTNMgALU+sa PVOS3XNvVohjEFdJlSwz =Tq1M -----END PGP SIGNATURE-----