Beiträge von [netcup] Felix P.

Wäre ein Terminal-Server eventuell interessanter? Wenn es darum geht von unterwegs auf eine Desktop-Umgebung zugreifen zu können, empfehle ich x2go (haben wir für das Homeoffice im Einsatz).

Vielen Dank für Ihr Feedback!

Wir versuchen da Support zu geben, wo es uns möglich ist. Was aber sollen wir machen, wenn Kunden schreiben "mein vServer laggt, bitte behebt das Problem"? Hier können wir nur um weitere Fakten bitten. Leider bleiben diese viel zu oft aus.

Fehler können nie ausgeschlossen werden. Fehler können aufgrund von Millionen verschiedenen Ursachen entstehen, sowohl auf der Seite des Kunden wie auch auf unserer Seite oder weil es einfach ein vServer ist, der besonders was die Festplattenzugriffszeiten angeht, nicht mit einem dediziertem Server mithalten kann.

Um die Ursache für einen Fehler finden zu können, ist es wichtig strukturiert an die Aufgabe heran zu gehen. Dieses fängt mit einer Analyse der Ressourcenauslastung an, geht über eine Logfileanalyse (für Lags sind z.B. gecrashte InnoDB-Tabellen eine häufige Ursache) und kann dann gerne bei einer Anfrage beim Support enden.

Wer nicht bereit ist sich mit seinem eigenem System auseinander zu setzen, dem können wir gerne ein Management inkl. Confixx für 25 Euro (inkl. MwSt.) Aufpreis zu jedem unserer vServer Angebote optional anbieten. Hier stellen wir dann nicht nur die Funktionalität des Wirtssystems sicher, sondern auch die des vServers. Wir bringen hierzu jahrelange Erfahrung mit und ein ausgereiftes Monitoring-System (auf den vServern die wir managen, können wir übrigens die mysteriösen Lags nicht feststellen, genau so wie das viele andere Kunden nicht nachvollziehen können).

Wir können nicht auf die Cronjobs unserer Kunden zugreifen, da dieses nicht erlaubt ist.

Was wir von unserem eigenem Monitoring sagen können:

Um 0 h und 6 h starten die meisten Jobs die Logs auswerten. Da Logs groß werden können, macht sich dieses oft auf den Festplatten bemerkbar.

Zitat

Aber könnte man nicht eine Grafik erstellen, die aus Erfahrung von den "Mitarbeitern" kommt? Das mann das einfach etwas "schätzt".

Wo nach sollen die Cronjobs geschätzt werden? Es gibt Cronjobs die ein Bit umlegen und welche die ein Backup von 200 GB Dateien packen und komprimieren.

Zitat

Wenn mann möchte schon *grins*

Nein, denn der Gesetzgeber verbietet dieses.

Artimis: Das sind mal brauchbare Fakten!

Aus diesen würde ich folgende Aussage ziehen: Alle 10 Minuten geht die Zugriffszeit auf die Festplatten (geteiltes System) hoch. Da Sie selber auf die Festplatten zugreifen, steigt auch die Load Ihres eigenen Systemes zu den Zeitpunkten an.

Auf die Systeme der Kunden haben wir keinen Zugriff.

Wenn die Software drumherum mitspielt, werden wir die Images so anpassen, dass für die Crons immer ein zufälliger Wert genommen wird. Dann kann vielleicht die Spitze in der Nacht vermieden werden. Allerdings sind momentan gut 3000 vServer mit den Werten am arbeiten, sprich das Ergebnis wird einige Zeit dauern.

Artimis: Naja, noch unwahrscheinlicher ist es, dass Ihr System von Dritten beeinflusst wird, wenn es noch alle Ressourcen zur Verfügung stehen hat. Sofern die Load unter 1 ist, stehen Ihnen mehr als genug Ressourcen zur Verfügung.

Bei uns gibt das Monitoring übrigens Alarm, sobald die Load auf einem Node über 1 ist. Das ist ein sehr frühes Warnsystem. Sobald die Load über 1 ist wird das System geprüft (mit Ausnahme zwischen 0 und 0:25 Uhr).

Zitat

Der komplette Server laggt.

Woher kommen die Lags?

Artimis: Wieso gehen Sie davon aus, dass ein anderes System Ihr System negativ beeinflusst? Steht Ihnen kein RAM oder keine CPU mehr zur Verfügung? Wie hoch ist die Load? Woher stammen die Lags?

Zu Asterisk: Bei VoIP ist eine Priorisierung der Pakete eine generelle Empfehlung. Bei uns im Büro würde VoIP nicht ohne Priorisierung funktionieren. Meldet sich Ihr System (rein zufällig) alle 10 Minuten am SIP-Server an?

Zitat

Was ich genauso feststellen kann ist, dass der Webserver (wenn lange nicht zugegriffen wurde) 2-3 Sekunden für eine Antwort benötigt, danach geht alles wieder in unter 100ms. Kann es sein, dass der unsichtbar vom Host geswapped wird?

