Fórum Root.cz
Hlavní témata => Server => Téma založeno: Darkhunter 11. 02. 2025, 14:16:46
-
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):
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!
-
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.
-
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.
-
nvme2n1 tipuju, že je nakopnutý (nebo ošoupaný). Zkusil bych ho vyměnit.
Pošli sem výpis ze smartu.
-
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í.
-
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ě.
-
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.
-
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.
-
Tak ještě posílám SMART
=== 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).
-
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.
-
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?
-
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.
-
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 🤪.
-
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.
-
... a neni tento jeden treba povesen na PCH a timpadem znevyhodnen co se tyce latenci nebo sirce pasma?
Nebo se o ten kanal s necim deli. Ale to by zase nemel nijak vyznamne ovlivnit trim, o cemz tazatel pise ze to na chvili pomuze.
-
Tak jsem to dále zkoumal. Když spustím fstrim, tak to zhruba 2 hodiny je ok a pak postupně to jde do toho maximálního loadu. Vidím i jak utilizace časem stoupá. Pro všechny FS, které jsou na ext4, jsem zapl discard, ale nepomohlo to. Takže nezbývá asi než zapnout trim každé dvě hodiny?
-
No, já bych ten disk osobně teda vyhodil a pořídil něco vhodného pro servery.
-
...
Takže nezbývá asi než zapnout trim každé dvě hodiny?
Nikoliv, tím byste se možná pokusil řešít následek. Navíc není žádná jistota, že to i do budoucna pomůže, protože nevíte, proč se to děje.
Je tam určitá šance, že pokud ty ostatní tenhle problém nevykazují a je tam na oba RAIDy víceméně podobná zátěž, tak je prostě jeden kousek ze čtyřech vadný.
Ale jak jsme tu psali, abyste si to potvrdil, vyhoďte nejdřív ten podezřelý z RAIDu, neznám úplně jiný způsob, jak to zjistit. Pojedete chvíli bez redundance, ale jestli je to SSD skutečně nějak nakopnuté, má dlouhé latence a celý RAID na něj čeká, tak by ty problémy měly ustat.
Jinak samozřejmě, je pravda i to, že nezávisle na případném vadném kousku jde o entry-level consumer SSD. Jestli je ten server vytěžovaný a jde vám o spolehlivost a dostupnost, tak ty serverová SSD mají své opodstatnění a samozřejmě i důvody, proč pak stojí třeba dvakrát tolik.
-
Podle toho co si napsal generujes zhruba 1GB/hod zapisu.
V nehorsim pripade to znamena 2097152 zapisu (512B/zapis). Jenze ... velikost bloku toho ssdcka je podle vseho 64MB. Takze kvuli kazdymu jednomu zapisu bys pak musel nejdriv tech 64MB precist (coz odpovida tomu ze kdyz provedes trim, chvili se to nedeje), coz ti generuje 134TB/hod. Tzn cca 40MB/s cteni, a to je slusna porce i pro SSD. Pricemz to zdaleka neni vsechno. Protoze to samy pak musis upravit a zpet zapsat.
Tudiz krome toho ze jeden disk to nejspis nedava, mas dost pravdepodobne problem ve velikosti bloku toho raidu + bloku fs.
-
Jeste bych se podival na SMART rozdil, udelejte 2 vzorky vzdalene 24 hodin (nebo hodinu ve spicce) terba pres vsechny disky pomoci nvme smart-log a odectete objem cteni i zapisu, at vidite o jakou zatez se vlastne jedna.
(snad LVM mirror neni tak blbej, ze by kazdej zapis povazoval za update celeho LVM extentu, coz je 4MB)
-
Tenhle model disku mám, nemá rád teploty takže solidní chladič je nutnost, když kopíruju více dat jednorázově (cca 400GB+). Udělal bych kontrolu zda se přehřívá když je hodně vytížený. Určitě bych alespoň toto ověřil.
Osobně jej ale používám jako sekundární velké úložiště, na hlavní pak Samsung 990 Pro (heatsink) a to pro stolní PC.
O jeho vhodnosti nasazení jako hlavní disk nejsem přesvědčen (testováno cca 3 měsíce). Nasazení v serveru mě přijde riskantní až nevhodné. Beru to pouze jako velké úložiště.