Vielleicht nehme ich es auch zu Emotional dann verstehe ich nicht zwingend alles.
Trotzdem vielen Dank für deine Meinung! Damit ist die Offtopic-Diskussion beendet.
Vielleicht nehme ich es auch zu Emotional dann verstehe ich nicht zwingend alles.
Trotzdem vielen Dank für deine Meinung! Damit ist die Offtopic-Diskussion beendet.
Skulduggery
Die Virtualisierungstechnologie LXC und auch OpenVZ darf man nicht mit der Vollvirtualisierungstechnologie, wie z.B. KVM oder VMware verwechseln. Denn diese Virtualisierungstechnologien sind eher ein besseres chroot, die selber so gut wie keine zusätzlichen Ressourcen benötigen.
Ich selber nutzte auch - aufgrund der schon durch jbr27 genannten Vorteile - auf meinem virtuellen Server OpenVZ 7 und bin mit der Leistung der einzelnen virtuellen OpenVZ-Container voll und ganz zufrieden.
Um zum Thema zurück zu kommen: Gibt es schon weitere Erkenntnisse? Auf meinem Server kann ich seit einigen Tagen auch beobachten, dass offenbar Festplattenzugriffe plötzlich teilweise extrem langsam sind und Prozesse sehr lange darauf warten müssen. Im Extremfall dauert dadurch der Aufruf diverser PHP Skripte (die noch nicht im Opcode-Cache sind) mehrere Sekunden.
Das tritt allerdings erst seit einigen Tagen auf und dauert manchmal nur Minuten bis zu knappen Stunde, dann rennt es wieder wie gewohnt. Gibt es da irgendeine handhabe dagegen oder muss ich einfach damit leben, dass hier offenbar ein »Nachbar« alle Ressourcen zeitweilig für sich beansprucht?
Wenn wir zum Ausgangsthema zurückkehren: Was ist beim OP Mittwoch kurz nach 12 Uhr gelaufen? Dort gibt es für eine längere Zeit einen Unterschied (hohe IOWait bei gleichzeitig erhöhten Durchsatz).
Ist dieser Prozess auch für einige weitere Ausschläge verantwortlich?
... Gibt es da irgendeine handhabe dagegen oder muss ich einfach damit leben, dass hier offenbar ein »Nachbar« alle Ressourcen zeitweilig für sich beansprucht?
Da du dir die Ressourcen auf dem Host mit weiteren Kunden teilst und Diese eventuell auch nicht per Hard-Quota für jeden einzelnen Kunden begrenzt werden bzw. sind, wirst du mit diesem Problem leider leben müssen.
Eventuell bringt es was, wenn du mal den Support direkt wegen diesem Problem anschreibst.
Ich habe bis jetzt keinen kritischen Prozess finden können, der für die schlechte Performance verantwortlich ist.
Gerade habe ich nochmals alle Services (apache2, mysql, postfix, dovecot, munin-node, seafile) gestoppt und ein sysbench laufen lassen:
sysbench --test=fileio --file-total-size=10G --file-test-mode=rndrw --init-rng=on --max-time=600 --max-requests=0 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Initializing random number generator from timer.
Extra file open flags: 0
128 files, 80Mb each
10Gb total file size
Block size 16Kb
Number of random requests for random IO: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.
Operations performed: 2623 Read, 1748 Write, 5504 Other = 9875 Total
Read 40.984Mb Written 27.312Mb Total transferred 68.297Mb (116.56Kb/sec)
7.28 Requests/sec executed
Test execution summary:
total time: 600.0017s
total number of events: 4371
total time taken by event execution: 388.4892
per-request statistics:
min: 0.01ms
avg: 88.88ms
max: 11807.24ms
approx. 95 percentile: 397.97ms
Threads fairness:
events (avg/stddev): 4371.0000/0.00
execution time (avg/stddev): 388.4892/0.00
Alles anzeigen
Was ich mit htop und iotop beobachten konnte ist, dass die Belastung während des Benchmarks wirklich nur sehr gering scheint. Es ist sekundenlang kein io sichtbar, dann mal einige kbit/sek. Dasselbe gilt für die Prozessornutzung.
Zum Vergleich der gleiche Test auf einem anderen Server
Time limit exceeded, exiting...
Done.
Operations performed: 77327 Read, 51551 Write, 164864 Other = 293742 Total
Read 1.1799Gb Written 805.48Mb Total transferred 1.9665Gb (3.3562Mb/sec)
214.79 Requests/sec executed
Test execution summary:
total time: 600.0049s
total number of events: 128878
total time taken by event execution: 572.6604
per-request statistics:
min: 0.00ms
avg: 4.44ms
max: 483.32ms
approx. 95 percentile: 19.97ms
Threads fairness:
events (avg/stddev): 128878.0000/0.00
execution time (avg/stddev): 572.6604/0.00
Alles anzeigen
Das bedeutet für mich, das es "außerhalb" meines Systems zu starken Verzögerungen kommen muss. Anders kann ich mir das nichr erklären. Morgen werde ich Kontakt zum Support aufnehmen.
Viele Grüße
Wenn ich das hier so lese, dann wird ein richtiger dedizierter Server der nur für mich arbeitet, irgendwie schmackhafter.
Guten Tag,
ich habe den Beitrag jetzt nicht im Detail verfolgt. Allerdings kann ich denke ich eine Empfehlung für unsere neuen Root-Server in der SSD Variante aussprechen. Bei diesen gibt es deutlich bessere IO-Performance als in den vorangegangenen SSD oder gar SAS Modellen.
Unverbindliche Tests sind im Rahmen der Zufriedenheitsgarantie machbar.
Viele Grüße
Felix Preuß
Mein zusätzliches Logging mit atop hat ebenfalls ein paar "Schuldige" hervorbringen können.
Zuallererst muss ich Skulduggery Recht geben, dass der Treiber vermutlich nicht mit den LXC-Containern auf einem bereits virtualisierten Hostsystem zurecht kommt. Ebenfalls mit der Ausführung des Monitorings auf dem zu überwachenden Server, lag er richtig.
Die hohe Disk-Latenz tritt ausschließlich dann auf, wenn alle LXC-Container (natürlich gleichzeitig :D) ihre Prozesse ausführen und dann noch zusätzlich die jeweiligen Graphen in einem weiteren Container erzeugt werden. Ja, nicht gerade schlau von mir gelöst, aber aus der Mangel an einem weiteren Server, zurzeit nicht anders möglich.
Ebenfalls erzeugt Spamassassin während seines Trainings (sa-learn) eine recht hohe Festplattenauslastung.
Zusammengefasst treten die Spitzen über den Tag verteilt vielleicht für 20-30 Minuten auf und Munin verschafft sich zu seinen Messzeitpunkten selbst eine hohe Disk-Latenz.
Hol dir doch die 19 cent Krücke und bau da dein Monitoring hin und gut ist, meinet wegen kann ich mir auch die 2,49€ Kiste mieten und Check_Mk drauf schmeissen und dir einen Zugang geben. Alles besser als das was momentan bei dir läuft Natürlich kannst du auch Felix seinen Rat folgen das Uneffiziente Zeug nehmen und auf Hardware schmeissen das Uneffizient schnell macht...
Hol dir doch die 19 cent Krücke und bau da dein Monitoring hin und gut ist, meinet wegen kann ich mir auch die 2,49€ Kiste mieten und Check_Mk drauf schmeissen und dir einen Zugang geben. Alles besser als das was momentan bei dir läuft Natürlich kannst du auch Felix seinen Rat folgen das Uneffiziente Zeug nehmen und auf Hardware schmeissen das Uneffizient schnell macht...
https://www.netcup.de/bestellen/produkt.php?produkt=1539
Vielen Dank für's Angebot! Habe selbst noch einen VPS50 von der damaligen Aktion, den ich momentan nur als sekundären Nameserver (keine Sorge ohne LXC und BTRFS) verwende. In der nächsten freien Zeit werde ich die Munin-Instanz darauf umziehen und schauen, ob er das noch zusätzlich packt.
Wobei es mich nicht wundern wurde, wenn die kleinen VPS-Kisten für Munin zu schwach sind…
MfG Christian
Eventuell bringt es was, wenn du mal den Support direkt wegen diesem Problem anschreibst.
Gesagt, getan. Heute angeschrieben und wenig später hat man mir schon geholfen.
Nun liegen die Zugriffszeiten auf die Platte wieder im grünen Bereich.
Gesagt, getan. Heute angeschrieben und wenig später hat man mir schon geholfen.
Nun liegen die Zugriffszeiten auf die Platte wieder im grünen Bereich.
Ich habe gestern Abend ebenfalls mal den Support angeschrieben. Mir wurde mitgeteilt, dass keine Störung an meinem Node vorliegt, ich aber einmalig auf ein anderes System migriert werden könnte. Dieses habe ich aber abgelehnt, da ich den Fehler zuerst noch genauer analysieren will.
Nunja, auf wundersame Weise hat sich die Disk-Latenz direkt nach meiner Korrespondenz mit dem Support drastisch verbessert und liegt nun wieder bei den Werten vor der Störung. Ich habe euch ein paar Munin-Graphen angehängt.
Da der Support angeblich nichts gemacht hat, bin ich jetzt etwas verwundert ?(.
Auch ich habe den Support kontaktiert und nachdem "einige Verbesserungen durchgeführt" wurden, läuft wieder alles wie geschmiert.
Besten Dank auch an dieser Stelle an Netcup!