Hallo allerseits,
ich habe einen
DS1817+/Type2 - Board Product Name1, BIOS M.505 2017/05/09
mit
6.2.1-23824
auf dem bisher ohne Probleme mehrere Targets über iSCSI an einen HyperV exportiert wurden.
Das Gerät wird auch nur als iSCSI-Server verwendet.
Seit einen Backup (umkopieren großer Mengen auf einen anderen Fileserver) mit sehr hoher Leselast, sind zwei Targets in LUNs alter Art nur noch mit sehr geringer Bandbreite lesbar.
Probiert haben wir schon:
Auffällig ist, dass einige Kernel-Threads (kworker) fast kontinuierlich einen der vier CPU-Cores auslasten.
Schaut man mit iotop nach, sieht man, dass diese kworker relativ hohe Schreiblasten verursachen obwohl auf dem Gerät hauptsächlich gelesen wird.
Triggert man einen Backtrace sieht man fast immer folgendes:
Es wird also andauernd irgend ein Filedescriptor geschlossen und in Folge ein VFS Schreibzugriff durchgeführt.
Leider sind die Kernels in den *.pat-Dateien gestrippt so dass ich die Adressen nicht auflösen kann.
Die anderen drei Kerne tun meistens nichts.
Hat jemand eine Idee was hier vor sich geht?
ich habe einen
DS1817+/Type2 - Board Product Name1, BIOS M.505 2017/05/09
mit
6.2.1-23824
auf dem bisher ohne Probleme mehrere Targets über iSCSI an einen HyperV exportiert wurden.
Das Gerät wird auch nur als iSCSI-Server verwendet.
Seit einen Backup (umkopieren großer Mengen auf einen anderen Fileserver) mit sehr hoher Leselast, sind zwei Targets in LUNs alter Art nur noch mit sehr geringer Bandbreite lesbar.
Probiert haben wir schon:
- Target auf anderer Plattform lesen (Ubuntu Linux) ändert nichts. Auch dort sehr langsam.
- Target in neuem LUN zum testen erstellen, der läuft dann mit der üblichen Performance.
- DS1817+ neu starten ändert nichts
- /volume1 ist nicht annähernd voll, das kann es also auch nicht sein. Auch die einzelnen Targets haben alle Luft. Auch das löschen größerer Mengen ändert nichts.
Auffällig ist, dass einige Kernel-Threads (kworker) fast kontinuierlich einen der vier CPU-Cores auslasten.
Schaut man mit iotop nach, sieht man, dass diese kworker relativ hohe Schreiblasten verursachen obwohl auf dem Gerät hauptsächlich gelesen wird.
Triggert man einen Backtrace sieht man fast immer folgendes:
Rich (BBCode):
[55819.656300] SysRq : Show backtrace of all active CPUs
[55819.661955] sending NMI to all CPUs:
[55819.661963] NMI backtrace for cpu 1
[55819.661968] CPU: 1 PID: 29041 Comm: ash Tainted: P C O 3.10.105 #23824
[55819.661970] Hardware name: Synology Inc. DS1817+/Type2 - Board Product Name1, BIOS M.505 2017/05/09
[55819.661973] task: ffff8802735b6040 ti: ffff88023e27c000 task.ti: ffff88023e27c000
[55819.661976] RIP: 0010:[<ffffffff81283e8d>] [<ffffffff81283e8d>] delay_tsc+0xd/0x50
[55819.661984] RSP: 0018:ffff88023e27fe58 EFLAGS: 00000006
[55819.661986] RAX: 000000004e15eaa0 RBX: 0000000000002710 RCX: 0000000000000006
[55819.661989] RDX: 00000000000079c7 RSI: 0000000000000001 RDI: 0000000000249f74
[55819.661991] RBP: 0000000000000246 R08: 000000000000000a R09: 000000000000fffe
[55819.661993] R10: 0000000000000001 R11: 0000000000000615 R12: 0000000000000001
[55819.661995] R13: 0000000000000000 R14: ffffffff8183dd20 R15: 0000000000000000
[55819.661998] FS: 00007fb20211d700(0000) GS:ffff88027fc40000(0000) knlGS:0000000000000000
[55819.662000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[55819.662002] CR2: 00007f2ba56a2000 CR3: 00000001c93de000 CR4: 00000000001007e0
[55819.662004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[55819.662007] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[55819.662008] Stack:
[55819.662010] ffffffff81022e05 000000000000006c ffffffff812ed27a 0000000000000002
[55819.662015] fffffffffffffffb ffff88023e27ff20 00000000021e2808 0000000000000002
[55819.662019] ffffffff812ed6c6 ffff8802719ec9c0 ffffffff81162bae ffff88007ca40680
[55819.662023] Call Trace:
[55819.662030] [<ffffffff81022e05>] ? arch_trigger_all_cpu_backtrace+0x55/0x70
[55819.662035] [<ffffffff812ed27a>] ? __handle_sysrq+0xfa/0x160
[55819.662040] [<ffffffff812ed6c6>] ? write_sysrq_trigger+0x26/0x30
[55819.662045] [<ffffffff81162bae>] ? proc_reg_write+0x3e/0x60
[55819.662050] [<ffffffff810fd771>] ? vfs_write+0xc1/0x350
[55819.662055] [<ffffffff81121525>] ? __fd_install+0x15/0x40
[55819.662059] [<ffffffff810fed2c>] ? SyS_write+0x5c/0xb0
[55819.662063] [<ffffffff81121586>] ? __close_fd+0x16/0xd0
[55819.662068] [<ffffffff814b1dc4>] ? system_call_fastpath+0x22/0x27
[55819.662070] Code: 04 bf 48 c1 e0 02 f7 e2 48 89 d7 48 8b 05 0c 5f 5b 00 48 83 c7 01 ff e0 66 0f 1f 44 00 00 65 8b 34 25 1c e0 00 00 0f ae e8 0f 31 <89> c1 90 0f ae e8 0f 31 48 c1 e2 20 89 c0 48 09 c2 89 d0 29 ca
Leider sind die Kernels in den *.pat-Dateien gestrippt so dass ich die Adressen nicht auflösen kann.
Die anderen drei Kerne tun meistens nichts.
Hat jemand eine Idee was hier vor sich geht?