I/O Wait Problem

Welche PHP-Version?
Wie wird PHP eingebunden?
Welche PHP/PECL-Extensions sind geladen?
Wie sieht die php.ini aus?
phpinfo()?
 
Welche PHP-Version?
PHP5.4 PHP5.5 PHP5.6 PHP7

Wie sieht die php.ini aus?
http://php54.abperformance.de/phpinfo2.php
http://php55.abperformance.de/phpinfo2.php
http://php56.abperformance.de/phpinfo2.php
http://php7.abperformance.de/phpinfo2.php

Das meiste davon wird von LiveConfig verwaltet und bereitgestellt.

Nach wie vor muss es ja was mit dem Server zutun haben, ein simpler KVM von Contabo hat da nur gegähnt in den ganzen 4 Monaten wo wir ihn genutzt haben, ich bin davon Überzeug das wenn ich das Setup wieder auf einen KVM dort spielen würde, das das ganze entspannt laufen würde ohne I/O Peak Probleme, wenn der Server hier jetzt schon an seine "Grenzen" ist mit dem I/O Wait geht, wie muss es dann sein wenn noch 30 oder 40 Kunden dazu kommen?

Diese Peaks sind nun nicht dauerhaft, sondern kommen mal mehr und mal weniger über den Tag verteilt.

Vielleicht müssen wir hier wirklich auf SSD umsteigen um das Problem komplett in den griff zu bekommen, man müßte das ganze mal mit einem Premium M Server mit SSD von IPP vielleicht testen.
 
Last edited by a moderator:
Ayb said:
Vielleicht müssen wir hier wirklich auf SSD umsteigen um das Problem komplett in den griff zu bekommen, man müßte das ganze mal mit einem Premium M Server mit SSD von IPP vielleicht testen.
Click to expand...

Das könnt ihr doch viel einfacher haben. Da ihr einen RAID-Controller mit 8 Ports habt und erst 4 von 8 Ports verbraucht habt, fragt doch mal bei eurem Provider nach, ob er euch mal testweise 4 SSDs mit hinzu einbaut. Dazu braucht ihr noch nicht mal euer Betriebssystem neu aufsetzen.
 
Last edited by a moderator:
1. PHP 5.4 und 5.5 sind EOL und sollten dringend entsorgt werden.
2. APC ist überflüssig und kollidiert mit Zend OPCache.
3. Zend OPCache ist suboptimal konfiguriert.
4. PHP-[F]CGI ist deprecated und sollte schnellstmöglich durch PHP-FPM ersetzt werden.

Punkt 2. dürfte für etwa 20-30% Deiner durch PHP verursachten IO-Peaks verantwortlich sein und Punkt 3. für weitere etwa 30-60%.
Die anderen beiden Punkte wirken sich zwar kaum auf die IO aus, sind aber dennoch lohnende und notwendige Verbesserungen des Systems.


BTW: Werden ionCube und Readline bei Dir wirklich genutzt? Falls nicht, dann bitte entsorgen (Letzteres ist nicht Threadsafe, Ersteres hat Sicherheitslücken ohne Ende).
 
1. PHP 5.4 und 5.5 sind EOL und sollten dringend entsorgt werden.
Wird von einigen Kunden gebraucht

2. APC ist überflüssig und kollidiert mit Zend OPCache.
Werde ich mal deinstallieren

3. Zend OPCache ist suboptimal konfiguriert.
Was genau?

4. PHP-[F]CGI ist deprecated und sollte schnellstmöglich durch PHP-FPM ersetzt werden.
Wird von LiveConfig nicht unterstützt.

ioncube wird benötigt, einige Anwendungen sind damit verschlüsselt und laufen ohne ihn nicht.

---
@andreas
Ich werde das mal bei IPP anfragen, danke für den Tipp
 
Last edited by a moderator:
Ayb said:
1. PHP 5.4 und 5.5 sind EOL und sollten dringend entsorgt werden.
Wird von einigen Kunden gebraucht
Click to expand...
Diese Kunden sollen ihre Apps aktualisieren, andernfalls kannst Du aus Sicherheitsgründen nicht mehr für deren volle Funktionsfähigkeit garantieren. Beide PHP-Versionen enthalten ungefixte Lücken, welche eine Systemübernahme ermöglichen. Sicherheit geht immer vor, auch wenn es für den Kunden Arbeit bedeutet. Jammern tut der Kunde eh, entweder weil seine veraltete unsichere Website gehackt wurde, oder weil er etwas Zeit ins Update seiner Website stecken musste.

Ayb said:
2. APC ist überflüssig und kollidiert mit Zend OPCache.
Werde ich mal deinstallieren
Click to expand...
Wordpress W3 Totel Cache (den meintest Du wohl vor Deinem Edit) kann laut Google auch mit MemCache betrieben werden, somit ist APC hier nicht (mehr) nötig.

Ayb said:
3. Zend OPCache ist suboptimal konfiguriert.
Was genau?
Click to expand...
Du kannst es erstmal mit meinen Werten versuchen, das sollte schonmal ein Wenig helfen:
https://www.rootservice.org/scripts/phpinfo.php
Für optimalere Ergebnisse musst Du etwas mit den Cachegrössen und der Anzahl zu cachenden Files experimentieren.
Wichtig ist vor Allem keinen filebasierten Cache zu verwenden, sondern einen memorybasierten (mmap, shm).
 
