Ich bin gerade dabei, Daten in LUKS-Partitionen zu migrieren. Nachdem das Betriebssystemlaufwerk nun über LUKS läuft, habe ich versucht, mit der Migration der Datenlaufwerke zu beginnen. Dann reagierte der Server nicht mehr.
Dieses LUKS-Gerät wurde geöffnet:
cryptsetup luksOpen /dev/sdc data1
Und einer dieser Befehle hat den Server abgewürgt:
pv /dev/zero > /dev/mapper/data1
pv /dev/zero > /dev/sdc
Nicht sofort, aber innerhalb von Sekunden wurde der Server unbrauchbar langsam. Alles war bei I/O blockiert:
root@node51 [~]# ps aux | awk '{if($8~"D"||$8=="STAT"){print $0}}'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1197 0.0 0.0 0 0 ? D 06:39 0:00 [jbd2/dm-1-8]
root 1687 0.1 0.0 0 0 ? D 11:15 0:12 [kworker/u96:5]
root 13057 2.0 0.0 0 0 ? D 13:10 0:01 [dmcrypt_write]
root 13644 10.9 0.0 7452 784 pts/1 D+ 13:10 0:08 pv /dev/zero
root 14159 0.0 0.0 98256 6836 ? DNs 13:10 0:00 sshd: root [priv]
root 14772 0.0 0.0 29008 92 ? D 13:11 0:00 /usr/sbin/CRON -f
root 14773 0.0 0.0 98256 6748 ? DNs 13:11 0:00 sshd: root [priv]
root 15411 0.0 0.0 98256 6876 ? DNs 13:11 0:00 sshd: root [priv]
root 16009 0.1 0.0 98256 6840 ? DNs 13:11 0:00 sshd: root [priv]
root 16632 0.5 0.0 98256 6892 ? DNs 13:11 0:00 sshd: root [priv]
root 16900 0.0 0.0 5448 356 pts/3 D+ 13:11 0:00 awk {if($8~"D"||$8=="STAT"){print $0}}
root 28553 0.6 0.0 0 0 ? D 12:12 0:21 [txg_sync]
Bemerkenswert ist, pvdass etwa zwei Sekunden lang gemeldet wurde, dass Daten mit mehr als kopiert wurden 2GiB/s. Dies liegt daran, dass sowohl der Rückschreibcache als auch die schmutzigen Seiten voll sind (gefunden durch Überwachung von /proc/meminfo).
Anschließend pvwurde eine normale 200MiB/sSchreibgeschwindigkeit aufgezeichnet, der Vorsprung im Write-Back-Cache lag jedoch immer noch zwischen 2GiBund .3GiB
Die durchschnittliche Serverauslastung stieg aufgrund der zahlreichen E/A-Blockierungen über 10,00.
Das Abbrechen des Schreibtests dauert eine Weile pv, da der Rückschreibcache geleert werden muss. Direkt nach dem Abbruch des Tests normalisierte sich die Serverleistung jedoch wieder.
Interessanterweise verursachen diese Befehle keine Verzögerungen auf dem Server:
# Reads from dm-crypt block device
pv /dev/mapper/data1 > /dev/zero
# Reads from the raw block device
pv /dev/sdc > /dev/zero
# Writes to a control disk of a different model
pv /dev/zero > /dev/sdi
# Reads from a control disk
pv /dev/sdi > /dev/zero
# Writes to a file on a dm-crypt ext4 filesystem on a solid-state drive
pv /dev/zero > /tmp/empty
# Reads from that same solid-state drive
pv /dev/sda > /dev/zero
Ich habe folgende Fragen:
- Warum verlangsamen anhaltende sequenzielle Schreibvorgänge auf diese Datenfestplatte den Server so stark?
- Wie kann ich eine Überlastung der anderen Festplatten vermeiden, wenn ich auf eine oder mehrere bestimmte Festplatten schreibe?
- Warum verursacht dieser Festplattentyp Leistungsprobleme, andere Laufwerke jedoch nicht?
Ich muss sechs Festplatten desselben Modells ( /dev/sdc, /dev/sdd, /dev/sde, /dev/sdf, /dev/sdg, und /dev/sdh) verschlüsseln, und auf ihnen werden künftig sequenzielle Schreiblasten anfallen. Deshalb möchte ich nicht, dass der Server durch dieses Problem ins Stocken gerät.
Weitere Informationen
Schnelle Fakten
Server: Dell PowerEdge T320
Kernel: Linux node51 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Betriebssystem: Ubuntu Server 16.04 LTS Xenial Xerus 64-Bit
Problematische Festplatte: Toshiba PH3500U-1I72
Ich habe sechs dieser Festplatten, von denen ich weiß, dass sie alle in Ordnung sind. Ich habe zwei davon getestet und bei beiden einen serverweiten I/O-Leistungsabfall festgestellt. Sie lesen und schreiben fast 200MiB/sam Anfang.
Kontrolle (problemlose) Festplatte: Samsung SP1614C
Diese Festplatte hat eine dauerhafte Schreibgeschwindigkeit von 50MiB/s. Könnte es sein, dass die problematische Festplatte zu schnell ist?
Festplattencontroller: Dell PERC H310
An diesen Controller werden zwei Solid-State-Drives und sechs problematische Festplatten angeschlossen, die alle direkt als AHCI durchgeschaltet werden. Die Steuerfestplatte wird an einen im Mainboard verbauten SATA-Port angeschlossen.
E/A-Scheduler
root@node51 [/tmp]# tail -n +1 /sys/block/sd*/queue/scheduler
==> /sys/block/sda/queue/scheduler <==
noop [deadline] cfq
==> /sys/block/sdb/queue/scheduler <==
noop [deadline] cfq
==> /sys/block/sdc/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdd/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sde/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdf/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdg/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdh/queue/scheduler <==
[noop] deadline cfq
==> /sys/block/sdi/queue/scheduler <==
noop [deadline] cfq
Das Ändern des Schedulers von auf /dev/sdcmacht keinen erkennbaren Unterschied. Das Ändern des Schedulers auf scheint die Verzögerung etwas zu verringern, aber die E/A-Vorgänge auf den anderen Festplatten litten weiterhin darunter.noopdeadlinecfq
vm.dirty*Kernel-Parameter
root@node51 [~]# sysctl -a | grep 'vm.dirty'
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
Beispiele für erkannte und protokollierte Verlangsamungen/var/log/syslog
ZFS-Transaktionsgruppensynchronisierung:
May 11 19:28:44 node51 kernel: [ 4080.179688] INFO: task txg_sync:3179 blocked for more than 120 seconds.
May 11 19:28:44 node51 kernel: [ 4080.179905] Tainted: P O 4.4.0-22-generic #39-Ubuntu
May 11 19:28:44 node51 kernel: [ 4080.180110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 19:28:44 node51 kernel: [ 4080.180357] txg_sync D ffff88060b68baa8 0 3179 2 0x00000000
May 11 19:28:44 node51 kernel: [ 4080.180362] ffff88060b68baa8 ffff880616a96d00 ffff8806133ea940 ffff880603dc2940
May 11 19:28:44 node51 kernel: [ 4080.180366] ffff88060b68c000 ffff880616ad6d00 7fffffffffffffff ffff88056cb8c508
May 11 19:28:44 node51 kernel: [ 4080.180368] 0000000000000001 ffff88060b68bac0 ffffffff818211f5 0000000000000000
May 11 19:28:44 node51 kernel: [ 4080.180372] Call Trace:
May 11 19:28:44 node51 kernel: [ 4080.180381] [<ffffffff818211f5>] schedule+0x35/0x80
May 11 19:28:44 node51 kernel: [ 4080.180385] [<ffffffff81824315>] schedule_timeout+0x1b5/0x270
May 11 19:28:44 node51 kernel: [ 4080.180390] [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180395] [<ffffffff810c33b2>] ? __wake_up_common+0x52/0x90
May 11 19:28:44 node51 kernel: [ 4080.180398] [<ffffffff81820744>] io_schedule_timeout+0xa4/0x110
May 11 19:28:44 node51 kernel: [ 4080.180412] [<ffffffffc05afbec>] cv_wait_common+0xbc/0x140 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180416] [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 19:28:44 node51 kernel: [ 4080.180423] [<ffffffffc05afcc8>] __cv_wait_io+0x18/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180487] [<ffffffffc071320e>] zio_wait+0x10e/0x1f0 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180528] [<ffffffffc069ce66>] dsl_pool_sync+0x2c6/0x430 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180573] [<ffffffffc06b85b6>] spa_sync+0x366/0xb30 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180576] [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180623] [<ffffffffc06c9a4a>] txg_sync_thread+0x3ba/0x630 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180669] [<ffffffffc06c9690>] ? txg_delay+0x180/0x180 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180676] [<ffffffffc05aae31>] thread_generic_wrapper+0x71/0x80 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180682] [<ffffffffc05aadc0>] ? __thread_exit+0x20/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180686] [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 19:28:44 node51 kernel: [ 4080.180688] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 19:28:44 node51 kernel: [ 4080.180692] [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 19:28:44 node51 kernel: [ 4080.180694] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
ext4-Journal:
May 11 20:46:46 node51 kernel: [ 6000.186474] INFO: task jbd2/dm-2-8:1148 blocked for more than 120 seconds.
May 11 20:46:46 node51 kernel: [ 6000.193164] Tainted: P O 4.4.0-22-generic #39-Ubuntu
May 11 20:46:46 node51 kernel: [ 6000.199950] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 20:46:46 node51 kernel: [ 6000.208323] jbd2/dm-2-8 D ffff88060a6e7c98 0 1148 2 0x00000000
May 11 20:46:46 node51 kernel: [ 6000.208330] ffff88060a6e7c98 0000000000000246 ffff8806133eb700 ffff88060b561b80
May 11 20:46:46 node51 kernel: [ 6000.208333] ffff88060a6e8000 ffff88060aeb68b8 ffff88060a6e7d88 ffff88060a6e7d70
May 11 20:46:46 node51 kernel: [ 6000.208336] ffff88060b561b80 ffff88060a6e7cb0 ffffffff818211f5 ffff8805fd6af900
May 11 20:46:46 node51 kernel: [ 6000.208339] Call Trace:
May 11 20:46:46 node51 kernel: [ 6000.208355] [<ffffffff818211f5>] schedule+0x35/0x80
May 11 20:46:46 node51 kernel: [ 6000.208361] [<ffffffff812ea0e0>] jbd2_journal_commit_transaction+0x240/0x1870
May 11 20:46:46 node51 kernel: [ 6000.208365] [<ffffffff810b6be1>] ? dequeue_entity+0x431/0xa80
May 11 20:46:46 node51 kernel: [ 6000.208368] [<ffffffff810b774a>] ? dequeue_task_fair+0x51a/0x8a0
May 11 20:46:46 node51 kernel: [ 6000.208372] [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208378] [<ffffffff810ec5fe>] ? try_to_del_timer_sync+0x5e/0x90
May 11 20:46:46 node51 kernel: [ 6000.208381] [<ffffffff812ef32a>] kjournald2+0xca/0x250
May 11 20:46:46 node51 kernel: [ 6000.208384] [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208387] [<ffffffff812ef260>] ? commit_timeout+0x10/0x10
May 11 20:46:46 node51 kernel: [ 6000.208391] [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 20:46:46 node51 kernel: [ 6000.208394] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6000.208397] [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 20:46:46 node51 kernel: [ 6000.208399] [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6292.776357] perf interrupt took too long (2539 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Antwort1
Die Steuerfestplatte ist an einen im Motherboard integrierten SATA-Anschluss angeschlossen.
Wie bereits erwähnt sind die Festplatten, bei denen es zu Timeout-Problemen beim Leeren des Journals kommt, mit dem PERC verbunden, demselben Controller, an den auch die „problematischen“ Toshibas angeschlossen sind.
Die PERC 310 ist nur eine einfache Hardware-RAID-Karte. Ihre CPU ist wahrscheinlich leicht überlastet, entweder das oder es liegt ein Firmware-Fehler vor. Direktes AHCI ist keine sehr verbreitete Verwendung.
Ich würde vorschlagen, dass die IO auf dem PERC blockiert ist und nicht auf dem Betriebssystem.
Antwort2
Das ist eine Menge, die man verdauen muss.
Sie verwenden ZFS, daher besteht eine gute Chance, dass dies ein Problem mit den 5-TB-Festplatten in Ihrem Pool und möglicherweise Ihrem Pool-Setup ist.
Dabei kann es sich um Festplatten mit 4.000 Sektoren handeln. Daher sollten Sie bei Ihrem ZFS-Setup entsprechende Anpassungen vornehmen.
Können Sie Ihre df -h, fdisk -l, zpool list, zpool status -vund zfs list-Ausgabe bereitstellen?
Antwort3
Ich denke, Ihr Schreibcache ist im Vergleich zu Ihren Blockgerätegeschwindigkeiten zu groß. Ich würde Folgendes vorschlagen:
vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 20
Legen Sie niemals beide Werte fest, da der zuletzt festgelegte Wert gewinnt. Darüber hinaus können einige Linux-Kernelversionen einen Fehler aufweisen, bei dem die Einstellung *_bytesnicht wie vorgesehen funktioniert. Ich würde empfehlen, sie immer zu verwenden.*_ratio*_ratio*_bytes
Leider sind die Schreibcache-Einstellungen meines Wissens global. Daher wird der Durchsatz zu Ihren schnelleren Geräten etwas leiden, wenn Sie die globale Schreibcache-Größe aufgrund eines langsamen Geräts reduzieren müssen.