CentOS 7 instabilitás?

UPDATE: amióta SATA3 porton van a diszkem, nem tapasztaltam fagyásokat, úgyhogy most már szinte biztos, hogy nem a CentOS-sel vagy a kernellel lesz a baj.

Kaptam egy új PC-t nemrégiben a munkahelyemen - közel 5 évnyi munkaviszony után -, aminek egyfelől örülök, mert szebb, újabb és érezhetően gyorsabb mint a régi, de azért meggyűlik a bajom vele. A gépcserével egybekötve az OS-t is frissítettem CentOS 6-ról 7-re, a RedHat által ajánlott teljes újratelepítéses módszerrel. Lehet, hogy itt rontottam el?

A gépcsere vagy a frissítés ugyanis (egyelőre nem tudom eldönteni, hogy melyik) valami hihetetlen instabilitást eredményezett. A gépem rendszeresen lefagy, van, hogy előzmény nélkül egysze csak újraindul, erősebb I/O terhelésnél az egérkurzor szaggatni kezd, a GUI teljesen használhatatlanná válik kb. fél percre, és jellemzően ilyenkor kezdődnek a gondok (képernyő elsötétül, gép újraindul).

4 GB RAM-mal (+ ugyanennyi swap) és egy négymagos Core i5 procival azért mégse ezt várná az ember...

Seafile-t, rdesktop-ot, skype-ot, firefox-ot (legfrissebb, Adobe repóból telepített Flash plugin-nel) intenzíven használok a napi munkám során, így nem kizárt, hogy ezek valamelyike okozza a problémákat, de egyelőre sötétben tapogatózok. Nem ritka, hogy egyszerre 15-20 szerverre vagyok belépve SSH-val, és ugyebár ezek a kapcsolatok szépen lebontanak, ha újraindul a gép...

Fogalmam sincs, merre induljak el, van pár crash dump-om, de azokat megvizsgálgatva semmivel sem lettem előrébb, egyszer a gnome-shell fagy ki, egyszer a skype, de már a firefox plugin container-re (flash plugin?) is panaszkodott a rendszer egy alkalommal. A syslog és a dmesg parancs kimenete az ég világon semmit nem mond, nem látok bennük semmi gyanúsat.

Hetente legalább egyszer telepítem az frissítéseket, de semmivel sem javul a stabilitás, pedig már lassan 3 hónapja használom a rendszert.

Fontolgatom a CentOS 6-ra downgrade-elést (persze csak egy alapos HW diagnosztika után), de gondoltam, előtte feldobom a témát itt.

Más is tapasztal hasonló stabilitási gondokat CentOS 7-tel vagy inkább hardveres hiba lehet?

( locsemege v | 2014. 10. 14., k – 00:56 )

A leírásod alapján az vagy hardware-es hiba, vagy általában ritkán, de általad használt kernel modul hibája lehet. Ez utóbbi viszont jó eséllyel hagyna valami nyomot maga után, szóval hardware-re gyanakszom.

Ugyan nem használok CentOS-t, de Fedorából stabilizálják, és Fedorát használok, amióta létezik ez a disztribúció. Momentán Fedora 21 alfa kiadást 3.17-es kernellel, és még ezzel sincsenek stabilitási gondjaim, nem, hogy egy alaposan tesztelt, javított változatnak, mint amilyen a CentOS 7.

Lehet be nem dugott tápkábel, kapacitásszegény elektrolit-kondenzátor, RAM, valamilyen specifikáció - időzítés, feszültség - be nem tartása, háttértár - HDD vagy SSD. Szóval szinte bármi.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( kiuka | 2014. 10. 14., k – 01:35 )

én a helyedben egy memtest-el kezdeném az egészet. dmesg syslog, stb-be semmit se logol?

( hrgy84 | 2014. 10. 14., k – 03:36 )

En az alapveto tesztek utan (memtest, hdd test, VGA driver tuningolasa) megprobalnek a gepre egy sima Windowst telepiteni. Nem kell szeretni, csak atmenetileg hasznalni (1-2 nap). Ha a szintetikus tesztek soran nem jon elo semmi, es a Windowssal sem, akkor valami Linux oldali nyugod van, pocsekul van osszerakva a CentOS 7. Nem lepodnek meg rajta egyebkent, az alaprendszer altalaban baromi jo RedHateknel, de a GUI alapu rendszer nem egyszer tobb sebbol verzik. Eleg nehez szerteagazo modon tesztelni azt a reszet ugyanis.

