IP-Projects.de
Active Member
Ich habe mir schon einen Testserver mit einem Software RAID und Debian 8 installiert
Ich warte aktuell bis der RAID Sync durch ist, dann kanns los gehen.
I/O Wait Problem
- Thread starter Ayb
- Start date
Ich habe mir schon einen Testserver mit einem Software RAID und Debian 8 installiert
Ich warte aktuell bis der RAID Sync durch ist, dann kanns los gehen.
IP-Projects.de
Active Member
ok CAS ist raus. Als ich nach dem Rebuild den spaß installieren wollte hieß es:
"You cannot accelerate the partition that the operating system resides on. "
root@root901:/etc/intelcas# casadm --add-core --cache-id 1 --core-device /dev/md1
WARNING: Intel(R) CAS is running on a non-validated OS!
Error while adding core device to cache instance 1
Failed to open '/dev/md1' device exclusively. Please close all applications accessing it or unmount the device.
Sowas. Wie hieß es im Video - "es muss nichts an der Infrastruktur geändert werden."
Es scheidet daher als einfache Lösung in dem Fall aus. Da ich mir aber mittlerweile viel Mühe gemacht habe mit einer Anleitung und verschiedenen Tests, werde ich morgen den Server neu aufsetzen und das /var/www Verzeichnis als extra Mount Point setzen um darüber dann die CAS zumindest mal zu testen.
In dem Fall ist die Software daher leider keine einfache Lösung einen SSD Cache zu installieren. Vielleicht wenn man etwas fummelei reinbaut könnte man es z.B. auf LVMs einsetzen um die LVM Devices im Nachhinein mit einem SSD Cache zu versehen, das werde ich auch mal testen mit Proxmox
CAS ist raus. Als ich nach dem Rebuild den spaß installieren wollte hieß es:"You cannot accelerate the partition that the operating system resides on. "
root@root901:/etc/intelcas# casadm --add-core --cache-id 1 --core-device /dev/md1
WARNING: Intel(R) CAS is running on a non-validated OS!
Error while adding core device to cache instance 1
Failed to open '/dev/md1' device exclusively. Please close all applications accessing it or unmount the device.
Sowas. Wie hieß es im Video - "es muss nichts an der Infrastruktur geändert werden."
Es scheidet daher als einfache Lösung in dem Fall aus. Da ich mir aber mittlerweile viel Mühe gemacht habe mit einer Anleitung und verschiedenen Tests, werde ich morgen den Server neu aufsetzen und das /var/www Verzeichnis als extra Mount Point setzen um darüber dann die CAS zumindest mal zu testen.
In dem Fall ist die Software daher leider keine einfache Lösung einen SSD Cache zu installieren. Vielleicht wenn man etwas fummelei reinbaut könnte man es z.B. auf LVMs einsetzen um die LVM Devices im Nachhinein mit einem SSD Cache zu versehen, das werde ich auch mal testen mit Proxmox
Last edited by a moderator:
Naja inzwischen ist es bei uns so das der mysql die Peaks kaum bis gar nicht mehr verursacht dafür nun aber php-cgi der Kunden nun am Rad dreht und die I/O Wait Peak extrem beansprucht (ich dreh langsam durch)
Bzgl. des SSD Cache hatte ich Michael gestern schon gefragt, allerdings bcache => Neuinstallieren => kein Option die frage ist lohnt sich das wirklich den Server zu killen bcache und Co einzurichten und dann ein Backup einzuspielen. Das Problem ist hier am ganzen Server leider nur der I/O Wait alles andere läuft ohne Probleme.
Ein BBU gibt es leider nicht für den HWR das hatte ich schon gefrag.
memcached eine wirkliche Verbesserung sehe ich da leider nicht, der Ram hat sich zwar mehr gefüllt => trotzdem I/O Wait und die teilweise extrem bis zu 60%
Ich fürchte fast das die HDD für unsere Zwecke einfach nicht gedacht sind, obwohl gerade mal 60 Kunden auf dem Server sich nur befinden.
Wie sieht die Performance eigentlich mit SAS Festplatten aus im Vergleich zu normalen HDD und SSD ?
Bzgl. des SSD Cache hatte ich Michael gestern schon gefragt, allerdings bcache => Neuinstallieren => kein Option die frage ist lohnt sich das wirklich den Server zu killen bcache und Co einzurichten und dann ein Backup einzuspielen. Das Problem ist hier am ganzen Server leider nur der I/O Wait alles andere läuft ohne Probleme.
Ein BBU gibt es leider nicht für den HWR das hatte ich schon gefrag.
memcached eine wirkliche Verbesserung sehe ich da leider nicht, der Ram hat sich zwar mehr gefüllt => trotzdem I/O Wait und die teilweise extrem bis zu 60%
Ich fürchte fast das die HDD für unsere Zwecke einfach nicht gedacht sind, obwohl gerade mal 60 Kunden auf dem Server sich nur befinden.
Wie sieht die Performance eigentlich mit SAS Festplatten aus im Vergleich zu normalen HDD und SSD ?
Last edited by a moderator:
IP-Projects.de
Active Member
Besser aber dennoch mechanisch. Die SAS Platten drehen normalerweise schneller wodurch sie etwas schneller die IOPS ausliefern. Es ist interessant, dass es hier so Probleme gibt. Wir haben auf einem RAID 10 aus WD RE Festplatten ca. 400-500 Webseiten laufen absolut problemlos. Vielleicht haben hier die Kunden auch weniger Ansprüche.
Was genau macht denn der Kunde immer? Ist das ein Cronjob der Produkte in einer Artikeldatenbank aktualisiert oder was genau wird hier immer ausgelöst?
Die Kunden machen gar nichts, es sind zu 80% WordPress Webseiten, der Rest vermutlich Joomla,Nextcloud etc pp
Auch CronJobs werden nicht ausgeführt.
Ich kann es mir selbst nicht erklären warum das so ist, manche php-cgi Prozesse stören den Server nicht, und dann kommt wieder einer wo der I/O Wait verrückt spielt für 10 Sekunden und mehr, die Performance ist dann extrem schlecht wenn man mal eine Webseite aufruft.
Ich kann es leider auch nicht reproduzieren mal ist es Kunde X und mal Kunde Y wieder...
Ich sehe in der Konsole leider auch nur den php-cgi Prozess wenn der .wa Wert hoch fliegt.
Was heißt Ansprüche? Eigentlich nicht, allerdings erwartet natürlich jeder Kunde vernünftige Ladezeiten wenn er seine Seite aufruft, das ist auch oft der Fall, wenn nicht gerade ein I/O Wait Peak läuft.
Auch CronJobs werden nicht ausgeführt.
Ich kann es mir selbst nicht erklären warum das so ist, manche php-cgi Prozesse stören den Server nicht, und dann kommt wieder einer wo der I/O Wait verrückt spielt für 10 Sekunden und mehr, die Performance ist dann extrem schlecht wenn man mal eine Webseite aufruft.
Ich kann es leider auch nicht reproduzieren mal ist es Kunde X und mal Kunde Y wieder...
Ich sehe in der Konsole leider auch nur den php-cgi Prozess wenn der .wa Wert hoch fliegt.
Was heißt Ansprüche? Eigentlich nicht, allerdings erwartet natürlich jeder Kunde vernünftige Ladezeiten wenn er seine Seite aufruft, das ist auch oft der Fall, wenn nicht gerade ein I/O Wait Peak läuft.
Last edited by a moderator:
IP-Projects.de
Active Member
Ich hätte nochmal eine Idee. Schick mir bitte nochmal die Zugangsdaten per Mail. Eventuell kann man am Apache und den Max Workers noch etwas schrauben.
Es gibt Kunden - Obst und Gartenbauverein z.B., denen ist das schnuppe wenn die Seite mal 2 Sekunden lädt. Und es gibt Kunden die machen Firebug auf und fragen warum die Seite 0,5 Sekunden langsamer läuft Das meine ich mit Ansprüchen. Natürlich sollte jede Seite immer normale Ladezeiten haben.
Es gibt Kunden - Obst und Gartenbauverein z.B., denen ist das schnuppe wenn die Seite mal 2 Sekunden lädt. Und es gibt Kunden die machen Firebug auf und fragen warum die Seite 0,5 Sekunden langsamer läuft
Das meine ich mit Ansprüchen. Natürlich sollte jede Seite immer normale Ladezeiten haben.
A
andreas0
Guest
Welchen RAID-Controler setzt ihr auf euren Kunden- bzw. diesen Server ein?
Ich hätte nochmal eine Idee. Schick mir bitte nochmal die Zugangsdaten per Mail. Eventuell kann man am Apache und den Max Workers noch etwas schrauben.
Es gibt Kunden - Obst und Gartenbauverein z.B., denen ist das schnuppe wenn die Seite mal 2 Sekunden lädt. Und es gibt Kunden die machen Firebug auf und fragen warum die Seite 0,5 Sekunden langsamer läuft
Sind raus.
Nein ganz so schlimm ist es nicht, wenn der Peak nicht da ist sind die Ladezeiten auch wirklich top. Beim Peak allerdings muss man dann schon mal 5 Sekunden warten bis man überhaupt was sieht.
Ich sehe das selber auch am Monitoring einer Seite wo wir die Ladezeiten überwachen, das sind dann schon sehr große Unterschiede.
IP-Projects.de
Active Member
In den Systemen nichts großartiges - Adaptec 6805E. Ein RAID 1 noch als Backuppartition, KVM als Virtualisierungslayer mit aktuellem Kernel.
Und wir machen da sogar richtig I/O. Jeden Tag wird nach Viren gescanned, jeden Tag Backup auf eine externe Storage und die internen Backup Devices ...
A
andreas0
Guest
Könnt ihr denn Latenzprobleme bezüglich des Netzwerks zwischen eurem eventuell DSL-Provider und eurem Server schon mal ausschließen?
Weiterhin ist mir auch aufgefallen, dass auf eurer Abbildung mit TOP im ersten Beitrag auch ein Java-Prozeß läuft. Habt ihr Diesen auch mal intensiver in Bezug auf den GC beobachtet? Denn der GC ist nicht permanent aktiv, kann aber bei Aktivität sehr viele Ressourcen an sich reißen. Auch ist euer SWAP mit nur 512 MB aus meiner Sicht zu klein gewählt.
Last edited by a moderator:
Der Java Prozess soll wohl zum Raid gehören soweit ich das gesehen haben, warum der da immer läuft weiß ich nicht. Im htop steht nur das drin (siehe screenshot)
Nun bei 32GB Arbeitsspeicher der nicht mal 30% gefüllt ist denke ich brauch man kaum Swap, zumindest erkenne ich keinen Grund mehr Swap zu geben/nutzen.
@Michael
Wenn ihr da 400 Webseite betreibt und nichts besonders habt an Hardware und richtig I/O macht,muss bei uns ja irgendwas sein was extrem I/O frisst, den wir haben gerade mal 60 Kunden auf dem Server, eigentlich sollte sich der Server langweilen.
Nun bei 32GB Arbeitsspeicher der nicht mal 30% gefüllt ist denke ich brauch man kaum Swap, zumindest erkenne ich keinen Grund mehr Swap zu geben/nutzen.
@Michael
Wenn ihr da 400 Webseite betreibt und nichts besonders habt an Hardware und richtig I/O macht,muss bei uns ja irgendwas sein was extrem I/O frisst, den wir haben gerade mal 60 Kunden auf dem Server, eigentlich sollte sich der Server langweilen.
Attachments
Last edited by a moderator:
PHP-Friends
Active Member
iotop ist dein Freund
A
andreas0
Guest
Wie verhält sich euer System denn, wenn ihr diesen Java-Prozess testweise vorübergehend, um euer Problem noch weiter eingrenzen zu können, mal beendet? Denn ich glaube, dass der RAID-Controller seine Hauptaufgabe danach immer noch erledigen wird und nicht von diesem Java-Prozess abhängig sein wird.
Im Übrigen: Wenn der GC nicht gerade aktiv ist, wird man ihn auch nicht über iotop sehen können.
Das hatte ich vor den Prozess zu killen, allerdings hat man mir gesagt das man diesen nicht killen darf, von daher hab ich es auch nicht gemacht.
Natürlich schau bei iotop rein sobald ein Peak da ist, aber man sieht dort nicht wirklich viel, ich kann davon gerne nächstes mal einen Screenshot machen...
Natürlich schau bei iotop rein sobald ein Peak da ist, aber man sieht dort nicht wirklich viel, ich kann davon gerne nächstes mal einen Screenshot machen...
Attachments
Last edited by a moderator:
A
andreas0
Guest
Also, ich selber habe auch einen Root-Server mit einem RAID-Controller (6405E) von Adaptec bei IP-Projects gemietet. Bei mir auf meinem Root-Server läuft definitiv kein Java-Prozess, der für den RAID-Controller von Adaptec gedacht ist.
A
andreas0
Guest
Wenn ich mir deine Abbildung mit dem TOP-Auszug so anschaue, wurde dieser Java-Prozess per Hand nachträglich gestartet und wird nicht über den Dienst sysstemctl mit verwaltet bzw. gesteuert. Von daher gehe ich auch mal davon aus, dass dieser Java-Prozess auch ohne dein System zu beeinträchtigen einfach mal testweis vorübergehend beendet werden kann.
Lord Gurke
Nur echt mit 32 Zähnen
Wenn es immer die selben Kunden sind, bei denen diese Peaks auftreten, könntet ihr deren Homeverzeichnis einmal mit inotifywait "überwachen".
Mit "inotifywait -r -m /verzeichnis/" bekommt ihr live aufgelistet, welche Dateien wie gelesen oder geschrieben werden.
Vielleicht werden da ja irgendwelche riesengroßen Dateien verarbeitet. Falls die "browscap"-Erweiterung für PHP aktiviert ist, lohnt es sich auch mal dies testweise zu deaktivieren.
Mit "inotifywait -r -m /verzeichnis/" bekommt ihr live aufgelistet, welche Dateien wie gelesen oder geschrieben werden.
Vielleicht werden da ja irgendwelche riesengroßen Dateien verarbeitet. Falls die "browscap"-Erweiterung für PHP aktiviert ist, lohnt es sich auch mal dies testweise zu deaktivieren.