Utilizace disku zahlcuje celý server

[Darkhunter]

Zdravím,
popravdě nevím, která to je kategorie - jestli hardware nebo software, protože nevím, kde je chyba.
Máme server, kde nám běží 4xNVME v LVMraidech po dvou, na tom nám běží Linux s Dockerem.
Problém je, že máme load pořád větší, než počet CPU a celkově to, co na serveru běží, není snappy.
Koukal jsem, že load vysoký, ale všechno je to na IOwaitu.
Koukal jsem na iotop i další utilitky a IO bylo maximálně v jednotkách MB. To by měly NVME disky ustát.
Pak jsem řešil s chatgpt a to mi poradilo asi 40 věcí, ale žádná nepomohla.
Zapnul jsem si pak utilitku sar, kde vidím, že má jeden disk daleko větší load než ostatní, ale když jsou to stejné disky nvme2+nvme3, tak by měly mít jiný load? Také se děje, že občas je to v pořádku, ale většinou dost špatné. Ten inkriminovaný disk má ve smartu všechno v pořádku a dokonce i speedtest byl ok...
Sar mi printí toto(3 z 5 zobrazení vysoký load několika lvs a jednoho disky, 2 z 5 nulový load všude):

Kód: [Vybrat]

14:00:19          DEV       tps     rkB/s     wkB/s     dkB/s   areq-sz    aqu-sz     await     %util
14:00:24      nvme3n1     20.00      0.00     87.20      0.00      4.36      0.03      1.06      1.14
14:00:24      nvme1n1     18.60      0.00     82.40      0.00      4.43      0.02      0.68      1.00
14:00:24      nvme2n1     35.80      0.00    553.60      0.00     15.46     14.11    306.36    112.80
14:00:24      nvme0n1     39.40      0.00    572.00      0.00     14.52      0.23      5.03      1.54
14:00:24         dm-0      6.00      0.00     12.00      0.00      2.00      0.04      6.43    108.06
14:00:24         dm-1     55.80      0.00    560.00      0.00     10.04      0.21      3.81     44.14
14:00:24         dm-2      4.20      0.00      8.00      0.00      1.90      2.34    556.05    100.00
14:00:24         dm-3     54.00      0.00    545.60      0.00     10.10     14.41    266.85     99.88
14:00:24         dm-5      4.00      0.00      8.00      0.00      2.00      0.01      1.80      0.74
14:00:24         dm-6     14.20      0.00     64.00      0.00      4.51      0.00      0.06      0.06
14:00:24         dm-7      4.00      0.00      8.00      0.00      2.00      0.01      1.85      0.72
14:00:24         dm-8     14.20      0.00     64.00      0.00      4.51      0.00      0.04      0.06
14:00:24         dm-4    107.80      0.00   1091.20      0.00     10.12    308.78   2864.39    100.00
14:00:24         dm-9     28.20      0.00    128.00      0.00      4.54      0.00      0.09      0.08
14:00:24        dm-10      5.20      0.00     25.60      0.00      4.92      0.01      2.69      0.34
14:00:24        dm-11      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14:00:24        dm-12      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14:00:24        dm-13      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14:00:24        dm-14      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14:00:24        dm-15      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14:00:24        md127      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

Nevíte, co by s tím mohlo být? Už to řeším hrozně dlouho a na nic jsem nepřišel...
Díky!

[Reklama]

[RDa]

Co to je za raid konfiguraci? Mas tam funkcni trim?

Jaky je model disku a jsou disky spravne chlazeny?

Osobne bych kazdy disk vyradil z raidu, udelal trim, provedl fio test zamereny na latence, udelal trim, vratil do raidu.

[jjrsk]

Jestli to jsou soho disky koupeny nekde v garazi, tak bych se podobnymu chovani vubec nedivil. Podle toho jak to popisujes, tak je jeden disk vyrazne horsi, a kdyz ho das do raidu, tak na nej ten raid chte nechte musi cekat.

Jinak na MB/s nesejde, to co potrebujes znat jsou IOps.

[skrivy]

nvme2n1 tipuju, že je nakopnutý (nebo ošoupaný). Zkusil bych ho vyměnit.

Pošli sem výpis ze smartu.

[marder]

Zkus fstrim a pokud to nepomůže vyměnit ten podezřelý disk.
Je potřeba ale i monitorovat teploty těch disků, aby byla jistota že nezpomalují kvůli přehřívání.

[Reklama]

[Darkhunter]

Jsou to max 6 měsíců starý disky. Mají najeto asi 50TBW s tím, že mají mít 4kTBW životnost. Modely zjistím zítra.
Když jsem naposledy dělal fstrim, tak to pomohlo. Ale jen na chvilku...Teď mám zaplý fstrim jednou týdně.

[Darkhunter]

Co to je za raid konfiguraci? Mas tam funkcni trim?

Jaky je model disku a jsou disky spravne chlazeny?

Osobne bych kazdy disk vyradil z raidu, udelal trim, provedl fio test zamereny na latence, udelal trim, vratil do raidu.