Nein ich meinte da er Cachy was den APC/U benutzt

Aber gut das kann man verschmerzen wenn es wirklich Performance bringt. Allerdings lässt sich das nicht deinstallieren er sagt mir es wäre nicht Installiert => eigenartig

bzgl. der PHP Versionen hier ist erstmal zu klären ob LiveConfig das von selbst auf PHP5.5 oder PHP5.6 ändert wenn eine Version weg fällt,oder ob hier noch von Hand zu helfen ist.
 
Code: 
[root@srv1 kle1000]# yum --enablerepo=remi list php* | grep apc
Repository 'postfixrepo' is missing name in configuration, using id
php-ZendFramework2-Cache-apc.noarch             2.2.7-1.el7.remi           remi
php-pecl-apcu.x86_64                            4.0.11-2.el7.remi.5.4      remi
php-pecl-apcu-devel.x86_64                      4.0.11-2.el7.remi.5.4      remi
php54-php-pecl-apcu.x86_64                      4.0.11-1.el7.remi          remi
php54-php-pecl-apcu-devel.x86_64                4.0.11-1.el7.remi          remi
php55-php-pecl-apcu.x86_64                      4.0.11-1.el7.remi          remi
php55-php-pecl-apcu-devel.x86_64                4.0.11-1.el7.remi          remi
php56-php-pecl-apcu.x86_64                      4.0.11-1.el7.remi          remi
php56-php-pecl-apcu-devel.x86_64                4.0.11-1.el7.remi          remi
php70-php-pecl-apcu.x86_64                      5.1.8-1.el7.remi           remi
php70-php-pecl-apcu-bc.x86_64                   1.0.3-1.el7.remi           remi
php70-php-pecl-apcu-devel.x86_64                5.1.8-1.el7.remi           remi
php71-php-pecl-apcu.x86_64                      5.1.8-1.el7.remi           remi
php71-php-pecl-apcu-bc.x86_64                   1.0.3-6.el7.remi           remi
php71-php-pecl-apcu-devel.x86_64                5.1.8-1.el7.remi           remi
 
Nur eine Anmerkung von mir: Vorhandene Softwarepakete mit samt dessen Konfigurationen zu deinstallieren, auch wenn sie schon als veraltet und eventuell unsicherer eingestuft wurden, können das Gesamtsystem viel eher unbrauchbarer machen, als eben mal einen laufenden Prozess wie z.B. einen Java-Prozess testweise zu beenden, zumal man Diesen ja bei Bedarf ohne große Probleme wieder starten kann.
 
Last edited by a moderator:
Ich verstehe schon was du meinst, wollte vorher nur Rückmeldung erhalten von IPP ob man diesen Prozess wirklich einfach killen kann ohne etwas kaputt zu schießen....

Edit:
OPCache hab ich nun nach deinem muster für PHP5.6 und PHP7.0 angepasst

Wie sieht es eigentlich mit Redis aus? Kommt das in einen Konflikt mit irgendwas? Für WordPress soll sich das wohl extrem lohnen....
 
Last edited by a moderator:
@IP-Projects.de
Ich habe mir mal deinen hilfreichen Test über deine Webseite https://blog.ip-projects.de/die-intel-cache-acceleration-software-im-test/ genauer angeschaut.
Wenn man sich insbesondere folgende Zeilen daraus genauer anschaut, so sieht es so aus, als sei der KVM-Server so konfiguriert, sodass er generell das IO über einen Cache - eventuell über RAM realisiert - durchführt. Egal ob nun der Schalter oflag=direct im DD-Befehl gesetzt ist oder nicht.

Code: 
Festplatte write
dd if=/dev/zero of=./test.file bs=1M count=1000 oflag=direct

Ohne CAS: 141 MB/s
Mit CAS – normale Partition: 258 MB/s

[B]Ohne CAS[/B] – KVM virtuelle Maschine: [B]2.0 GB/s[/B]
Mit CAS – KVM virtuelle Maschine unter 256 GB: 241 MB/s
Mit CAS – KVM virtuele Maschine über 256 GB: 1.2 GB/s

Ohne CAS – LXC virtuelle Maschine: 109 MB/s
Mit CAS – LXC virtuelle Maschine: 3.0 GB/s

Ist dieser KVM-Server eventuell fehlerhaft konfiguriert?
 
@andreas0

Das habe ich unter meine Tests auch bereits geschrieben. Es handelt sich um eine Standard Konfiguration von Proxmox. Caching ist hier eigentlich nicht aktiv per default.

Am besten sind eigentlich die Referenzwerte direkt auf den blanko installierten System ohne einen Virtualisierungslayer dazwischen.

Ohne CAS: 141 MB/s
Mit CAS – normale Partition: 258 MB/s

Diese sind insgesamt am aussagekräftigsten genauso wie ioping.
 
Ich wollte hier kurz Rückmeldung geben.

Wir haben inzwischen den Server gewechselt dies mal ein (Adaptec 6805T) Raid-10 mit Flash und 8 x SAS Festplatten.

Das Problem mit den I/O Peaks ist jetzt jedenfalls komplett weg und taucht nicht mehr auf.

Wollte hier aber zum Abschluss eben Danke an alle sagen für eure Hilfe und Vorschläge!
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top