-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- 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) iQIbBAEBAgAGBQJTPJNZAAoJEFfjOJdKpi1EUUoP90/rCkSdggoIdVG97rdG+zGM uyWpyXY2jCOpWcwAbUPQBfigmc+ki/PI7gG68USxCMlQE6jUOxQr2qYUWhlT9HRx aebwts6zzcKPsjMdW9KrVzRhUr5wBWDQLX/OPEssIHp+5tf9LtMosCuhA+DUCW0D mlRfKGOJ0lPmt57AV9FqKPWH5TZtRMnsV0CLBfB/lnDbxro5pFng181OhWUPe9M4 RuvHcVPhMWoSU/ufMDNvaMhC3Cd0KQaMfuaWvt5ec2MwyXpoFgerv3Ab3jnE4yDZ MlDhF0BoD7L9UO4QpnmWbZgrP5Rpgm8//17A9cL8PffRLKPuotQ4O+37ZLO0gtpO QE4XnaNUfXc4GvCPvuBsA7nGrCmDcadxsXQD8VOiMngdocKgmeXiQR7ufAYQsb8o WcbXXzyZTgUdppBWfo1E8qT2pE39YfIV2t9vXOdGDjNLVXG8iywtdC+JOL0VX5sf LzOLvjrFxSaP/vReXLWcAjp0vFVSdf4UeGqAIzx7hXC4Q+6G/D9sqfFIMWTRC5tE wLos5rL6cp0Bp3M61QeQbJPPkHS4EvebANa01hGcAF6Zu5F7TLCRR+DLUefKEfZw 8U2WNUj7bwz5UTvdniAL/TopS3cp+7UTuaIUR9X3+aK/q0OneQjqze8aGkVvPDrq 5/9jQTKmJdSzPeH04XU= =QGw7 -----END PGP SIGNATURE-----
-----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-----
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... -----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----- _______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
-----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-----
Hallo Tilo, danke für die Info. - Ich informiere Omid - der wartet schon so lange :-) 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: Montag, 7. April 2014 14:56 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 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=apa che
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----- _______________________________________________ team mailing list team@lists.traso.de https://lists.traso.de/listinfo/team
-----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=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
_______________________________________________ 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-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo zusammen, Sören und ich haben heute gegen 06:15 Uhr mit der Umstellungen begonnen und diese 07:45 abgeschlossen. Der alte db01.jt war von ca. 06:30 bis 07:00 Uhr und ein zweites Mal von ca. 07:20 bis 07:40 Offline. Im ersten Schritt haben wir sämtliche Cron-Jobs angehalten, das xres_jt_logbook Schema exportiert und in den neuen importiert. Dann haben wir den alten MySQL-Server angehalten, den neuen via Chef in db01.jt umbennant und ihm die MySQL-Rolle als Master gegeben. Danach haben wir alle DNS-Einträge der beiden getauscht d.h. - - db01.rz1.jt.xres.de löst nun nach 10.21.3.14 auf - - db03.rz1.jt.xres.de löst nun nach 10.21.3.8 auf Der MySQL-Server auf dem alten (nun db03.jt) wurde mit bind-address 127.0.0.1 wieder gestartet. Dort ist es also möglich sich per SSH-Tunnel die alte Datenbanken anzuschauen. Im zweiten Schritt habe wir die Replikation zum db02.jt wieder zu Laufen gebracht. Der Abschluß bildete die Cron-Jobs wieder zu aktivieren, das System allgemein und grob zu testen und Collectd und Nagios zu überprüfen bzw. die Änderungen dort zu konfigurieren. Laut mehreren Aussagen "fühlt" sich das System schneller an - Im Ernst ich habe wohl die meiste Zeit in den letzten Wochen mit dem System verbracht und konnte keine Gefühle entwickeln; liegt aber vielleicht auch an mir. Nagios und Collectd laufen und schicken zufriedenstellende Daten. SRK und ich werden das System die nächsten Tage bzgl. der Speicherentwicklung (Swap, key-buffer-size, innodb-buffer-size) beobachten und ggf. nach Absprache Nuancen verändern, was zu kurzen (15min) Nichtereichbarkeiten führen wird. lg, Tilo - -- 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) iQIcBAEBAgAGBQJTRQVIAAoJEFfjOJdKpi1EcmkP/0LEVpK9Bygua/Eb02EoCPQX rzV2cgbYV9SJMt0PYvx7Fhyz+SNnMamno23XoagjEtCstAWbhkUalBXPdlXddsh+ ygA1tfaQnKI1JiZ01GFVzExiYQd3d6q3yyn8ZTjUm6r2vX9Tal9Oy6fIelzQMQxw riWKBtzifATTloqwJ5YzTYohlhmeX4lLauXazAf8iArtk27PHrGTxC8ARb40sTtb YUwrIwZhzXIwJk98H6aI+q95vlGfvMltyhKFbbpQIszQvT1ouBIyZKWNNPaO5P/n /112aMe3C/AMOJHC8eAXhQfNMnNv7C89NawLw9Q0gTMF4Nh9/vtKpy69z2oy117X I/9D9oiaQfjWtJ+PqsrTaQFZY4qT9CNxIDzEi8ZQBnX50rJORR2HN2Xo1XcdnQ96 pzy4/yx9gqpKKHMq3wcXIvDQDFf34AHb47ECCdnCEM6ctglpfJTvHl+Mv0rwZ+f/ xHuZ26VwjtUWtlPEj9u+JPHrEaUrowrFIXzK7Bfn0e+F11h0E5/NfVefGMrHXrKS hh3HuWU0NT63ODT5g0xkF+/hgBRtZLDiG3BdG7hzKAcRaMaXgWpAgQ5Ki6lXZuC/ 2jjNPU04xPwl91oEPAeUTrMjVfCEDdBQU701DIcwt/hT9QtXxPMpCeL8hcdtyUNE ckDsh7I876FH9w0UAPuC =rrnS -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Speicherverbrauch/-entwicklung sieht gut aus, System wird das Wochenende von daher problemlos überstehen. lg, Tilo Am 09.04.2014 10:31, schrieb Tilo Werner:
Hallo zusammen,
Sören und ich haben heute gegen 06:15 Uhr mit der Umstellungen begonnen und diese 07:45 abgeschlossen. Der alte db01.jt war von ca. 06:30 bis 07:00 Uhr und ein zweites Mal von ca. 07:20 bis 07:40 Offline.
Im ersten Schritt haben wir sämtliche Cron-Jobs angehalten, das xres_jt_logbook Schema exportiert und in den neuen importiert. Dann haben wir den alten MySQL-Server angehalten, den neuen via Chef in db01.jt umbennant und ihm die MySQL-Rolle als Master gegeben.
Danach haben wir alle DNS-Einträge der beiden getauscht d.h.
- db01.rz1.jt.xres.de löst nun nach 10.21.3.14 auf - db03.rz1.jt.xres.de löst nun nach 10.21.3.8 auf
Der MySQL-Server auf dem alten (nun db03.jt) wurde mit bind-address 127.0.0.1 wieder gestartet. Dort ist es also möglich sich per SSH-Tunnel die alte Datenbanken anzuschauen.
Im zweiten Schritt habe wir die Replikation zum db02.jt wieder zu Laufen gebracht.
Der Abschluß bildete die Cron-Jobs wieder zu aktivieren, das System allgemein und grob zu testen und Collectd und Nagios zu überprüfen bzw. die Änderungen dort zu konfigurieren.
Laut mehreren Aussagen "fühlt" sich das System schneller an - Im Ernst ich habe wohl die meiste Zeit in den letzten Wochen mit dem System verbracht und konnte keine Gefühle entwickeln; liegt aber vielleicht auch an mir.
Nagios und Collectd laufen und schicken zufriedenstellende Daten.
SRK und ich werden das System die nächsten Tage bzgl. der Speicherentwicklung (Swap, key-buffer-size, innodb-buffer-size) beobachten und ggf. nach Absprache Nuancen verändern, was zu kurzen (15min) Nichtereichbarkeiten führen wird.
lg, 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) iQIcBAEBAgAGBQJTR+9JAAoJEFfjOJdKpi1E94QP/1i/t6i9E/XFbXkIFRKfQoiF 2SkQ5gS8p9ujHvefHq1uri1Zon8F4Zxf2Ng1iMFun5buNNpcpJF35N3/hn6UABLt 4Vf9FJJPhLwoeL4qjuALbweRISdr38YCIlgcwMBMQsQjZlOYhfZbtppO8pznGY5q 6CiQMjAMrwFv8SoK74ZZzzoWd292SqMZ2LMuXgwNZaT8PJMrF8fcsoxGNJ28niOS obx22Bj0fIcRWqlMayMEwd/QyqF9dO2I7JNDQUcrXXr6BXlOjEAqNKMJP+9LCMnF 4ddjYTmOrAgiit0BiLIzKdLVxqaQyoyBlGBJwzJuU++jhsxR5JmpgMyjXR76rrwO 2+q7lL4KyPqmmChjTowyB+Uw1Yx+vVA5rPiFW+FZwe6dEnMVdOCuO6Q+J0xiczRp BslyA/ZZoUxK7NgBCOGIdq3TmPCJd/j00Y7qTsErKOaZWZsRBR3sCE2kodx874Pv qO/0lyZ92zXUdPZ4oEfRi948H2y8/PI0AGN8EEP/5mIyyYVetpPN7uSX/MtvATMl Or7RfZuO/pxGXLCdON3LgMgvB+8ThUl+X/bxwMATqb7ahHnu7NixzM8LZ0o6+3Eq SdeIg2xHglVOMvLVxYoxyClVJvLmlOeLQHNBlqRHURNS7VWc6fYErDTcVQNH00rV uiT0teXHx4svWcS7Guwz =+14o -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, SRK und ich haben gerade beschlossen, dass wir am Mittwoch gegen 07:00 Uhr die MyISAM Key-Buffer-Size verdoppeln: key-buffer-size = 12908M und binlog_ignore_db = xres_jt_logbook setzen. lg, Tilo @Support & Haiko bitte dem Kunden Bescheid sagen, dass er für max. 30min am Mittwoch nicht buchbar ist. Am 11.04.2014 15:34, schrieb Tilo Werner:
Speicherverbrauch/-entwicklung sieht gut aus, System wird das Wochenende von daher problemlos überstehen.
lg, Tilo
Am 09.04.2014 10:31, schrieb Tilo Werner:
Hallo zusammen,
Sören und ich haben heute gegen 06:15 Uhr mit der Umstellungen begonnen und diese 07:45 abgeschlossen. Der alte db01.jt war von ca. 06:30 bis 07:00 Uhr und ein zweites Mal von ca. 07:20 bis 07:40 Offline.
Im ersten Schritt haben wir sämtliche Cron-Jobs angehalten, das xres_jt_logbook Schema exportiert und in den neuen importiert. Dann haben wir den alten MySQL-Server angehalten, den neuen via Chef in db01.jt umbennant und ihm die MySQL-Rolle als Master gegeben.
Danach haben wir alle DNS-Einträge der beiden getauscht d.h.
- db01.rz1.jt.xres.de löst nun nach 10.21.3.14 auf - db03.rz1.jt.xres.de löst nun nach 10.21.3.8 auf
Der MySQL-Server auf dem alten (nun db03.jt) wurde mit bind-address 127.0.0.1 wieder gestartet. Dort ist es also möglich sich per SSH-Tunnel die alte Datenbanken anzuschauen.
Im zweiten Schritt habe wir die Replikation zum db02.jt wieder zu Laufen gebracht.
Der Abschluß bildete die Cron-Jobs wieder zu aktivieren, das System allgemein und grob zu testen und Collectd und Nagios zu überprüfen bzw. die Änderungen dort zu konfigurieren.
Laut mehreren Aussagen "fühlt" sich das System schneller an - Im Ernst ich habe wohl die meiste Zeit in den letzten Wochen mit dem System verbracht und konnte keine Gefühle entwickeln; liegt aber vielleicht auch an mir.
Nagios und Collectd laufen und schicken zufriedenstellende Daten.
SRK und ich werden das System die nächsten Tage bzgl. der Speicherentwicklung (Swap, key-buffer-size, innodb-buffer-size) beobachten und ggf. nach Absprache Nuancen verändern, was zu kurzen (15min) Nichtereichbarkeiten führen wird.
lg, 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
- -- 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) iQIcBAEBAgAGBQJTS8GVAAoJEFfjOJdKpi1EZx4P/i3AKLm/4uqoKmxR81HJ5JO7 FyPGgVy/jqZGHcR0Rxbb0gZPQaqhYi1ZcvcKWtCi2/Bjf3n0x8R60rlAlQYUgmjl jBCIlifTZ/qWFCAluI9/pqNptNchkZoptYN8UOrhXNKhP7M0LkmJM7IRty1a8NSn +PKecKOtQ6nAwlQI8Wq/KOpihkRVl8lgN8BHMNMCsGRI2lhFnyQgM+Mp3OUZ/qYB hzC7Fr9W3G+0qaWSTEXLIdFSXFKvBE7+2e1ZObB/vCvCD72wY/lT7STS3Cf1Ng1Y x9C0uSm855Pe5ITezFz1uvscwWbaV7A4trSr9AMGtu6e06NMAGzey2UBZti0XXRv U5ChqJyJjd6hvaXKTgfN9ZlSGvTVTagWLgsPHcY14g72bm0GClUV76hwKy2tGU8H MIFsUsjlxNros/GNU3gPpeZXQya9IEHo/vQE40Cng2+0I1emJv3EfzesfuOblYhs K3R8jzQvinZgZWGrlZTOhG+CDhWZsV4rVeIrluHg9U8B7EGI+F/XItQJQC+DKv4r zcb3eGtFf8K/QM8WNHe0rQ7RVP2KLjWcDYCVF78Yh/JWlSnwafR5vEMPOlE42a/s x6cew3Oecbra0eE7pVH8U4mGMCJY3+pSuraX0d7UoAe35r/Y1U4u+5DH2xgpSZCn AuT1aU+Q+qPVqyw8CCx9 =d21v -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Da ich gelesen haben wir ihr laut und deutlich genickt habt, nehme ich an dass das i.O. geht und mit dem Kunden abgesprochen wurde. Danke, Tilo Am 14.04.2014 13:08, schrieb Tilo Werner:
Hallo,
SRK und ich haben gerade beschlossen, dass wir am Mittwoch gegen 07:00 Uhr die MyISAM Key-Buffer-Size verdoppeln:
key-buffer-size = 12908M und binlog_ignore_db = xres_jt_logbook
setzen.
lg, Tilo
@Support & Haiko bitte dem Kunden Bescheid sagen, dass er für max. 30min am Mittwoch nicht buchbar ist.
Am 11.04.2014 15:34, schrieb Tilo Werner:
Speicherverbrauch/-entwicklung sieht gut aus, System wird das Wochenende von daher problemlos überstehen.
lg, Tilo
Am 09.04.2014 10:31, schrieb Tilo Werner:
Hallo zusammen,
Sören und ich haben heute gegen 06:15 Uhr mit der Umstellungen begonnen und diese 07:45 abgeschlossen. Der alte db01.jt war von ca. 06:30 bis 07:00 Uhr und ein zweites Mal von ca. 07:20 bis 07:40 Offline.
Im ersten Schritt haben wir sämtliche Cron-Jobs angehalten, das xres_jt_logbook Schema exportiert und in den neuen importiert. Dann haben wir den alten MySQL-Server angehalten, den neuen via Chef in db01.jt umbennant und ihm die MySQL-Rolle als Master gegeben.
Danach haben wir alle DNS-Einträge der beiden getauscht d.h.
- db01.rz1.jt.xres.de löst nun nach 10.21.3.14 auf - db03.rz1.jt.xres.de löst nun nach 10.21.3.8 auf
Der MySQL-Server auf dem alten (nun db03.jt) wurde mit bind-address 127.0.0.1 wieder gestartet. Dort ist es also möglich sich per SSH-Tunnel die alte Datenbanken anzuschauen.
Im zweiten Schritt habe wir die Replikation zum db02.jt wieder zu Laufen gebracht.
Der Abschluß bildete die Cron-Jobs wieder zu aktivieren, das System allgemein und grob zu testen und Collectd und Nagios zu überprüfen bzw. die Änderungen dort zu konfigurieren.
Laut mehreren Aussagen "fühlt" sich das System schneller an - Im Ernst ich habe wohl die meiste Zeit in den letzten Wochen mit dem System verbracht und konnte keine Gefühle entwickeln; liegt aber vielleicht auch an mir.
Nagios und Collectd laufen und schicken zufriedenstellende Daten.
SRK und ich werden das System die nächsten Tage bzgl. der Speicherentwicklung (Swap, key-buffer-size, innodb-buffer-size) beobachten und ggf. nach Absprache Nuancen verändern, was zu kurzen (15min) Nichtereichbarkeiten führen wird.
lg, 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) iQIcBAEBAgAGBQJTTToPAAoJEFfjOJdKpi1E/jYP/1MI+uMdU0yXjZCO63bLSIIa ON44i/d29aK1VELR3a6dxA8d1K5+smU6953AusZzmZgk+tE7y/mccAjlTSiJ/LTq sxSYC40qnxuUH8fLVyKnGxoowwhEX2msjih9AaujHCYQtwQ7WrBhuT4FjA8NgTbB o2h2Oe5BekMRxiy+ZQoy2dZCAzoUp3IgGOJ59T1eH66Gb0LQuemCoFxzOld/4JYM EHPVFD7bDkFwOi5/ax37E8wfq5uqHxg7ya/T3gxQdY2eT36/s1LoUuyadq35cSYZ 3mojA3FFzpfp1GFpzRlJdk1bRP+qpKiymJuCoe60Pqxgeu9uVYEL4RokJ1zQSobZ Twcqwun8jWewKOLtyMz7WclYWUsY10UOj0vNNSnL0ob3MN67K01a4UeGMQJaSfM6 2NyhfmDSYks7R7bxvHOsAwviTqQIBoGewZD9kX4b2+i2ONJ2lo7ZcsfURa1LAp7z wk35CubqcSMNbFyiflVWMLipS7FNbGGkJKgA3IiwOUtKABmjL9mvv8LzocBOhhKS rq2DogTpYgXx8BWKM0hla5OpaNxUjufgyW1XjIDWmh+R3L4pKifOAD6TRpH+eNEl Y7i6gAta0S5Bh1e8ubMzYLqWpMyOHCE9O07EGzilScGORqUYZ2Sqjdc+CLWTqZeF X5jl0RrDiZ17/DIAhpY7 =fzLN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Tilo, es wäre besser, dies vor 7 Uhr zu tun, da um 7 Uhr eine Menge Scripte starten, die dann manuell gestartet werden müssten (Reports usw.). Sollte dies nicht möglich sein, muss die Info raus, dass die Reports sich verspäten werden. Viele liebe Grüße Stefan Wieden - - Development ___________________________________________________________________________ TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig Tel.: +49 341 90 98 745 // Fax: +49 341 90 98 749 Internet: http://traso.de E-Mail: s.wieden@traso.de ___________________________________________________________________________ Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 Am 15.04.2014 15:54, schrieb Tilo Werner:
Da ich gelesen haben wir ihr laut und deutlich genickt habt, nehme ich an dass das i.O. geht und mit dem Kunden abgesprochen wurde.
Danke, Tilo
Am 14.04.2014 13:08, schrieb Tilo Werner:
Hallo,
SRK und ich haben gerade beschlossen, dass wir am Mittwoch gegen 07:00 Uhr die MyISAM Key-Buffer-Size verdoppeln:
key-buffer-size = 12908M und binlog_ignore_db = xres_jt_logbook
setzen.
lg, Tilo
@Support & Haiko bitte dem Kunden Bescheid sagen, dass er für max. 30min am Mittwoch nicht buchbar ist.
Am 11.04.2014 15:34, schrieb Tilo Werner:
Speicherverbrauch/-entwicklung sieht gut aus, System wird das Wochenende von daher problemlos überstehen.
lg, Tilo
Am 09.04.2014 10:31, schrieb Tilo Werner:
Hallo zusammen,
Sören und ich haben heute gegen 06:15 Uhr mit der Umstellungen begonnen und diese 07:45 abgeschlossen. Der alte db01.jt war von ca. 06:30 bis 07:00 Uhr und ein zweites Mal von ca. 07:20 bis 07:40 Offline.
Im ersten Schritt haben wir sämtliche Cron-Jobs angehalten, das xres_jt_logbook Schema exportiert und in den neuen importiert. Dann haben wir den alten MySQL-Server angehalten, den neuen via Chef in db01.jt umbennant und ihm die MySQL-Rolle als Master gegeben.
Danach haben wir alle DNS-Einträge der beiden getauscht d.h.
- db01.rz1.jt.xres.de löst nun nach 10.21.3.14 auf - db03.rz1.jt.xres.de löst nun nach 10.21.3.8 auf
Der MySQL-Server auf dem alten (nun db03.jt) wurde mit bind-address 127.0.0.1 wieder gestartet. Dort ist es also möglich sich per SSH-Tunnel die alte Datenbanken anzuschauen.
Im zweiten Schritt habe wir die Replikation zum db02.jt wieder zu Laufen gebracht.
Der Abschluß bildete die Cron-Jobs wieder zu aktivieren, das System allgemein und grob zu testen und Collectd und Nagios zu überprüfen bzw. die Änderungen dort zu konfigurieren.
Laut mehreren Aussagen "fühlt" sich das System schneller an - Im Ernst ich habe wohl die meiste Zeit in den letzten Wochen mit dem System verbracht und konnte keine Gefühle entwickeln; liegt aber vielleicht auch an mir.
Nagios und Collectd laufen und schicken zufriedenstellende Daten.
SRK und ich werden das System die nächsten Tage bzgl. der Speicherentwicklung (Swap, key-buffer-size, innodb-buffer-size) beobachten und ggf. nach Absprache Nuancen verändern, was zu kurzen (15min) Nichtereichbarkeiten führen wird.
lg, 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTTTuYAAoJEJD9yagW2vzo/jQP/2WE/GEB+s6g8SQZGgEjTE6t r0e5UEjrTbfGdADfIbIHgNCXwtWH1tQ4U0ArL/GQxJk2yKHMpS8PN5Y9I0XG4OGb x7BteD0ESGg9DXXfx9qWUdDB+tDUJessHXWUCB/YnSpkCIT73JVfXuOAHczmMyKv aIObITHbRykPkUmAQWk3Tf3wPhWO69UiOhkBbCdqvU85rG7BPXobjRzg6BDGzYdP yjj6XF8Sv6umV/J6I77rzckwnDlZ4ALlDIKO93ig+/9+9xAwpnIQoX+61rVzWZUS wMAK81UyHs6hhEkpwVTHOstFLh5Tbm5ResaaUOEeWC8yzGWvlV+eX2Q1zo7r7+F/ DzYe7TJRsBfn56ezRhWp54fKIR1tyxEGaBVqnelowuOX1pltAXuxQu1IdwUol9OC mvO8Qhu/ZiwDR9+moxXdunMvWBhxWMZzpjTuwMA0xThKQDKs1oPrjZdGlNlArPpe m67sbty0gakzA2Vu5soGX3O0yox1RM1JZa9ac2xbgwQXpM/PlkXLkUTOSMMSm8rm blOoJDZySpAUUnijrFSxxTSmM0OPXTzN/XxlGRge2TV/5tc3bYBa144vhNtID01a xUHNTBTdVm+mA0Z5WFT5q7SgeHaRTsid18DAfxA5vwlcZ/NYtZGy1ZIDqPNcTmnK cZSZyLAd7vc0ki2POCUe =B97o -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, dann fange ich freudig und mit viel Zuversicht morgen gegen 06:15 Uhr an... Am 15.04.2014 16:00, schrieb Stefan Wieden:
Hallo Tilo,
es wäre besser, dies vor 7 Uhr zu tun, da um 7 Uhr eine Menge Scripte starten, die dann manuell gestartet werden müssten (Reports usw.). Sollte dies nicht möglich sein, muss die Info raus, dass die Reports sich verspäten werden.
Viele liebe Grüße
Stefan Wieden - Development ___________________________________________________________________________
TraSo GmbH Georg-Schumann-Str. 294 D-04159 / Leipzig
Tel.: +49 341 90 98 745 // Fax: +49 341 90 98 749
Internet: http://traso.de E-Mail: s.wieden@traso.de ___________________________________________________________________________
Geschäftsführer: Haiko Gerdes
Handelsregister: Amtsgericht Leipzig, HRB 21850
Am 15.04.2014 15:54, schrieb Tilo Werner:
Da ich gelesen haben wir ihr laut und deutlich genickt habt, nehme ich an dass das i.O. geht und mit dem Kunden abgesprochen wurde.
Danke, Tilo
Am 14.04.2014 13:08, schrieb Tilo Werner:
Hallo,
SRK und ich haben gerade beschlossen, dass wir am Mittwoch gegen 07:00 Uhr die MyISAM Key-Buffer-Size verdoppeln:
key-buffer-size = 12908M und binlog_ignore_db = xres_jt_logbook
setzen.
lg, Tilo
@Support & Haiko bitte dem Kunden Bescheid sagen, dass er für max. 30min am Mittwoch nicht buchbar ist.
Am 11.04.2014 15:34, schrieb Tilo Werner:
Speicherverbrauch/-entwicklung sieht gut aus, System wird das Wochenende von daher problemlos überstehen.
lg, Tilo
Am 09.04.2014 10:31, schrieb Tilo Werner:
Hallo zusammen,
Sören und ich haben heute gegen 06:15 Uhr mit der Umstellungen begonnen und diese 07:45 abgeschlossen. Der alte db01.jt war von ca. 06:30 bis 07:00 Uhr und ein zweites Mal von ca. 07:20 bis 07:40 Offline.
Im ersten Schritt haben wir sämtliche Cron-Jobs angehalten, das xres_jt_logbook Schema exportiert und in den neuen importiert. Dann haben wir den alten MySQL-Server angehalten, den neuen via Chef in db01.jt umbennant und ihm die MySQL-Rolle als Master gegeben.
Danach haben wir alle DNS-Einträge der beiden getauscht d.h.
- db01.rz1.jt.xres.de löst nun nach 10.21.3.14 auf - db03.rz1.jt.xres.de löst nun nach 10.21.3.8 auf
Der MySQL-Server auf dem alten (nun db03.jt) wurde mit bind-address 127.0.0.1 wieder gestartet. Dort ist es also möglich sich per SSH-Tunnel die alte Datenbanken anzuschauen.
Im zweiten Schritt habe wir die Replikation zum db02.jt wieder zu Laufen gebracht.
Der Abschluß bildete die Cron-Jobs wieder zu aktivieren, das System allgemein und grob zu testen und Collectd und Nagios zu überprüfen bzw. die Änderungen dort zu konfigurieren.
Laut mehreren Aussagen "fühlt" sich das System schneller an - Im Ernst ich habe wohl die meiste Zeit in den letzten Wochen mit dem System verbracht und konnte keine Gefühle entwickeln; liegt aber vielleicht auch an mir.
Nagios und Collectd laufen und schicken zufriedenstellende Daten.
SRK und ich werden das System die nächsten Tage bzgl. der Speicherentwicklung (Swap, key-buffer-size, innodb-buffer-size) beobachten und ggf. nach Absprache Nuancen verändern, was zu kurzen (15min) Nichtereichbarkeiten führen wird.
lg, 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
_______________________________________________ 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) iQIcBAEBAgAGBQJTTUG+AAoJEFfjOJdKpi1EUKkP/2RRIMYDZUvBlP2/s6hMf8Cs MfG1cXprMB8J0opgFh20CXap8En3Gvr6fw6GZqfmZX1aCBDoeRUi7hxKCp/+vSpN thwP245TbZECV2nqu3HBD4bAh7F8jfSympK4EIGBxwiu94znoyTdSb1Ph3UbkFLZ 6xH9e/xsB1kIrY3iSBEZHceVmYq/zq6cw0syHiitcqIcKhgZCfm1ArSuzGrm6z48 ws9ACkvpyxKjtHWgsPBsBY43xdb54m8s/MJGhMBtmLfikeEnuDFRVXDsSDx+I1HC o7YnUznHcV9YcbsmLo0Qz865lRDNn88JpDTyFWYtbQPz4s4nPoBssiHrrrI7FDeb PByKY1ZBxw6sVen3+YwQT5QuBUIhUh5lUzwzezhSwycMVF0pwbmtJ8ajJK/fdEV5 IBgkmhCmYDpMQczo2XA/pIggtzeWJAtNaYtTsLPNNNSO/s5RcZUuwEt70x5EfPOi RyBFNtf7YCoBKQZQwoNgt5cvitrOMJODhf72EcTod8Jd/QsPTvsKvDxXK2fg921y mZQ8+js2sV2X0R5V82CpJ5gA+bLDocrb4zuMBM5dr4XhSEYeGO8F8zN8Wn06xMMI RpWNNCQgKV5ZfWKeRICGVnosJ5Q1WNo73jZ5YxL7d08OApDUoo7gcab97qf61v7B feAQML+8WPxjsaaKfLFO =vSQg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alles ist gut. Die Konfig ist umgestellt. Der MySQL-Server war von 06:15 - 06:18 und 06:30 - 06:33 nicht erreichbar. Zwischen 06:15 und 06:45 war er insgesamt schlecht erreichbar, da diesem Zeitraum die MTU auf 1408 gesetzt war. lg, Tilo Am 15.04.2014 16:27, schrieb Tilo Werner:
Ok, dann fange ich freudig und mit viel Zuversicht morgen gegen 06:15 Uhr an...
- -- 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) iQIcBAEBAgAGBQJTTg1gAAoJEFfjOJdKpi1E+4gP/jiaXB26Mrli6xu2ahH1xrOr 0u4ZnySdXdYrSBpJba+rHUBBJUFh4aekHo29xiSdnhApe1S5r12zsX1zoH5u6FfV e7Y2PlLSb6fZ8EEOlQ/avMrbdG33qkVw/0xjtmQbdT3oGEHprpF6MoUiPdLrHOtF 2g0HbZ5nhZfmIU4klu7rkebONBxBYb8xvDq10FtrWBOoqjphV1qjQKoc0tXs+5O/ PAd2Oofqc3TOSXsVYD3A0jtb74EEHOorZHrQViXUa9WHS3+d4CoHsYG9+jG17zO5 UO002UiLLmTDCQcA2e+2LkY7T73L1eEuhO2OxM3AOdb2OGQFWOvqRfmhb29D/Ljx vXRxh0LXrInnmtFUq+/Ya/EMNXprr1CoxSCL/Pqo6ma65NarQG4LJ44PX1Cj7K1e paGWFS90hDX62nWDJFQ/xdsnAtywr8fWLXcUyhbQQCHErBhr+2zIklFeDdcIGsnQ 3GN2Vp0+Spd9Qcs+ME4/XByc7BuD9F+9ms66aRnm5zRLfOhytAik67IR6et+RbEk PfUcXhvIJiAn0mA4SLKhOdduMKKBsMikCf+up8yyrlDd/2nHMNzt3+N8sY6Rqu5x M2Abf5VaOh5XAdLQCp/YrvqPF2eqxyklhiOnHCTyGl92+KqjInhmf8qsynpC4LrX b0BVrv3Ir+7HhweUnqen =OnZd -----END PGP SIGNATURE-----
participants (3)
-
Haiko Gerdes -
Stefan Wieden -
Tilo Werner