zip überlastet CPU

[saxandl]

ich starte nächtes eine Richerungs-Routine, die u.a. zip-archive erstellt.

der zip-prozess (tar z) allerdings belastet die cup dermaßen, dass das System dem collaps nahe ist:
timeout-errors, etc.

und das, obwhol der zip-prozess "nice -n 20" gestartet wurde.

gibt es eine CPU-schonendere Alternative zu tar oder eine andere Möglichkeit, die CPU-Last zu beschränken?

[rendegast]

Einmal dürfte/sollte es keine Fehler geben -> Hardware testen.

nice -n 20

Müßte es nicht 'nice -n 19' sein?
Im allgemeinen reicht 'nice'.
'top', 'htop'

dass das System dem collaps nahe ist:
timeout-errors, etc.

Was für timeouts, Netzwerk, Platten-IO, Logs?
Größe des Jobs, geht es um 10GB auf einem 500MHz, Stunden?

Große zip-Jobs beschleunigen klappt häufig durch Spielen mit der Kompressionsrate.

[saxandl]

Einmal dürfte/sollte es keine Fehler geben -> Hardware testen.

ist getestet und IO

Müßte es nicht 'nice -n 19' sein?
Im allgemeinen reicht 'nice'.
'top', 'htop'

nice reicht imo von -20 hohe Priorität bis +20 = niedrige Priorität

Was für timeouts, Netzwerk, Platten-IO, Logs?
Größe des Jobs, geht es um 10GB auf einem 500MHz, Stunden?

z.b. (aus dem gedächtnis):

Code: Alles auswählen

task miniserv.pl:3764 blocked for more than 120 seconds.
echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables

Job (beispiel): file 177GB.tar => 38GBtar.gz
auf 8 core i7-2600 - Dauer ca. 70min

[whisper]

Schon mal den Arbeitsspeicher beobachtet?
Wieviel RAM hat die Kiste? poste mal deine fstab, vielleicht ist ein tmp Verzeichnis am Ende, df -h während des Laufes mal öfter absetzen

[tex]

die CPU ist hier nicht das problem sondern das io subsystem (platte(n), controller, etc.).

hol dir schneller platten oder versuch mal ionice. nice bringt hier nichts. außerdem beeinflußt nice ja auch nur die relative auslastung. wenn sonst keine anderen prozesse laufen würde das immer noch 100% cpu "ziehen".

[saxandl]

Schon mal den Arbeitsspeicher beobachtet?
Wieviel RAM hat die Kiste? poste mal deine fstab, vielleicht ist ein tmp Verzeichnis am Ende, df -h während des Laufes mal öfter absetzen

32GB

fstab:

Code: Alles auswählen

proc /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/md/0 none swap sw 0 0
/dev/md/1 /boot ext3 defaults 0 0
/dev/md/2 / ext4 defaults 0 0
/dev/md/3 /home ext4 defaults 0 0

df

Code: Alles auswählen

Filesystem            Size  Used Avail Use% Mounted on
/dev/md2             1016G  266G  700G  28% /
tmpfs                  16G     0   16G   0% /lib/init/rw
udev                   16G  164K   16G   1% /dev
tmpfs                  16G     0   16G   0% /dev/shm
/dev/md1              496M   38M  434M   8% /boot
/dev/md3              1.7T  477G  1.2T  30% /home

[whisper]

Ja, sieht nach IO Waits aus. das siehst du in htop übrigens auch ganz gut.
Um da was zu optimieren, könnte man mit dem Blocking Faktor experimentieren. Sowohl Filesystem als auch tar Optionen.

Code: Alles auswählen

     -b, --blocking-factor BLÖCKE
           BLÖCKE x 512 Byte pro Datensatz

[rendegast]

task miniserv.pl:3764 blocked for more than 120 seconds.

Der entsprechende Abschnitt:

Code: Alles auswählen

# run_logout_script(username, sid, remoteip, localip)
sub run_logout_script
{
if ($config{'logout_script'}) {
        alarm(5);
        $SIG{'ALRM'} = sub { die "timeout" };
        eval {
                system($config{'logout_script'}.
                       " ".join(" ", map { quotemeta($_) || '""' } @_).
                       " >/dev/null 2>&1 </dev/null");
                };
        alarm(0);
        }
}

Das aufgerufene Skript:

Code: Alles auswählen

$ cat /usr/share/webmin/record-logout.pl
#!/usr/bin/perl
# Write an actions log for a logout

BEGIN { push(@INC, ".."); };
use WebminCore;

&init_config();
($username, $sid, $remoteip) = @ARGV;
if ($username && $sid && $remoteip) {
        $WebminCore::remote_user = $remote_user = $username;
        $main::session_id = $sid;
        $0 = "miniserv.pl";
        &webmin_log("logout", undef, undef, undef, "global", undef,
                    undef, $remoteip);
        }

Muß das wirklich mit dem per nice laufenden Komprimieren zusammenhängen?
('nice -n20' wird auf einen nice-Wert 19 umgedeutet, also die niedrigste Priorität 39)

Läuft miniserv.pl vielleicht auch mit geringer Priorität?
Dann vielleicht dessen nice-Wert niedriger / Priorität höher ansetzen.


Läuft webmin mit dem miniserv.pl, oder ist über einen anderen Webserver realisiert?
(Idee wäre, daß miniserv.pl gar nicht laufen sollte.)


Gibt es zu dem Zeitpunkt vielleicht kernelbug-Meldungen im syslog?
(bei einem thread im www)
Ginge dann wieder in die Hardware-Ecke, oder vielleicht Treiber/Kernel-Problem.

Code: Alles auswählen

smartctl -a /dev/sdX