I/O-Last legt System lahm

    Hallo,


    mit einem
    dd if=/dev/zero of=/root/out.file
    kann ich mein System so sehr beschäftigen, dass es kaum noch nutzbar ist.
    Ist das normal?
    Ich habe das auf zwei Systemen getestet, jeweils Ubuntu 12.04. Auf Beiden ist das der Fall.


    Ich bin auf das Problem gekommen, da ich beim Transfer mit scp von dem einen auf den anderen Rechner eine hohe load hatte. Mit obigem Befehl wollte ich es einschränken.


    Bei obigem dd-Befehl ist ja klar, dass die Platte gut zu tun hat, aber beim scp kommen nur 30-50MB/s über das Netzwerk. Die Platte ist eine Notebook-Platte, aber das sollte ja handlebar sein. Und selbst wenn: Warum wird das System dadurch so lahm gelegt?


    Unten noch ein Output von Iostat.


    Gruß,
    Hendrik


    Moin,


    ich hatte genau dieses Verhalten auf einem "geerbten" PC (älteres AMD-System mit einer einzelnen SATA HD).
    Schon bei mäßiger IO-Last wurde das ganze System extrem lahm.


    Ich habe nach ewiger Bastelei incl. BIOS Update etc. als letztes Mittel eine IDE-Platte dazugesteckt, neu formatiert und die Daten der SATA darauf kopiert, incl. Betriebssystem. Danach lief das System richtig.


    Bei der Bastelei habe ich zufällig festgestellt, dass die SATA-Platte "seltsam" partitioniert war, mit "krummen" Partitionsgrenzen. Nach einer Neupartitionierung lief diese Platte wieder schnell und ohne den Rechner auszubremsen.


    Eine Erklärung dafür habe ich nicht, aber es schadet sicher nicht, mal die Partitionierung zu prüfen.


    Wolfgang

    MSI C847MS-E33, Cine S2 6.0, Zotac GT630 (GK208), dual boot
    Work: yaVDR 0.7 ansible Ubuntu 22.04. Backup: yaVDR 0.5 Ubuntu 12.06


    Eine Erklärung wäre, wenn die Platte intern mit 4K Sektoren arbeitet.
    Dann sollte man die Partitionen an "vernünftigen" Grenzen ausrichten.


    Lars.

    Hallo zusammen,
    ich habe diesen Thread zum Anlaß genommen, meine Partitionen zu checken, da ich häufiger eine Systemlast > 2.0 beim Login per putty vom system mitgeteilt bekam.
    ich hatte bisher immer (Interrupt-) Probleme mit dem gleichzeitigen Betrieb von drei Cine2 vermutet.
    Ein align-check mit parted zeigte mir, dass ich beim letzten Umzug des Systems auf neuere Hardware mit u.a. neuer HD mit 4K-Sektoren geschlampt hatte.
    Meine "Auffüll-Partition" (sda1) war blöderweise nur 1000KByte groß statt 1024KByte. Damit hatte ich das missalign-Problem nicht beseitigt. Da aber zunächst alles lief, habe ich dort nicht wieder gesucht.
    Habe nun die Platte mit gparted magic umpartitioniert und die Mini-Partition am Anfang der Platte gelöscht, da die aktuellen Versionen von gparted magic die 4k-Sektoren bereits per default berücksichtigen.
    Da ich die /etc/fstab nicht angepasst hatte, lag die swap-Partiton nach dem nächsten reboot mehr auf /dev/sda3 sondern auf /dev/sda2. Das System startet aber mit einer Fehlermeldung trotzdem scheinbar problemlos (aber ohne swap).
    Auf Pro7HD kam es aber zu regelmäßigen Artefakten, ohne dass in den zugehörigen Logs direkte Hinweise auf die beteiligten Komponenten zu finden waren.
    Die Probleme waren dann aber schnell ganz massiv da, als ein zweiter vompclient den VDR etwas mehr forderte.
    Im Syslog konnte ich nur Meldungen von "thread ended..(pid=..tid=..)" finden, der VDR startete immer neu, um sich kurz darauf wieder zu verabschieden.


    1. Beobachtung: ohne Swap macht das System Probleme, welche sich zunächst nicht ohne weiteres zuordnen ließen.


    2. Beobachtung: Nachdem ich die Einträge in der fstab korrigiert hatte waren die Probleme verschwunden. Der Start der Swap-Partition lag nun ebenfalls auf 4k Sektoren.


    Vermutung: Auch, oder vielleicht sogar gerade, beim Swap macht sich vermutlich die durch das missalignment verdoppelte Zugriffszeit auf die ausgelagerten RAM-Pages drastisch bemerkbar.


    Bisher sind noch keine der sonst bei höherer Last (mehrere Aufnahmen gleichzeitig) zeitweilig auftretenden Buffer overflows aufgetreten.


    Falls man bei manueller Partition insbesondere beim Kopieren von "alten Partitionen" von ehemals 512byte Sektoren HDDs nicht aufpasst, kann es auch passieren, dass zwar das eigentliche System korrekt auf einem 4K_sektorstart beginnt, eine irgendwo anders im system liegende swap-Partition aber dennoch missaligned ist und damit das swappen nur halb so schnell wie möglich macht.


    ich habe mein System 'mal gekloned und werde diese Problematik bei Gelegenheit mit wechselnden Swap-Partitionen (1x alligned , 1x missaligned) weiter untersuchen.
    Die Systemlast liegt nun dauerhaft unter 1.0
    cu

    ASUS H87-PRO (Intel G3220+4GB RAM), 3x PCI-E CineS2 Dual DBS2 Ver. 5.5,
    64bit Ubuntu 16.04.4 LTS-Server, VDR 2.3.8 (mit DDCI2+streamdevserver+vompserver+vnsiserver)
    Diskless-Clienten: 4x Raspberry-Pi als Vomp-client in HD, 2x Fire TV (Stick und Box) mit Kodi per VNSI
    DVB-S-Radio per streamdev + externremux + ffmpeg + mpd auf Internetradios (mit Reciva-Barracuda-Chipsatz)


    Hab's gerade auch hier mal unter Ubuntu 12.04 mit einem ca. 6-1/2 Jahre alten dual-Core AMD und 2GB RAM getested: Eine CPU geht laut 'xosview' auf dauerhaft 100%, ich kriege ca. 60MB/sec als Datentransfer hin (auch laut 'xosview').
    Da scheint bei dir was im argen zu liegen... Aendert sich das Verhalten, wenn du an das dd... Kommando auch eine groessere Blocksize haengst (z.B. 1M)?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden