Apr 24, 2024, updated at Apr 25, 2024 (UTC)

714

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.

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

Please also mark the comments that contributed to the solution of the article

Content-Key: 21908196692

Url: https://administrator.de/contentid/21908196692

Printed on: May 4, 2024 at 13:05 o'clock

5 Comments

Latest comment

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".

Gruß

cykes

Zitat von @cykes:

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.

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

Zitat von @schrick:

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.

* 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 1
top - 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

German Question Linux Network

Hotly discussed

End of availability for classic Teams clientDani - 2 Comments

Ubuntu 24.04 LTS Noble Numbat availableFrank

Developer diary: Release 6.1admtech