Posts by jbr27

    [...]
    Warum greift man nicht auf ressourcensparsame Audiochats wie den guten alten TeamSpeak Server zurück? Läuft lokal auf dem Rechner oder per App auf dem Smartphone. Für Screensharing von einer oder zwei Parteien kann man dann ja immer noch auf andere Tools zurückgreifen.

    [...]

    Du wirst lachen - wir kommunizieren seit 2 Wochen nur noch über meinen Teamspeak-Server, den ich eigentlich vor Monaten schonmal offline nehmen wollte.


    Sogar eine Verteidigung einer Abschlussarbeit (wir sind ein Forschungsinstitut) wurde schon darauf durchgeführt.


    Bei Präsentationen (oder Screensharing) nutzen wir BigBlueButton nur für den Videostream. Der Ton läuft weiterhin über TeamSpeak, da wir subjektiv die Audioqualität besser finden.


    P.S. Animal Crossing New Horizons hat mich momentan auch im Griff :‘D.

    Ist die Aussage immernoch gültig?

    Ich habe gerade die Antwort vom Support erhalten, dass Mining auf aktuellen Root-Servern / VPS nicht erlaubt ist und man mit der Bestellung von neuen Produkten auch die aktualisierten AGB akzeptiert.

    Vor 30 Minuten wurde ein weiterer Server von mir neugestartet (Zwischenstand: 2 von 6).


    Beides waren sanfte Shutdowns per ACPI. Die laufenden LXC-Container hatten genug Zeit um sauber herunterzufahren (nach 30-45 Sekunden hatten beide Server ihren Shutdown bereits abgeschlossen). Nach weiteren 20 Minuten wurden beide Server ohne Probleme wieder hochgefahren.


    Ich habe die Vermutung, dass die Server nach Preismodell oder Bestelldatum abgearbeitet werden. Nach meinem RS2000 (gestern Abend um 23 Uhr) wurde heute um 16 Uhr mein RS1000 neugestartet. Meine VPS10, VPS20, VPS50 usw. wurden noch nicht beachtet.

    Entweder beanspruche ich die plötzlich stärker, oder die mit neuem Logo halten weniger aus… :D


    Bei meiner Netcup-Tasse von der letzten Aktion an Ostern hatte ich nach einem Monat normaler Benutzung auch bereits den Henkel einzeln in der Hand :D. Habe leider keine alte Version der Tasse als Vergleich.

    Gesagt, getan. Heute angeschrieben und wenig später hat man mir schon geholfen. :thumbsup:
    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 ?(.

    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.

    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.

    • BTRFS als Dateisystem Unterbau verwenden
    • Ich klink mich raus.


    BTRFS läuft auf meinem Testsystem mit LXC-Containern seit einem halben Jahr ohne Probleme. Hätte ich jetzt hunderte an Kunden oder eine große Firma, würde ich sicherlich auch konservativer an die Sache herangehen. Für unser Familienunternehmen (< 10 Mitarbeiter) hält sich das Risiko (mit Backups) in Grenzen.


    Hätte ich jetzt bereits BTRFS auf dem Produktivsystem, wären die Container schon längst auf einen neuen Server migriert und das Problem damit behoben.

    Falls einer mir einen trifftigen Grund nennen kann, sowas machen zu wollen mit wohlgemerkt produktiven Zeug, dann lasse ich mich da gerne eines besseren belehren.


    Auf meinem Server laufen zurzeit jeweils in einem einzelnen LXC-Container:
    - DNS (bind)
    - Git (gogs)
    - Mail (Mailcow (dovecot, postfix, nginx, php5-fpm))
    - munin
    - sharelatex (docker, mongodb, redis-server)
    - GPS-Tracking für Flottenmanagement (traccar)
    - web (nginx, php7.0-fpm, mysql-server)


    Für jeden Container sind nur die benötigten Ports per iptables freigeben. Die Kommunikation untereinander erfolgt in einem internen Netz.
    Für die Zukunft ist noch der Umstieg auf BTRFS geplant, womit die Container besser schneller gesichert werden können.
    Bei kritischen Updates kann der Container geklont oder ein Snapshot angelegt werden. Läuft etwas schief, kann ohne merkliche Downtime alles zurückgespielt werden.


    Wenn BTRFS jeweils auf dem Haupt- und Backupsystem vorhanden ist, können die Container in Sekunden umgezogen werden (Wartungsarbeiten, neuer Server, usw.)


    Zumindest für meine Bedürfnisse habe ich mit meinem Lösungsweg bisher nur gute Erfahrungen sammeln können. Schöner wären natürlich einzelne vServer oder ein richtiger dedizierter Server. Das alles würde aber deutlich mehr als 12,99€ im Monat kosten.

    Nochmal zurück zum eigentlichen Thema:


    Eine Defragmentierung hat leider auch keine Verbesserung der Disk Latency bewirkt. Zur Zeit logge ich mit atop mal alle Prozesse mit, habe aber zu den "Spitzenzeiten" noch keinen Schuldigen gefunden.
    Da es ein Produktivsystem ist, kann ich leider erst nächstes Wochenende nachts mal das Rettungssystem booten und die Disk Latency überprüfen.

    Ich habe seit dem 19. November ähnliche Probleme mit meinem Server (RS2000 G7 SE). Ohne irgendetwas verändert zu haben, hat sich die Disk Latency drastisch erhöht. Auch ein Neustart oder das Stoppen aller LXC-Container hat zu keiner Verbesserung geführt. Wahrscheinlich beansprucht ab dem 19. November ein anderer Kunde sehr viel "Festplattenleistung" auf dem Node. Ich beobachte dieses Verhalten noch eine Weile. Momentan sind mir noch keine längeren Ladezeiten für meine Anwendungen aufgefallen. Daher sieht es nur auf dem Papier besorgniserregend aus.


    Anbei mal einige Munin-Diagramme von meinem betroffenen System.

    Habe für ZFS eine Auto-Snapshot-Rotation gebastelt.
    Jemand Lust das mal zu testen?
    Wenn Interesse besteht git'e ich das mal.


    Ich habe gerade etwas ähnliches mit BTRFS anstatt ZFS gebastelt. Wäre also potentiell interessiert ;).

    Btrfs wird kommen, keine Frage, aber man muss es ja nicht überstürzen. Ich sammel lieber erst einmal Erfahrung mit unwichtigen Dingen in einer VM zu Hause. Für ein Produktivsystem ist mir das aktuell zu gefährlich.


    Vielen Dank für deine Antwort! Ich zögere ja (leider) auch noch. Die Funktionalität der Snapshots im Zusammenhang mit btrfs send / receive erleichtern den Backup-Prozess von LXC-Containern natürlich ungemein. Ebenso könnte vor kritischen Umstellungen / Updates einfach ein Snapshot (in unter einer Sekunde) angelegt werden. Bei ordnerbasierten LXC-Container kann dieser Schritt schon Stunden dauern und ist mit Downtime für den Container verbunden.


    Wie ist deine Einschätzung zu ZFS (auf Linux) als Alternative bis BTRFS ein wenig gereift ist? Zumindest Ubuntu scheint ja momentan eher auf ZFS zu setzen.