6
Linux TGT iSCSI langsam
Moin,
ich nutze in einer Linux VM (Ubuntu Server) den tgt Dienst.
Die VM ist per 10G angebunden und hat zwei SSD's mit einer Größe von 2TB eingebunden und sonst noch 8 kleine mit 480GB oder so.
Darauf ist jeweils ein RAID und eine LUKS Verschlüsselung.
Die VM dient derzeit als "VSAN", also sie stellt per tgt (iSCSI) die Festplatten für mehrere vmWare ESXi Server über 10G bereit. Das funktioniert sehr gut, wenn die Linux VM gerade gestartet wurde und der RAM noch leer ist.
Die VM hat 20GB RAM und nutzt diesen bei der Verwendung von tgt sofort komplett aus, das heißt, das nach kurzer zeit nur noch etwa 700MB - 1GB frei sind und der Rest gechacht wird.
Mein Problem ist aber, das sobald der RAM vollständig genutzt wird, die iSCSI Verbindung extrem langsam ist und es mich derzeit sehr nervt.
Einmal war so viel last da, das der Server in dem OOM (Out of Memory) gelaufen ist und den tgt Dienst gekillt hat.
Man bemerke, das der Server die SSD Geschwindigkeit selten komplett ausnutzt, eigentlich nur, wenn der RAM leer ist, dann schreibt er auch sehr schnell auf die SSD's (laut Iostat).
Interessant ist dabei, das ich noch ne zweite VM habe, auf einem anderen Server, die auch Festplatten per tgt (iSCISI) bereit stellt und der diese Probleme nicht hat.
Diese werden dann auf einem anderen Linux System eingebunden, da die Festplatten ab und zu benötigt werden, aber nicht in den anderen passen usw.
Diese VM teilt über tgt einige HDD's, die, wenn man sie zusammenzählen würde, eine Größe von etwas mehr als 100TB haben.
Und diese VM läuft sehr performant und nutzt das limit der HDD's komplett aus, obwohl sie mit weniger RAM läuft, aber auch diese nutzt alles vom RAM:
Liegt das irgendwie an vmware ESXi, das die einfach ein Problem damit haben oder warum ist das nur da so langsam.
Die tgt config ist sehr basic, nur die LUN mit dem Namen und dem Geräte Pfad definiert, welche IP drauf Zugriff haben darf und das war's.
Liebe Grüße
ich nutze in einer Linux VM (Ubuntu Server) den tgt Dienst.
Die VM ist per 10G angebunden und hat zwei SSD's mit einer Größe von 2TB eingebunden und sonst noch 8 kleine mit 480GB oder so.
Darauf ist jeweils ein RAID und eine LUKS Verschlüsselung.
Die VM dient derzeit als "VSAN", also sie stellt per tgt (iSCSI) die Festplatten für mehrere vmWare ESXi Server über 10G bereit. Das funktioniert sehr gut, wenn die Linux VM gerade gestartet wurde und der RAM noch leer ist.
Die VM hat 20GB RAM und nutzt diesen bei der Verwendung von tgt sofort komplett aus, das heißt, das nach kurzer zeit nur noch etwa 700MB - 1GB frei sind und der Rest gechacht wird.
root@iscsi-vsan:/home/jj# free -h
total used free shared buff/cache available
Mem: 19Gi 807Mi 184Mi 1,0Mi 18Gi 18Gi
Swap: 3,8Gi 75Mi 3,7Gi
root@iscsi-vsan:/home/jj#
root@iscsi-vsan:/home/jj# systemctl status tgt
● tgt.service - (i)SCSI target daemon
Loaded: loaded (/lib/systemd/system/tgt.service; disabled; vendor preset: enabled)
Active: active (running) since Wed 2024-04-03 20:44:22 UTC; 3 weeks 0 days ago
Docs: man:tgtd(8)
Main PID: 2733 (tgtd)
Status: "Starting event loop..."
Tasks: 33
Memory: 16.9G
CPU: 1d 15h 55min 52.400s
CGroup: /system.slice/tgt.service
└─2733 /usr/sbin/tgtd -f
.....
root@iscsi-vsan:/home/jj# Mein Problem ist aber, das sobald der RAM vollständig genutzt wird, die iSCSI Verbindung extrem langsam ist und es mich derzeit sehr nervt.
Einmal war so viel last da, das der Server in dem OOM (Out of Memory) gelaufen ist und den tgt Dienst gekillt hat.
Man bemerke, das der Server die SSD Geschwindigkeit selten komplett ausnutzt, eigentlich nur, wenn der RAM leer ist, dann schreibt er auch sehr schnell auf die SSD's (laut Iostat).
Interessant ist dabei, das ich noch ne zweite VM habe, auf einem anderen Server, die auch Festplatten per tgt (iSCISI) bereit stellt und der diese Probleme nicht hat.
Diese werden dann auf einem anderen Linux System eingebunden, da die Festplatten ab und zu benötigt werden, aber nicht in den anderen passen usw.
Diese VM teilt über tgt einige HDD's, die, wenn man sie zusammenzählen würde, eine Größe von etwas mehr als 100TB haben.
Und diese VM läuft sehr performant und nutzt das limit der HDD's komplett aus, obwohl sie mit weniger RAM läuft, aber auch diese nutzt alles vom RAM:
root@iscsi-diskarray:/home/jj# free -h
total used free shared buff/cache available
Mem: 9,7Gi 590Mi 741Mi 1,0Mi 8,4Gi 8,8Gi
Swap: 3,8Gi 36Mi 3,8Gi
root@iscsi-diskarray:/home/jj#
root@iscsi-diskarray:/home/jj# systemctl status tgt
● tgt.service - (i)SCSI target daemon
Loaded: loaded (/lib/systemd/system/tgt.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2024-04-06 12:19:43 UTC; 2 weeks 4 days ago
Docs: man:tgtd(8)
Main PID: 2831 (tgtd)
Status: "Starting event loop..."
Tasks: 113
Memory: 8.6G
CPU: 5d 8h 9min 6.468s
CGroup: /system.slice/tgt.service
└─2831 /usr/sbin/tgtd -f
.....Liegt das irgendwie an vmware ESXi, das die einfach ein Problem damit haben oder warum ist das nur da so langsam.
Die tgt config ist sehr basic, nur die LUN mit dem Namen und dem Geräte Pfad definiert, welche IP drauf Zugriff haben darf und das war's.
Liebe Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 21908196692
Url: https://administrator.de/contentid/21908196692
Ausgedruckt am: 09.11.2024 um 01:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
was mir spontan beim Status des betroffenen Servers aufgefallen ist:
Bei der anderen VM steht da "enabled".
Gruß
cykes
was mir spontan beim Status des betroffenen Servers aufgefallen ist:
(Zeile 9) (/lib/systemd/system/tgt.service; disabled; vendor preset: enabled)
Bei der anderen VM steht da "enabled".
Gruß
cykes
Zitat von @cykes:
Moin,
was mir spontan beim Status des betroffenen Servers aufgefallen ist:
Bei der anderen VM steht da "enabled".
Moin,
was mir spontan beim Status des betroffenen Servers aufgefallen ist:
(Zeile 9) (/lib/systemd/system/tgt.service; disabled; vendor preset: enabled)
Bei der anderen VM steht da "enabled".
Moin,
ja das ist mit Absicht so, damit die vmware ESXi Server nicht probieren sich schon auf etwas zu verbinden was noch nicht existiert.
Da ich zuerst das LUKS Volumen entschlüsseln muss und dann erst tgt zulassen will.
Hi.
Danke für die Infos.
Gruß Schrick
Mein Problem ist aber, das sobald der RAM vollständig genutzt wird, die iSCSI Verbindung extrem langsam ist und es mich derzeit sehr nervt.
Sorry aber diese Aussage sagt uns hier so viel wie wenn du einer Autowerkstatt sagst "Mein Auto quietscht sagt mir warum."- Was bedeutet für dich "Langsam" in Zahlen? Zugriffszeiten, Datenübertragungsrate?
- Wer verbindet sich mit dem Target?
- Aus anderem Subnetz/VM/Blech?
- Wir sehen die virtuellen NIC Settings aus?
- Ist zufällig das Hardware Offloading oder ReceiveSideScaling in der VM aktiv?
- MTU Size?
- Wie sieht ein Wireshark Trace während einer Übertragung aus?
- Hardware Unterbau, NIC Typen, verwendete Treiber sehen dort wie aus?
- Was sagt ein "top" zum Zeitpunkt?
- Wie sieht die DiskIO und swap zu diesem Zeitpunkt aus?
Danke für die Infos.
Gruß Schrick
1Zitat von @12764050420:
Hi.
Sorry aber diese Aussage sagt uns hier so viel wie wenn du einer Autowerkstatt sagst "Mein Auto quietscht sagt mir warum."
Muss zu meiner Verteidigung sagen, das ich manche Infos schon genannt habe, vielleicht nicht viel, aber es war nicht nichts.Hi.
Sorry aber diese Aussage sagt uns hier so viel wie wenn du einer Autowerkstatt sagst "Mein Auto quietscht sagt mir warum."
* Was bedeutet für dich "Langsam" in Zahlen? Zugriffszeiten, Datenübertragungsrate?
Alles, die Datenübertragung ist mickrig und auch die Zugriffszeit ist nicht besonders schnell.
Es wechselt mal hin und her, ich erlebe Momente wo die Zugriffszeit so lange braucht, das ich mich nicht mal mehr unter einer Minute mich per SSH auf eine VM rauf schalten kann, wenn auf der Platte gearbeitet wird.
Und mal lösche ich nen Snapshot und kann neben bei noch Daten verschieben etc. ohne Probleme, bis der RAM voll ist.
Finde es halt sehr ungewöhnlich, das er so viel RAM frisst.....
* Wer verbindet sich mit dem Target?
Wie gesagt "vmware ESXi Server", insgesamt 4 Stück* Aus anderem Subnetz/VM/Blech?
Ja, wie man das normal macht, anderes Netz mit VLAN und immer auf dem vmware ESXi Server.Halt als Datastore für die VM's
* Wir sehen die virtuellen NIC Settings aus?
Es ist ein VLAN wo nur die Server und die VSAN drin ist, es sind maximal 254 Clients möglich....Was genau willst du wissen?
10G Glasfaser, 5 Clients (4 Server und 1 mal die VSAN)
* Ist zufällig das Hardware Offloading oder ReceiveSideScaling in der VM aktiv?
Ich habe sowas auf Default gelassen, das waren doch die Teile, die ich per ssh eingeben muss?* MTU Size?
Auch alles auf den Standardwerten gelassen, frag mich nicht auf was das steht.* Wie sieht ein Wireshark Trace während einer Übertragung aus?
Das habe ich nicht geprüft, werde ich noch machen* Hardware Unterbau, NIC Typen, verwendete Treiber sehen dort wie aus?
Verbindungsgeschwindigkeit:10000 Mbps
Treiber:
ixgben
HP 560SFP+ Intel X520-DA2 2-port 10Gbe Network LP
* Was sagt ein "top" zum Zeitpunkt?
jj@iscsi-vsan:~$ top -o %MEM -b -n 1top - 13:05:48 up 21 days, 16:23, 1 user, load average: 0,00, 0,03, 0,05
Tasks: 362 total, 1 running, 361 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,5 us, 0,5 sy, 0,0 ni, 99,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
MiB Mem : 20114,5 total, 252,9 free, 796,9 used, 19064,6 buff/cache
MiB Swap: 3889,0 total, 3815,0 free, 74,0 used. 18946,7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
799 root rt 0 420940 27908 9072 S 0,0 0,1 2:50.18 multipathd
84490 root 20 0 325136 16828 9304 S 0,0 0,1 33:34.28 python3
1365 root 20 0 2058804 15140 6100 S 0,0 0,1 1:37.13 snapd
762 root 19 -1 56084 13408 12232 S 0,0 0,1 0:14.04 systemd-journal
1926 root 20 0 295588 12784 11028 S 0,0 0,1 0:10.98 packagekitd
92465 root 20 0 17184 10624 8456 S 0,0 0,1 0:00.04 sshd
1 root 20 0 166668 10316 6764 S 0,0 0,1 0:31.40 systemd
1418 root 20 0 109752 9404 7996 S 0,0 0,0 0:00.03 unattended-upgr
1373 root 20 0 393600 8488 6112 S 0,0 0,0 0:14.05 udisksd
92544 jj 20 0 17316 7800 5404 S 0,0 0,0 0:00.06 sshd
1368 root 20 0 17288 7140 4720 S 0,0 0,0 0:03.42 systemd-logind
1360 root 20 0 32732 6640 5252 S 0,0 0,0 0:00.03 networkd-dispat
1330 systemd+ 20 0 25540 6408 4900 S 0,0 0,0 0:03.58 systemd-resolve
1416 root 20 0 15440 6224 5420 S 0,0 0,0 0:00.00 sshd
2733 root 20 0 276796 6004 2796 S 0,0 0,0 2424:20 tgtd
* Wie sieht die DiskIO und swap zu diesem Zeitpunkt aus?
Swap steht oben schon in der "free -h" Ausgabe.DiskIO:
4,00 36,0k 0,0k 36,0k 0,0k sdb
14,00 356,0k 0,0k 356,0k 0,0k sdc
Ist immer nur im kb Bereich wenn der RAM voll is.
Und sonst sowas:
106,00 0,0k 53,0M 0,0k 53,0M sdb
109,00 8,0k 53,5M 8,0k 53,5M sdc
Danke für die Infos.
Ich habe zu danken
Moin,
gibt es denn vielleicht auf den ESXi Hosts irgendwelche Warnungen/Fehler, die auf den iSCSI Pfad verweisen?
Welche ESXi Version kommt zum Einsatz?
Gruß
cykes
gibt es denn vielleicht auf den ESXi Hosts irgendwelche Warnungen/Fehler, die auf den iSCSI Pfad verweisen?
Welche ESXi Version kommt zum Einsatz?
Gruß
cykes
Der Arbeitsspeicher (RAM) ist bei Linux nach einiger Zeit immer voll, da alles gecached wird, was jemals gelesen oder geschrieben wurde. Dein Gefühl sagt also, dass es nur solange gut läuft, bis der Arbeitsspeicher voll ist.
Wenn du also "sync" eingibst, dauert es länger (einige Sekunden), bis der Befehl zurückkommt?
Ist der Cache zum Schreiben ("write_back") aktiv? Ist es gewünscht? (Datenverlust bei Stromausfall...)
Haben beide Systeme verschlüsselte Festplatten? Hat die virtuelle CPU Support für die verwendete Verschlüsselung, prüfen z.B. mit "cat /proc/cpuinfo|grep -i aes" ?
Die VMs (auf denen tgt läuft), sind die mit VMWare ESX oder KVM (Ubuntu) virtualisiert? Und warum nicht direkt auf Hardware?
Und die Platten sind im Virtualisierunghost mit SCSI oder SATA oder PCIe angebunden, und nicht etwas über ein weiteres Netzwerk?
Neben Durchsatz (MB/s) würde ich mir noch die IOPS anschauen. Auch wenn auf dem Papier SSDs das 100-fache an IOPS gegenüber HDDs schaffen, ist es bei Virtualisierung oft weniger, da nicht so viel parallel läuft und die Latenzen höher sind. Nicht umsonst wird bei QEMU 9.0.0 als erstes "block: virtio-blk now supports multiqueue where different queues of a single disk can be processed by different I/O threads" hervorgehoben (QEMU version 9.0.0 released). Weiterhin müssen die Daten im VM-Host nochmal umkopiert werden, was auch etwas Performance kostet.
Wenn du also "sync" eingibst, dauert es länger (einige Sekunden), bis der Befehl zurückkommt?
Ist der Cache zum Schreiben ("write_back") aktiv? Ist es gewünscht? (Datenverlust bei Stromausfall...)
Haben beide Systeme verschlüsselte Festplatten? Hat die virtuelle CPU Support für die verwendete Verschlüsselung, prüfen z.B. mit "cat /proc/cpuinfo|grep -i aes" ?
Die VMs (auf denen tgt läuft), sind die mit VMWare ESX oder KVM (Ubuntu) virtualisiert? Und warum nicht direkt auf Hardware?
Und die Platten sind im Virtualisierunghost mit SCSI oder SATA oder PCIe angebunden, und nicht etwas über ein weiteres Netzwerk?
Neben Durchsatz (MB/s) würde ich mir noch die IOPS anschauen. Auch wenn auf dem Papier SSDs das 100-fache an IOPS gegenüber HDDs schaffen, ist es bei Virtualisierung oft weniger, da nicht so viel parallel läuft und die Latenzen höher sind. Nicht umsonst wird bei QEMU 9.0.0 als erstes "block: virtio-blk now supports multiqueue where different queues of a single disk can be processed by different I/O threads" hervorgehoben (QEMU version 9.0.0 released). Weiterhin müssen die Daten im VM-Host nochmal umkopiert werden, was auch etwas Performance kostet.
