Hallo,
weshalb ein Backup sehr lange dauern kann, kann verschiedenste Ursachen haben.
Code: Select all
top - 16:50:01 up 13 days, 19:47, 1 user, load average: 1,10, 0,62, 0,26
Tasks: 132 total, 3 running, 129 sleeping, 0 stopped, 0 zombie
%Cpu0 : 1,3 us, 7,0 sy, 73,2 ni, 16,4 id, 0,3 wa, 0,0 hi, 0,3 si, 1,3 st
%Cpu1 : 0,0 us, 0,3 sy, 28,4 ni, 70,2 id, 0,3 wa, 0,0 hi, 0,0 si, 0,7 st
KiB Mem: 6115044 total, 5938944 used, 176100 free, 230284 buffers
KiB Swap: 12578812 total, 0 used, 12578812 free. 4419924 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9540 root 35 15 105256 13096 4300 R 100,4 0,2 0:07.34 7z
35 root 20 0 0 0 0 S 0,7 0,0 0:54.22 kswapd0
1248 root 20 0 790140 13988 6056 S 0,7 0,2 10:59.54 fail2ban-s+
21509 root 20 0 0 0 0 R 0,7 0,0 1:13.66 kworker/0:0
1 root 20 0 28920 5204 3116 S 0,3 0,1 3:05.31 systemd
439 root 20 0 49748 16340 13924 S 0,3 0,3 2:23.26 systemd-jo+
2 root 20 0 0 0 0 S 0,0 0,0 0:00.49 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:06.76 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:+
7 root 20 0 0 0 0 S 0,0 0,0 9:20.09 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0,0 0,0 0:03.50 migration/0
10 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 lru-add-dr+
11 root rt 0 0 0 0 S 0,0 0,0 0:03.94 watchdog/0
12 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0
13 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1
Lass uns kurz dein "top" zerlegen. Dein Server läuft mit ca. 55% Serverlast ( 110 loadaverage : 2 Kerne) wobei Kern 1 die höhere Last hat.
Kern 1 = CPU 0:
us: 1,3 - CPU-Nutzung von User-Prozessen
sy: 7,0 - CPU-Nutzung von System- und Kernel-Prozessen
ni: 73,2 - CPU-Nutzung von Prozessen, die keine Standard-Priorität besitzen
id: 16,4 - CPU im Leerlauf
wa: 0,3 - Zeit, welche die CPU durch I/O Zugriffe (bsp. Festplatte) warten muss
hi: 0,0 - Hardwareinterrrupts
si: 0,3 - Softwareinterrupts
st: 1,3 - stolen time (Zeit, die der physikalische Server anders vergibt, obwohl sie deiner virtuellen Maschine zugeordnet ist)
Wobei wir dann schon zum nächsten kommen: Du hast virtuelle CPU-Kerne und der Hypervisor bevorzugt einen anderen virtuellen Prozessor.
Zumal bei virtuellen CPU-Kernen nie die an dich vergebene Leistung bekannt ist, diese kann 90%, 80%, 70% eines physikalischen Kerns sein,
da der Rest für den Masternode reserviert ist.
Zum Prozess selbst:
PID: Prozess-ID 9540
USER: Der Benutzer, unter dessen Kennung der Prozess läuft bzw. gestartet wurde
PR: 35 - dynamische Priorität
NI: 15 - mit welcher Priorität der Prozess gestartet wurde
VIRT: 105256 - Virtueller Speicherverbrauch
RES: 13096 - Speicherverbrauch (RAM) des Prozesses (ohne Auslagerung)
SHR: 4300 - Der Speicher des virtuellen Speichers, der geshared werden kann
S: R - Prozess Status
%CPU: 100,4 - Prozentualer Zeitanteil der CPU für den Prozess
%MEM: 0,2 - Prozentualer Anteil des RAMs für den Prozess
TIME+: 7,34 - Die Gesamtzeit,die die CPU dem Prozess gewidmet hat
Alle Werte nahezu im grünen Bereich: Summasumarum gehts hier einfach nicht schneller.
Wäre z.B. die HDD zu langsam, würden sich die loadaverage erhöhen, bei wenig %us und hohem %wa, wobei der %wa Grenzwert mit der Faustformel 1/Prozessorkerne errechnen lässt. Wäre zu wenig RAM, würde sich dein swap-used Wert erhöhen, membuffers und memcached hingegen gegen 0 gehen, sowie ein höherer %wa Wert vorliegen, bei gleichzeitig hohem Load-Average.
LG nikko