Nein, alles was im RAM ist, ist auch im physikalischen RAM.

Wenn wirklich nichts auf Ihrem vServer los ist und SSH nicht korrekt arbeitet, wenden Sie sich doch bitte einmal an den Support. Dieser würde die Auslastung Ihres Systems prüfen und es dann test-halber auf einen anderen Node verschieben.

Bei Apache2 kann ich dieses Phänomen bestätigen. Es liegt aber nicht am vServer. Das tritt auch bei dedizierten Server auf.

Zitat

Dennoch treten Lags auf, die definitiv nicht von mir verursacht sind, sondern mit einfachster deduktiver Logik auf Cronjobs anderer vServer auf em Hostsystem zurückzuführen sind.

Sie bemängeln Fehler an einer VoIP-Softwarelösung die sehr stark danach aussehen, dass sie von einer nicht vorhandenen Paket-Priorisierung herrühren. Das hat nichts mit einem vServer an sich zu tun. Würden wir hier im Büro im Router die Priorisierung abschalten, könnten wir nicht mehr sauber telefonieren.

ice-breaker: Das besonders Nachts die Festplatten aufgrund von Logrotates und Backups ausgelastet sind, ist bei vServer die ein geteiltes Festplattensystem nutzen nicht vermeidbar. Die Lösung dafür ist meistens, dass man selber Logrotate z.B. um 8 Uhr Morgens ausführt. Da haben die Festplatten immer am wenigsten zu tun und man kann auch Nachts mit seiner anteiligen Zugriffsgarantie auf das Festplattensystem so zugreifen, dass gängige Aufgaben (Webserver, MySQL...) ohne Aussetzer arbeiten können. Ein vServer kostet weit aus weniger als ein Dedizierter Server, da hier Ressourcen geteilt werden.

Wenn es ganz schlimm mit dem IO-Wait ist (dieses bitte nachweisen), ziehen wir einen vServer auch gerne kostenlos auf einen anderen Node um. Uns muss aber verständlich gemacht werden, dass man als Kunde weiß wo die Probleme liegen und das Probleme seitens des Kunden (leider liegen die im Schnitt bei diesem), ausgeschlossen werden können.

Alex: Kaum arbeitet man mal im Homeoffice, langst du gut zu! Hast du ne Flat bei der Wurstbude ausgehandelt?

Logrotate? Weniger flexible Leistungen da andere vServer mehr aktiv sind?

Warum haben Sie noch immer nicht geprüft woher die Lags stammen? Wir können hier schlecht hellsehen. Würde so ein Beitrag beim Support eingehen, könnte er damit rein gar nichts anfangen.

Zitat

Auch die "Load average"-Anzeige ist nicht besonders hoch.

Diese ist interessant, wenn die Lags auftreten.

Das kann z.B. daran liegen, dass Ihnen neben den garantierten Leistungen, auch flexible Leistungen zur Verfügung stehen, wenn diese andere vServer nicht nutzen. Da es immer einige Zeit braucht, bis jeder Kunde seinen vServer voll nutzt, können später durchaus weniger flexible Leistungen als zu Beginn zur Verfügung stehen. Die garantierten Leistungen stehen immer zur Verfügung, wenn sie benötigt werden.

Des weiteren haben Sie eventuell zum besagten Zeitpunkt mehr Besucher gehabt als zu einem anderen.

Schauen Sie sich doch einfach Ihr System an und prüfen Sie woher die Lags kommen. Von alleine passiert auf einem System gar nichts.

Zitat

Wenn ein Prozess die Auslastung auf 100% hochbeföhrdert, muss der Prozess ja "viel" arbeiten.

So einfach ist das leider nicht. Es braucht nur ein Prozess die Festplatte blockieren (z.B. MySQL) und schon müssen die anderen warten.

Gameserver werden wir nicht verbieten. Wir haben viele Kunden die Gameserver problemlos betreiben. Man sollte allerdings nur das nutzen, von dem man weiß das es auch funktioniert. Gerade bei den Gameservern gibt es viele unsaubere Plugins, die von Menschen ohne genügend Kenntnisse "geproggt" wurden.

Zitat

Ausserdem müsste ja die Laufzeit bei dem jeweiligen Prozess bei "htop" rot sein - also das der Prozess die ganze Zeit arbeitet und "durchdreht".
Ist bei keinen Prozess der Fall.

Wieso müsste das Ihrer Meinung nach so sein?

Zitat

Vielleicht könnnntete, man ja das Sheduling ein wenig unter die Lupe nehmen, wenn von den garantierten Ressourcen manchmal gar nichts zu spüren ist.

Das wird rund um die Uhr per Monitoring überwacht. Mit einem Benchmark sollten Sie auch feststellen können, dass Ihnen die garantierte Leistung zur Verfügung steht. Sie scheinen die für VoIP empfohlene Paket-Priorisierung auf ein CPU-Problem zu reduzieren. Gerne führen wir kostenpflichtig eine Analyse durch, wie es zu dem von Ihnen geschilderten Problem kommt.