Je to RAID1, takže to by bylo dost složité. Zkusím to flo.

[Darkhunter]

Jestli to jsou soho disky koupeny nekde v garazi, tak bych se podobnymu chovani vubec nedivil. Podle toho jak to popisujes, tak je jeden disk vyrazne horsi, a kdyz ho das do raidu, tak na nej ten raid chte nechte musi cekat.

Jinak na MB/s nesejde, to co potrebujes znat jsou IOps.

Jasně, že na MB/s nesejde, ale i to IO je dost nízké...A ze zápisu v rámci kb/s taky neuděláš extra IO.

[Darkhunter]

Tak ještě posílám SMART

Kód: [Vybrat]

=== START OF INFORMATION SECTION ===
Model Number:                       Lexar SSD NM790 4TB
Serial Number:                      NHG456R000109P2202
Firmware Version:                   12237
PCI Vendor/Subsystem ID:            0x1d97
IEEE OUI Identifier:                0xcaf25b
Total NVM Capacity:                 4,096,805,658,624 [4.09 TB]
Unallocated NVM Capacity:           0
Controller ID:                      0
NVMe Version:                       2.0
Number of Namespaces:               1
Namespace 1 Size/Capacity:          4,096,805,658,624 [4.09 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            caf25b 038a00006d
Local Time is:                      Tue Feb 11 21:41:32 2025 CET
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x0a):         Cmd_Eff_Lg Telmtry_Lg
Maximum Data Transfer Size:         128 Pages
Warning  Comp. Temp. Threshold:     90 Celsius
Critical Comp. Temp. Threshold:     95 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     6.50W       -        -    0  0  0  0        0       0
 1 +     5.80W       -        -    1  1  1  1        0       0
 2 +     3.60W       -        -    2  2  2  2        0       0
 3 -   0.0500W       -        -    3  3  3  3     5000   10000
 4 -   0.0025W       -        -    4  4  4  4     8000   41000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        44 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    8%
Data Units Read:                    27,740,478 [14.2 TB]
Data Units Written:                 230,197,058 [117 TB]
Host Read Commands:                 193,118,068
Host Write Commands:                2,974,223,159
Controller Busy Time:               20,098
Power Cycles:                       25
Power On Hours:                     4,952
Unsafe Shutdowns:                   22
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               44 Celsius
Temperature Sensor 2:               31 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

Self-test Log (NVMe Log 0x06)
Self-test status: No self-test in progress
Num  Test_Description  Status                       Power_on_Hours  Failing_LBA  NSID Seg SCT Code
 0   Extended          Completed without error                4945            -     -   -   -    -
 1   Short             Completed without error                4945            -     -   -   -    -

[𝑾𝑰𝑭𝑻]

Jestli to jsou soho disky koupeny nekde v garazi, tak bych se podobnymu chovani vubec nedivil. Podle toho jak to popisujes, tak je jeden disk vyrazne horsi, a kdyz ho das do raidu, tak na nej ten raid chte nechte musi cekat.

Jinak na MB/s nesejde, to co potrebujes znat jsou IOps.

Jasně, že na MB/s nesejde, ale i to IO je dost nízké...A ze zápisu v rámci kb/s taky neuděláš extra IO.

Já třeba říkám, že ani propustnost, ani IOPSy samy o sobě nejsou nic. Úložiště se dá vytížit jak hromadou malých IO operací, tak podstatně menším množstvím velkých IO operací. Samotný parametr IO za sekundu neznamená nic, pokud nevíme, jak velké ty IO jsou.
Co je podle mě nejsnazší ukazatel je právě ta utilizace, to je něco, co se mně osobně z linuxu tahá dost nešikovně. Windowsy na to maj krásnej graf přímo v task manageru, kterýmu říká „aktivní čas“ a popisuje ho jako „procento času, po který byl disk zaneprázdněn žádostmi o čtení nebo zápis“. Pokud je disk v pořádku, může být zatížen ke 100% hranici jak zmíněnou kopicí malých IO operací, tak velkými IO operacemi a v takové situaci se dá z IOPSů a propustnosti odhadnout, že je OK. Ale pokud není v úplně nejlepšíá kondici, může se na 100 % aktivního času dostat tím, že se opakovaně snaží zpracovat vadný sektor v případě rotačních disků, nebo v případě SSD třeba zápisem v situaci, kdy musí zároveň uklízet. iostat to umí mj. s parametrem -x, který by měl ukazovat rozšířené statistiky včetně utilizace, což je právě ten sloupec %util, ale tenhle textový výpis je třeba pro mě nešikovný, mám raději grafy . Navíc nechápu, jak se může utilizace dostat nad 100 % (disk nemůže v časovém úseku čekat déle než 100 % toho času, takže to linux zase prezentuje kdovíjak).

[RDa]

Navíc nechápu, jak se může utilizace dostat nad 100 % (disk nemůže v časovém úseku čekat déle než 100 % toho času, takže to linux zase prezentuje kdovíjak).

Mas IO fronty v IO planovaci v jadre OS a pak nekolik front v ramci NVMe specifikace.

