Server s Dockerem zamrzá

[Darkhunter]

Ahoj,
už nevím, co s tím dále debugovat a řeším to skoro již dva roky a zatím nic nepomohlo.
Mám DIY server s Ryzenem 5950X + 4x32GB RAM UDIMM ECC + Asrock Rack X470-D4U.
Na serveru běží Archlinux a na něm jen Docker s cca 700 kontejnery.
Od začátku jsem řešil problém, že s tím Ryzenem server padá po spuštění Dockeru třeba po 5 minutách. Proběhlo několik reklamací a nic - prý vše v pořádku. Mezitím jsem tam měl Ryzen 5800X3D a ten byl rock-stable. Nakonec pomohlo snížení frekvence pamětí na polovinu (1333Mhz). Dlouhou dobu to bylo v pořádku, ale pár měsíců zpátky problém zase začal. Myslel jsem, že to bylo teplotou, tak jsem upgradoval case a chladiče. Teplota klesla průměrně o 10 ˚C.

Každopádně to vůbec nepomohlo. Server teď pravidelně padá při buildění jedné monorepo node.js aplikace. Když build běží, tak load serveru není celkově větší než 10 a teploty lezou přes 90°C i přesto, že server mám daný na TDP 80W a PPT 95W. Rozhodl jsem se to dnes znovu řešit, aby to nedělalo v pracovním týdnu nepříjemnosti, ale bohužel nejsem schopný teď server shodit.

Zkoušel jsem stress i stress-ng a i přes extrémní nastavení jsem se nedostal přes 80˚C. Vůbec teda nechápu, jak může nějakej node s loadem max 10 zatopit tolik serveru, že dokáže zamrznout tak, že ani přes IPMI ho nemohu ovládat.

Bohužel si stále nejsem jistý, že to je vysokou teplotou a navíc to teď ani nemohu nasimulovat i přesto, že spouštím několik buildů naráz.

Dá se to nějak oddebugovat, co reálně ten totální freeze způsobilo? V logách ani nikde jinde nic nemám a bohužel to teď ani nemůžu nasimulovat no...

[Reklama]

[skrivy]

S 5950X máme také problémy.

(teď mě neber za slovo - to nastavení si nepamatuji přesně) Máme vypnutý turboboost a nastavené TDP na nižší hodnotu (snad 60W) a stejně se nám servery s tímto CPU jednou za čas (řádově týdny) seknou nebo restartují.

Jinak teplota 90°C by měla být hraniční, kdy CPU sníží sám od sebe frekvence. Když jsme jeli na 100% s teplotou dlouhodobě na 90°C, tak se záseky děly každých <24h.

Osobně to považuji jako vlastnost této série, kdy jedou na hraně nebo to špatně používáme.

Po této zkušenosti tyto CPU nicméně používáme jen v clusterech, kde záseky nevadí. V novějších serverech máme Ryzeny 7900 a ty fungují dobře (vyjma problémů se Samsung SSD).

[Jan Forman]

Domnívám se, že to může být RAMkou nebo řadičem v CPU. Taky běžně provozuju dlouhodobě 5950X na 100% utilizaci na dvou slotech a nikdy se to neseklo. Lidi hlásí různé problémy při použití plně obsazených 4 slotů.

[ogdru6jahad]

a neslo by to zkusit misto dockeru pustit primo na masine a koukat, jestli za to muze cpu/ram a problem je mimo docker.

[Michal Šmucr]

Pokud to souvisí s pamětí, nebo teplotou, tak by ta chyba by měla jít replikovat nějak opakovaně a rychleji i bez toho buildování. Ale samozřejmě to může být i jinými komponenty (deskou, zdrojem), zvlášť pokud zhebne i BMC modul, který by měl být do značné míry nezávislý, ale neznám konkrétně tuhle desku.
Co se týká testování zátěže a teploty a zdroje, tak mám lepší zkušenost s Firestarterem než se stress-ng. Hodně jsem ho používal, když jsem testoval nody v renderfarmě, i kvůli tomu, že dokáže udělat současný load na GPGPU přes CUDA a dosahuji i jen přes CPU vyšších teplot.
https://github.com/tud-zih-energy/FIRESTARTER
Pro online verifikaci tam pak použít parametr --error-detection.

Klasika Prime95 je také dobrý pro souběžné testování CPUa paměti a třeba odhalování potíží s mezisocketovou komunikací resp. Infinity Fabric od AMD. Chce to ale použít custom test a nastavit, aby použil dostatečně velký blok paměti.

Jinak na samotnou paměť a rychlé odhalování chyb pak typicky memtest86, i když spolehlivějších výsledku jsem dosahoval s tím freeware od PassMarku, ne s opensource verzi (plus). Zvlášť v SMP módu a s rowhammer alogritmem
https://www.memtest86.com/
Stran pamětí jsem ještě zažil, že u některých desek s desktop chipy se vyjevovaly chyby např. pouze při obsazení všech čtyřech slotů. Při pouze dvou slotech to chodilo, s plným obsazením pak bylo nutné výrazně snížit frekvenci a laborovat metodou pokus omyl s latencemi (daleko od automatických XMP hodnot), případně ještě napětím do modulů (tam pak zas bacha na teplotu, zvlášť v případě, že moduly jsou úplně holé bez pasivů).

[Reklama]

[Darkhunter]

Tak jsem to ještě více debugoval.
Za poslední dny to crashuje každý den minimálně jednou a neděje se pouze, když je server hodně vytížen.
Poslední logy, co vidím na serveru, jsou:

Kód: [Vybrat]

[nodemon] starting `node  ./src/main.js || touch ./src/main.js`
Tzn to není při kompilaci, ale při startu node appky.
Vypnul jsem CPB/Turboboost a teploty CPU nejdou nad 65°C.
Přečtu si vaše rady a zkusím aplikovat.
Jinak memtest jsem procházel několikrát a vše v pohodě. Ve stejné sestavě a jen s vyměněným 5950X za 5800X3D to běželo půl roku, než jsem tam tu 5950X zase hodil. Tou 5950Xkou to taky není. Reklamoval jsem ji a měl jsem celkově tři kusy a všechny stejnej behavior. Je možné teda ale, že ty ramky začaly blbnout až teď a předtím to padalo jen s vyššími takty.

[jjrsk]

Vem ten CPU a dej ho do jine sestavy na ktere spust stejny system. Ze pri reklamaci "funguje" === zapne se.

Kristalova koule pak rika, ze bys moh mit problem s napajeci kaskadou, tzn v okamzeni kdy si CPU rekne o nejakou tu amperu, jdou volty do kopru. Napajeni je na MB kolem CPU, a s jinym kterej ma proste jinou charakteristiku to klidne fungovat muze. Teplota s tim nema nic spolecnyho. Stejne tak ti ten CPu muze klidne fungovat v jiny desce, protoze jeji kaskada to proste ustoji.

Co muzes (ale nedelej si nadeje) je pokusit se vycist hotnoty napajeni a predevsim jejich kolisani (lm_sensors treba), ale necekej ze se ti SW cestou povede zalogovat ten vypadek, v tu dobu uz je to mrtvy. Kazdopadne pokud za provozu jsou hodnoty pod mezi nebo kolisaji = nasel si fail.