iSCSI sehr geringe Bandbreite auf einzelnen LUNs

Status
Für weitere Antworten geschlossen.

mhgu

Benutzer
Mitglied seit
16. Okt 2018
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
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:
  1. Target auf anderer Plattform lesen (Ubuntu Linux) ändert nichts. Auch dort sehr langsam.
  2. Target in neuem LUN zum testen erstellen, der läuft dann mit der üblichen Performance.
  3. DS1817+ neu starten ändert nichts
  4. /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
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?
 

mexx81

Benutzer
Mitglied seit
17. Dez 2013
Beiträge
597
Punkte für Reaktionen
0
Punkte
42
Das ist mal ein übles Problem. Positiv ist, dass Du ermitteln kannst, dass der Fehler nach den großen Dateitransport aufgetaucht ist. Ich kann sagen, dass wir ebenfalls via iSCSI die Synology als Backupserver nehmen.

4 Netzwerkinterfaces:
1 Management
3 iSCSI

3 iSCSI Targets mit einen LUN

alle 3 iSCSI Targets via iSCSI Initiator verbunden und einzel die 3 iSCSI Interfaces des Windowsservers zugewiesen.

Wir erreichen sehr hohe Bandbreiten.

Also schließe ich ein allgemeinen Fehler auch aus und teile Deine Meinung, dass es etwas mit den Dateitransport hat.

Ich rate Dir an dieser Stelle echt dazu ein Ticket bei Synology zu öffnen. Das werden Dir nur die Jungs per Fernwartung lösen können.
 

mhgu

Benutzer
Mitglied seit
16. Okt 2018
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Hallo mexx81, wir haben ein Ticket bei Synology geöffnet. Das Problem ist nur, das die LUN mit deren Helpdesk scheinbar noch langsamer ist als unsere :rolleyes:
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat