Performanceoptimierung PHP wait load

@d4f: Ich vermute, dass manche so und manche so sind. Die DB-User Passwörter scheinen AES 128 bit Verschlüsselung zu haben. Das PW vom Panelzugang sieht mir nach einem gesalzenem MD5 Hash aus. Wird wohl bei allen neueren Plesk-Versionen so sein, die verschlüsseln / hashen und nicht Klartext speichern, ich wüsste nicht, dass man das einstellen kann.

@remote_mind: Danke für den Tipp mit den Sonderzeichen, jetzt ist aber seit zwei Tagen Parallels dran, sich das anzusehen, da möchte ich jetzt auch nicht dazwischenfunken. Mittlerweile habe ich von Parallels erfahren, dass es da mit der Zeichenkodierung etwas zerhaun hat, was deine Vermutung auch bestätigt.
Bzgl. der Passwörter, ja für das Panel geht das schon, aber wo stehen dann die Passwörter, die die Server wie Courier, Postfix, Proftp und SSH verwenden? Da sind sie dann wahrscheinlich auch wieder anders verschlüsselt / gehasht, oder? Bei Email wäre mir das am wichtigsten, denn da fällt es sofort auf.
 
Last edited by a moderator:
Lord Gurke said:
Bei KVM z.B. bringt es echt Schub, wenn man die Host-CPU 1:1 durchreicht. Sonst sieht die CPU im Gast nur ein paar wenige Befehlssätze und muss unnötigerweise aufwändigere Rechenoperationen anstoßen als wenn der optimierte Befehlssatz genutzt wird.
Click to expand...
Leicht OT, aber dafür mache ich keinen neuen Thread auf: Ich arbeite mich gerade ins Thema Virtualisierung (mit KVM, derzeit unter SolusVM & CentOS) ein, wie reicht man denn die CPU 1:1 durch?
 
@remote_mind: Ja schon, ich denke, dass das aber für Plesk nur da gespeichert wird und Courier bzw. Postfix die Passwörter wahrscheinlich woanders abfragen, oder sehe ich das falsch? Cool, pleskhacker.com kannte ich noch gar nicht, Danke für den Link!
 
Also wenn ich das richtig sehe benutzt Plesk spezielle Auth-Module für die Dienste. Es gibt also ein
Code: 
AUTHMODULES="authpsa"
im Courier-Konfigfile /etc/courier-imap/imapd und ein
Code: 
auth required pam_plesk.so try_first_pass
in /etc/pam.d/common-auth etc.

Wie die Module genau arbeiten weiss ich nicht, aber ich vermute schon dass hier direkt auf die PSA-Datenbank zugegriffen wird.

schönes Wochenende,
Nils
 
s24! said:
Leicht OT, aber dafür mache ich keinen neuen Thread auf: Ich arbeite mich gerade ins Thema Virtualisierung (mit KVM, derzeit unter SolusVM & CentOS) ein, wie reicht man denn die CPU 1:1 durch?
Click to expand...
Ich habe das bisher nur ohne irgendwelche Control-Panels dazwischen gemacht. Bei mir steht in der XML-Datei für die Definition der Maschine noch ein
Code: 
<cpu mode='host-passthrough'/>

Das wird auf der selben XML-Ebene definiert, wie auch vcpu oder der Name.
Wenn das aktiviert ist, ist jedoch keine Live-Migration der Maschine auf ein System mit einem anderen CPU-Modell mehr möglich!
 
Nachdem das System fast gänzlich wiederhergestellt ist und das Problem trotz Austausch der Platten (2 Stück, Raid 1) wohl immer noch besteht, anbei der folgende Test:

Code: 
dd if=/dev/zero of=/var/file bs=32k count=5000 oflag=sync
5000+0 Datensätze ein
5000+0 Datensätze aus
163840000 Bytes (164 MB) kopiert, 294,363 s, 557 kB/s

Also Fehler gabs anscheinend kein, aber 557 kB/s erscheint mir doch etwas langsam, oder? 164 MB sollte auch keine 5 Minuten brauchen.
 
Wohl doch nicht so unnormal bei der Paketgröße. Ich habe auf zwei anderen Servern mal das selbe getestet.

Einmal Heimserver (Ubuntu Lucid):
Auf die SSD (wie er abgeht!):
Code: 
dd if=/dev/zero of=/var/file bs=32k count=5000 oflag=sync
5000+0 Datensätze ein
5000+0 Datensätze aus
163840000 Bytes (164 MB) kopiert, 5,61398 s, 29,2 MB/s

Wieder Homeserver aber aufs LVM mit zwei 2TB Samsung:
Code: 
dd if=/dev/zero of=/home/file bs=32k count=5000 oflag=sync
5000+0 Datensätze ein
5000+0 Datensätze aus
163840000 Bytes (164 MB) kopiert, 338,461 s, 484 kB/s

Und dann noch auf einen Dell PowerEdge mit einer 500GB Standard Platte die von Dell dabei ist:
Code: 
dd if=/dev/zero of=/var/file bs=32k count=5000 oflag=sync
5000+0 Datensätze ein
5000+0 Datensätze aus
163840000 Bytes (164 MB) kopiert, 186,129 s, 880 kB/s

Wobei das schon eine Nummer schneller ist. Was meint ihr dazu?
 