Mindazonaltal nekem is valami hardveres issue a tippem, tehat mindenkeppen errefele nezelodj elsokent. Azonban tapasztalatbol mondom, hogy a legtobb szerviz nem ismeri el operacios rendszerkent a Linuxot, igy a par napos Windowsos teszttel ket dolgot is nyerhetsz: el tudod mondani a szervizeseknek, hogy a Windows mit produkal, es ki tudod zarni, hogy a Linux lenne a problema. A legtobb esetben meghalaljak az ugyfelszolgalatok, ha szamukra is dolgokrol meselsz nekik - meg akkor is, ha sokkal kevesebb infot tudsz eloszedni, mint ami Linuxon elerheto.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( viraghj v | 2014. 10. 14., k – 09:50 )

Csak azért, mert ilyen ötlet még nem volt :)

Talán érdemes a BIOS beállításoknál is szétnézni,
ACPI trükkök, stb

( cheeky v | 2014. 10. 14., k – 10:10 )

Ahogy mindenki írta előttem is, memtest a barátod első körben.
Viszont amit írsz, hogy miket használsz, és milyen a felhasználási mintád, arra azért 4 GB RAM manapság sajnos kevés.
Amúgy is filléres dolog a memória, 8 GB simán el kellene férjen a desktopodban alap szinten is.
De ettől még a panaszaid memóriahibának tűnnek.

Nekem is eszembe jutott, hogy esetleg kevés lehet a RAM, de a statok alapján nem úgy látom, hogy ez lenne a baj, most épp fut minden alkalmazás, amit említettem és így állok memóriával:

KiB Mem: 3860332 total, 3662492 used, 197840 free, 7136 buffers
KiB Swap: 4079612 total, 173424 used, 3906188 free. 2185828 cached Mem

Kicsit gyanús az a ~170 MB swap használat, de kb. 2 GB adat van a cache-ben, ami ha jól tudom, bármikor felszabadítható és kiosztható a futó process-eknek.

Most egyébként minden rendben a géppel, tegnap viszont 5 pendrive párhuzamos írása (dd) közben jött elő a hiba, elsötétült a kép, és kb. 5 másodperccel később újraindult a gép.

A logok persze semmit nem mondanak, de ha mondjuk valamelyik pendrive selejtes is volt, azért csak nem kellene az egész rendszert magával rántania...

Linux wsbud2kd1079.emea.media.global.loc 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Nem valószínű, hogy USB-specifikus probléma, mert akkor is előjött már, amikor a merevlemez pörgött igen intenzíven (pl. seafile indexelés közben).

A logikáját értem. Az adott verziójú vanillából indulnak ki, s utána az összes patch a Red Hat berkein belül kerül hozzá, így a kötőjel után van egy build szám. Tehát nem nyúlnak vissza a vanillához. Gondolom, azért, mert ha van olyan patch, ami a vanillában másként került megvalósításra, akkor nem szeretnék ezt használni, ha a saját megoldásuk tesztelt, hiszen arra vállalják a felelősséget. Az más kérdés, hogy a vanilla is jelentős részt a Red Hat igényei szerint alakul, de azért nem teljesen. Fedorába például egész kevés patch-csel kerül a legfrissebb vanilla.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hulyeseg, arra, amit ir, 4G tokeletesen eleg. Oke, a firefoxnal van nehany megszoritas, Chrome-mal lehet jobban jarna, de whatever. En evek ota 4G-vel tolom, es eleg, pedig nagyon hasonlo usage patternem van.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( gergelykiss | 2014. 10. 14., k – 21:10 )

Köszönöm szépen a hozzászólásokat!

A memtest futtatása megvolt, nem jelzett semmi hibát 4 tesztciklus alatt.

Tesztjelleggel kicseréltem a HDD SATA kábelét, illetve kiderült, hogy a diszkem véletlenül SATA2 portra lett bedugva, holott simán tudja a SATA3-at is, úgyhogy átkötöttem egy SATA3-as portra az alaplapon. Ez picivel mintha gyorsított is volna az írási/olvasási műveleteken, bár ezt csak "érzésre" tudom mondani, nem futtattam benchmark teszteket.

Fagyást, lassulást egyébként nem tapasztaltam tegnap óta, meglátjuk, megmarad-e így hosszabb távon.

Egy kernel trace azért csak előbukkant a logokból, de nem igazán tudom értelmezni... Feltöltöttem ide, ha esetleg ránézne valaki, aki jártas ilyesmiben, megköszönném.

( _neo v | 2014. 10. 15., sze – 00:40 )

Nekem pontosan ugyanezt produkálta a vadiúj laptopom. Kiderült, hogy badsectoros a merevlemeze és néha megakasztotta a gépet, néha pedig amikor sikerült valami ökörséget olvasnia, akkor dobott a kernel egy panicet..

Köszi, nem látom nyomát hibás szektornak a logokban.

A SMART ezt mondja, itt se látszik bármi rendellenesség:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 174 174 021 Pre-fail Always - 2266
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 13
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 1530
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 13
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 9
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 11
194 Temperature_Celsius 0x0022 108 106 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0