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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 21908196692
Url: https://administrator.de/contentid/21908196692
Ausgedruckt am: 24.11.2024 um 18:11 Uhr
6 Kommentare
Neuester Kommentar
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
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.