-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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
- -- 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) iQIcBAEBAgAGBQJTPg4nAAoJEFfjOJdKpi1EjiYP/1SDC+cUO960d49/yxjHUmZl mO005LFN5QIjJWdIKv37ykqvFAmQu6dXUne4neNsyhNIJJr3tFbhi3lEkBLFVcak Yb+TtJVdLbXfvthfGsSlMSnI4RBP4N10msGwfU0fwC3p9CvZZflphMB0s9ooif8D GaLhEadWi07BTqaCADzTIpRpDGwCDS+HdgoEPoyXQX1M6y6vKT/bcwQWpz0JzxZ3 EXUh/28E2uhpiNXw4bjLnWDuWh46dwYvjqJdSOi7fbB0zwDtlMF4vLJZroU/rCZb vKb91z8+TRj3ithcrO95yYr37nU9nc2rsENNELawEnouXZw4nLDK5N9Txk54j0HC Q1wNq9jDQf42sGQ/NHD+8ZtH0WqX5gsR+jaZr1p4fC7A9ByQNhY1WOrj2hMUoNkD 5OC/7HzXvLb5CCXAfXGvwNWv4kKGH8d2TWlUd92p7e4Gk8sd/Y+WuX9N7Xu7LgQI KcpJIUCCu01VzBxdkCjb6D9y9B1YEQ94ZzXE1wbefrmb7zc2Kpozd9kiUt09KMsx Ie3YZ5G0B7ZsHMLB3CchocXlzqk/YO8YYC6VOy62tYqrfT2yylw6C2COjVDztM5L mMJc2Dck5LXzQYzv3CTrm0gf7jfI5jCDtcGnwZUvTwpCdZIJ/6PA78mAcExHjXaf r0rZLiT9/16dIlK8hSSY =31qR -----END PGP SIGNATURE-----