Varianta 1 - metrika 100% utilizace, kdy v jadre neni zadna nadbytecna operace ve fronte, a vsechno je predano do front disku.

Z toho pak vyplyva moznost utilizace - pokud delas naivni jednovlaknovy directory travelsal, tak nikdy ta utilizace nepujde vysoko, protoze dalsi dotazy lze vytvorit az disk odpovi. Ale jakmile pustis X vlaken a kazdy bude chtit cist data znamych souboru.. tak muze dojit k zahlceni. Nevime co tam tazatel provozuje za operace (zda nejaka database, caching, logovani nebo co)

To, ze ma nekdo utilizaci nad 100% spise znaci ze se od disku chce vice, nez co zvladne udelat.

Varianta 2 - pokud proces zavola IO operaci skrze syscall, tak tahle operace muze byt vykonana synchronne v ramci jednoho volani, za dobu behu na danem jadre. Pokud jsou ale latence tak vysoke, ze se musi preplanovat proces do spiciho stavu aby se i cpu jadro uvolnilo, tak je to jina kategorie. Coz taky muze hrat roli pro 100% barieru - pod by znamenalo vse se stiha, nad by znamenalo ze IO vyvolalo uspani procesu.

[RDa]

Co to je za raid konfiguraci? Mas tam funkcni trim?

Jaky je model disku a jsou disky spravne chlazeny?

Osobne bych kazdy disk vyradil z raidu, udelal trim, provedl fio test zamereny na latence, udelal trim, vratil do raidu.

Je to RAID1, takže to by bylo dost složité. Zkusím to flo.

Vsak od toho je RAID1 ten mirror, ze jeden disk muzes odebrat a hrat si s nim.. jako jo, budes mit degradovane pole.

Pises ze mate LVM raid (dm-raid) - to neni uplne bezny rezim pouzivani.. precejen sw raid je spise domenou md-raidu. U mirroru dokaze md raid rozkladat zatez, ze se cte z obou disku, pokud bys to chtel pokus nechat cist jen z jednoho disku, tak to lze udelat pres write-mostly priznak. Takze by se pomalejsi z paru disku mohl venovat pouze zapisum a cteni by vzdy slo z disku ktery je zdravej.

Pak me jeste napada - ze 4x NVMe na rekneme pcie x4 vyzaduje trocha spravnejsi hw - jsi si jistej ze vsechny disky jsou pripojeny plnotucne, a treba na linky procesoru.. a neni tento jeden treba povesen na PCH a timpadem znevyhodnen co se tyce latenci nebo sirce pasma?

[Michal Šmucr]

Ano, souhlas s RDa a předřečníky. Zkusil bych inkriminované SSD vyndat z RAIDu.
Není normální, že by jedno párové blok. zařízení v RAID-1 mělo takhle vysoký průměrný wait-time ve frontě v porovnání s tím druhým.
Nevím jestli se dá přímo v LVM RAIDu jednodušše vyřadit blokové zařízení (podobně jako --fail v mdadm), téměř vůbec LVM RAID nepoužívám, spíš klasický mdraid a dlouho jsem s tím nedělal.
Natvrdo by to mělo jít urvat třeba takhle:
echo 1 | sudo tee /sys/block/nvme2n1/device/delete
Nebo samozřejmě fyzicky vyndat.
V RAID-1 režimu by to mělo projít bez ztráty dat, ale asi bych stejně zastavil ty kontejnery a pro sichr zazálohoval. Pokud zjistíte, že je SSD v pohodě, tak se jen vrátí zpátky a sesynchronizuje znovu.

S tímhle Lexarem jsem se konkrétně nikdy nesetkal, ale podle všeho to má MAXIO MAP1602 řadič (což je relativně laciný DRAM less model) a tak rok a půl zpátky bylo do jádra přidávané pár patchů a quirků, aby to vůbec chodilo.
U některých SSD pak SMART moc neřekne, ale přes utilitky z nvme-cli se dají vytáhnout další logy. Ale záleží to na konkrétním modelu, třeba dražší serverové modely (Kioxia, Micron) tam mají další užitečné informace.
Tzn. např. přes nvme fw-log, nvme error-log, případně obecný nvme get-log -log-id=<cislo>
Možná by se z toho dalo něco vytáhnout i tímhle způsobem.

[M Z]

S lvm raidem jsem si hrál asi 5 let zpět a moc dobře to nefungovalo. Zatížení CPU nebo i dokonce síťovky mělo velký vliv na iowait disků. Zkusil bych to, po kontrole jednotlivých disků, předělat na dm RAID. A příště do serveru koupit minimálně Samsung EVO 🤪.

[p_a_l_o]

LVM RAID může být sestavený dvěma způsoby. První je bitmapa součástí obou disků. Druhý je bitmapa ve zvlášť LV.
Pokud je to připraveno chybně, mohou na jednom z disků zápisy do LV způsobovat dvojnásobek zápisových operací do PV.
Pošli výpisy konfigurace LV a rozložení do PV.