Hier noch ein Screenshot von iostat 1 wenn mal wieder länger eine Seite geladen wird. Das trifft in der Regel hauptsächlich zu, wenn es dynamische (CMS) Daten sind, die nicht gecached sind (und dann wohl auch nicht im APC Cache landen). Mit oder ohne APC hatte soweit ich beobachtet habe keinen Unterschied gemacht, als der Server noch komplett in Standardkonfiguration war (ohne APC und Anpassung der Konfig-Dateien) oder jetzt.
 

Attachments

  • iostat.png
    iostat.png
    155.8 KB · Views: 144
Und das war los, als ich den dd Schreibtest auf dem betroffenen Server durchgeführt habe (Screenshot).
 

Attachments

  • iostat.png
    iostat.png
    155.8 KB · Views: 138
iostat macht mehr Spass als 'iostat -x'

Mit 'iotop' solltest Du mal schauen, welcher Prozess es ist, der da so viel IO-Last erzeugt.
 
iotop habe ich hier, Screenshot im Anhang. MySQL tut gut was, aber warum? Ich habe die 5.5 drauf (von dotdeb).

Die Mountoption noatime habe ich jetzt auch aktiv, bringt aber auch nichts.

Das einzige, was mir jetzt einfallen würde, wäre ein Downgrade auf MySQL 5.1:
apt-get install mysql-server=5.1.66-0+squeeze1 mysql-server-5.1 mysql-client-5.1
Ich mache das eher ungern, sollte aber doch problemlos klappen. Oder was meint ihr? Oder brauch ich das gar nicht testen?
 

Attachments

  • iotop.jpg
    iotop.jpg
    179.4 KB · Views: 163
Last edited by a moderator:
Noch ein Test, den ich ausgeführt habe, bei einer Website, bei der das Problem ganz gut nachvollziehbar ist, habe ich diese auf ein Shared Hosting eines TYPO3 Hosters geklont, da waren wesentlich bessere Ladezeiten, also kann es an der Site selbst nicht liegen. Wobei ich auch festgestellt habe, dass dies Hauptsächlich TYPO3 V 6 Systeme betrifft. Bei einem 4.7er System läuft alles ratz fatz, die wait Last steigt hier zwar auch kurzfristig auf 20 %, ist aber sofort wieder unten und die Seite ist geladen. Vor allem beim Update des Extension Repository merkt man das gut. TYPO3 6 ist auch die erste Version, die MySQL 5.5 unterstützt, trotzdem läuft es nicht so wie die alten Versionen, die 5.5 offiziell noch nicht unterstützen. Bei anderen Systemen wie Magento, Contao usw. merkt man das entweder gar nicht oder kaum.
 
Es scheint so, als habe ich die richtigen Konfigurationseinstellungen gefunden, die die Seiten wieder zum rennen gebracht haben:

Code: 
innodb_buffer_pool_size=1024M
innodb_additional_mem_pool_size=100M
innodb_log_buffer_size=100M
innodb_thread_concurrency=2
innodb_flush_log_at_trx_commit=2

Anscheinend hat sich nun dadurch das Problem gelöst!
 
Gut möglich, dass du den InnoDB-Bufferpool vorher gar nicht oder nicht ausreichend genutzt hast. Der ist wesentlich performanter als MyISAMs Cache.

innodb_flush_log_at_trx_commit kannst du auf 0 setzen, hab ich gute Erfahrungen mit gemacht.
 
Also den Buffer Pool hatte ich schon hoch gesetzt, nur innodb_additional_mem_pool_size und innodb_log_buffer_size war recht knapp bemessen und ausschlaggebend für den Performanceschub soll wohl innodb_flush_log_at_trx_commit=2 gewesen sein. Den Wert gleich 0 setzen probiere ich mal aus, Danke für den Tipp!
 
klodeckl said:
ausschlaggebend für den Performanceschub soll wohl innodb_flush_log_at_trx_commit=2 gewesen sein.
Click to expand...
Das deckt sich mit deiner iotop-Ausgabe, welche das Journal als I/O-Performancefresser verraten hatte - wenn du dauernd auf die Platte commitest, kommt es zu genau solchen Engpässen. Da kann man zum einen mit Mountoptionen nachhelfen, zum anderen auch (wie hier) direkt in MySQL ansetzen (was die Problemursache allerdings nur umschifft).
 
Die Einstellung noatime hatte ich ja bereits gesetzt (und hat keine großen Verbesserungen gebracht). Was kann ich da noch verbessern bei den Mountoptionen?
 
In Bezug auf MySQL habe ich durch das beschriebene "Phänomen" mit der (hier bereits erwähnten sowie kritisierten und daher nicht noch mal erwähnten) Mountoption barrier=0 gemacht. Konkret habe ich die Wirkung herausgefunden, als ich den Dump einer knapp 50 GB großen Datenbank einspielen musste. Es ist schon ein Unterschied, ob das Journal 70-99% deines I/Os verursacht oder ob die Hardware von MySQL selbst (bzw. dem "rasenden" Dump) belastet wird. =)
 
Danke für den Tipp. Ich tendiere da wohl fast dazu, die Mountoption zu probieren. Die my.cnf kann ich ja trotzdem so lassen wie sie jetzt ist (dann hätte ich das Problem doppelt nicht meh :-) ).
 
You must log in or register to reply here.
Back
Top