SSD és Firefox random fagyás Ubuntun

Merevlemezek, vezérlők

Érdekes hibára lettem figyelmes nagyjából azóta, mióta SSD van a gépemben. A meghajtó egy Sandisk 128GB-os SSD, ami egyedüli tárolóeszközként használatos egy Dell-E5530-as notebookban.

Firefox használatakor böngészés közben (az esetek jeletős többségében Google képtalálatok böngészésénél, illetve a Google Maps használata alkalmával) véletlenszerű piallanatban az egér elkezd szaggatottan, akadozva mozogni. Ekkor a gépre nézve már azt látom, hogy a HDD LED folyamatosan világít, a rendszermonitor hirtelen nagy mennyiségű adat írását/olvasását jelzi. Pár pillanat múlva a processzorhasználat is megugrik és kb. használhatatlanná válik a gép.
Ha elég gyors vagyok és még a folyamat elején ki tudok lépni a Firefoxból, akkor igaz lassan, de a bezárást követően a lemezműveletek megszűnnek és a gép ismét használható. Ha pár másodpercen belül nem sikerül bezárnom a Firefoxot, akkor kb. kikapcsolás a vége, majd újraindítás.

Legutóbb a Firefox bezárásakor a Gnome3 újraindult, tehát a bejelentkező kép jelent meg, belépve pedig teljesen üres munkaterület fogadott, mint amikor elindítom a rendszert.
Rendszerösszeomlásról és egyéb hibáról az Ubuntu nem értesített, pedig van, hogy feljön a hibajelentés küldése ablak, de itt semmi ilyen nem történik.

Én az SSD-re gyanakszom, a Firefoxban kikapcsoltam már mindeféle háttértárra való cache-elést és merevlemez használatot, de szerintem nem mentem sokra vele, mert pl. egy Youtube videót nézve is folyamatos írásokat látok a háttértárolóra.

Ilyen esetben a rendszerben hol lehet információkhoz jutni, hogy egyértelmű legyen a hiba oka?
Ezidő alatt, hogy írom ezt a postot csak egy Firefox van nyitva és a rendszerfigyelő, ami CPU használatot nem jelez egyik folyamatnál sem, viszont a rendszermonitoron most is látok sűrű időközönként történő lemezírási ciklusokat úgy, hogy hálózati forgalom nincs.

Ext4 fájlrendszert használok, swap partícióm nincs, van egy sda1 20GB-os /root és egy 100GB-os sda2 extendedben egy sda5 /home.
A Gsmartcontrol szerint minden oké. Jelenleg Ubuntu 14.4LTS van a gépen, az egész cucc fél éves sincs még, igaz napi használatban van dokkolóban.

  • 8407 megtekintés

( locsemege v | 2014. 05. 13., k – 02:26 )

A jelenség olyasmi, mintha valahol memory leak lenne, vagy csak elfogyott volna a memória és az OOM killer lépett volna működésbe.

Swap-ed legyen, mert manapság gyakran használnak tmpfs-t, amelynek az a jellemzője, hogy RAM-ban foglalódik, de ha kevés a hely, swap felé tágul.

Arról nem írtál, mennyi RAM van a gépedben.

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

4GB RAM van benne, ezért sem hoztam létre a telepítésnél swap-et.
Nem használok nagy memóraigényű programokat, bár a Firefox kilóg a sorból, mert annak a memóriából sohasem kevés. Ezt mondjuk nem lehet valahogy bekorlátozni? Volt olyan, hogy csak a böngészőt indítottam el és egy idő után csak azt láttam, hogy a 4GB memóriának a 92%-a foglalt volt.

Én eddig azt hittem, azért van a gépben a RAM, hogy használjuk. :) Sok memória esetén is célszerű a swap meglátásom szerint. Az okot írtam, a tmpfs tud swap-re dolgozni, ha fogytán a RAM.

Nálam 5 db tmpfs van, mindegyike a RAM 50 %-ban korlátozva, azaz 4 GiB esetén 2 GiB. Ebből nyilvánvaló, hogy a rendszer reménykedik, ez sohasem lesz egyidejűleg kihasználva. Ha mégis valaki például a /tmp-t elkezdené teleírni, ami éppen tmpfs, jó volna, ha swap-re tudna menekülni az adat, hiszen ellenkező esetben maximum 2 GiB-ot falna fel csak ez az egyetlen filerendszer.

Szóval a swap nem hülyeség, ráadásul tömöríthető zswap.enabled=1 kernelparaméter alkalmazásával.

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

Igen a RAM azért van, hogy használjuk, nem ez a probléma. A probléma az, hogy nem csak Firefox fut a gépen. Amikor 2GB RAM volt az asztali gépemben a Firefox azt is telenyomta, mikor mellé tettem még kettőt, a 4GB-ot is szintén telenyomta.
Több fórumban is olvastam anno mikor az SSD beállítással foglalkoztam, hogy nem javasolják SSD-re a lapozó partíciót mivel pont az a cél, hogy az ideiglenes cuccokat is inkább a RAM-ba töltsük az írási ciklusok csökkentése miatt.

Szerintem az adat csak ne "meneküljön" a swap-re, hanem az az alkalmazás ami elkezdni telenyomni a RAM-ot egészséges keretek közé legyen szorítva és gazdálkodjon egy felhasználó által megadott területtel, vagy pakoljon ki, hogy más folyamatok is használhassák az elfoglalt területeket.

Egyébként ez a fagyás gond minden esetben 80-90%-os memória telítettség mellett jelentkezik.
Szerintem ilyenkor kezdődne valami kiírás a nem létező swap helyett valahová, csak hát annyira dolgozik szerencsétlen, hogy minden megáll.

Lehet, hogy csak álmodozom, de nem lehet, hogy a böngészők optimalizálják a memóriahasználatukat, és megpróbálnak alkalmazkodni az elérhető memóriamennyiséggel úgy gazdálkodni, hogy ki is használják, de fel is szabadítsák, ha épp másnak van rá szüksége?

Ez nem egyszerű. Valószínű, a böngésző gyorsabb, hatékonyabb, ha több memóriát használhat. Ha teszem azt, egy képet minden megjelenítés alkalmával renderelni kell, az lassú, de memóriát spórol, mert amikor nem kell megjeleníteni, akkor felszabadítható a hely.

Ugyanakkor, ha egyszer rendereljük, utána pixelenként a memóriában tartjuk, az gyors, de zabálja a memóriát.

Mit tehet a böngésző? Például megkérdezi az oprendszertől, mennyi a szabad memória, és ahhoz alkalmazkodva foglal vagy kevesebbet, vagy többet. Viszont, ha már lefoglalta, s most valaki elkezd ámokfutni a /tmp-be, akkor a tmpfs RAM disk hamar betelik, ugyanakkor semmi probléma sem származik abból, ha a tartalom a swap-re kerül. Mégpedig azért nem, mert régen a /tmp amúgy is HDD-n volt, szóval annál nem lesz rosszabb a helyzet. Ugyanakkor, ha nem kell a swap-et használni, úgy lényegesen jobb lesz a helyzet, mivel a RAM elérési ideje töredéke a HDD-jének.

Ugyan a böngésző kényszerítette ki közvetve a helyzetet, de a böngésző jóhiszemű volt, az elején nem tudhatta, hogy spórolni kell a RAM-mal. Amikor nem spórolt, azért tette ezt így, hogy gyorsabb legyen.

Nyilván bele lehet kötni a példámba, ugyanakkor azt szeretném mondani, hogy nem olyan egyszerű valamit optimálisra csinálni, ha nem ismerjük a peremfeltételeket. Márpedig azt aligha tudjuk, milyen alkalmazások milyen erőforrás igénnyel indulnak majd a későbbiekben.

Továbbra is az a véleményem, a swap jó dolog, bár nem feltétlen SSD-n megvalósítva.

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

Memória elfogyás +1
Én is jártam hasonlóan, egy idő után a firefox egyszerűen kilépett (semmi fagyás, akadás, ilyesmi nem volt, egyszer volt, következő pillanatban már nem).
Egy ideig tűrtem, utána meguntam, és közben figyeltem a rendszert: a 4 giga memória kifogyott (semmi lényeges nem futott mellette). Adtam alá 3.4 giga swap-et (SSD-n), azóta minden oké, egy idő után elkezdi a swap-et használni, firefox-ból kilépek, aztán lecsökken a swap használat is (bár igazán nem szokott érdekelni, lassulást nemigen tapasztalok).

( ak0sh | 2014. 05. 13., k – 06:41 )

Én ilyet SSD-vel + Firefox-al + Ubuntu-val nem tapasztaltam.
Igaz, én kikapcsoltam mindenféle lemezre cache-lést a rókában.

( trey | 2014. 05. 13., k – 08:11 )

Évek óta használok Firefox + SSD + Ubuntu hármast, de ilyet még nem láttam. Mondjuk nekem a Firefox cache könyvtár egy ramdisk-ben van.

--
trey @ gépház

( manfreed (nem ellenőrzött) | 2014. 05. 13., k – 08:22 )

Én is tapasztalgatok ilyesmit lényegében azóta, amióta SSD-vel van dolgom. Nálam nem a Firefox okozza, bár okozhatná épp az is.

Az én tapasztalatom az, hogy bármi komolyabb lemezművelet (írás inkább?) képes olyan terhelést okozni, ami az általad említett tünetekkel jár. Ahányszor nekiállok nagyobb fájlokat másolni, kitömöríteni, vagy komolyabb sebességgel torrentezni a gépem elkezd akadozni. Ugyanez, ha elfogy a memória, és elkezd lapozófájlba írni. Akadozik az egérkurzor (de szerintem inkább a képernyő teljes újrarajzolása), zene- vagy videolejátszás, lényegében a gépem ilyenkor használhatatlan egészen addig, amíg be nem fejezi amit épp csinált.

Mindkét gépem, amiben SSD van szivat ezzel, bár az egyik gépemen, amiben gyengébb vas van mint ha sokkal könnyebben előjönne.

Pár napja nekem is hasonlót művel a Firefox, az elindítást követően percekig darál, közben fogja a gépet, gyakorlatilag megáll az élet míg befejezi. Nem fagy, de blokkolja a gépet.
Egérkurzor akad, kattintások megtörténnek, de csak percek múlva, futó dolgok megállnak majd mennek tovább.
(i7, Kubuntu 12.04.4 amd64)

( bazso | 2014. 05. 13., k – 09:19 )

Nálam a céges win7 alatt is előjött. A megoldás az acpi mód váltása volt a bios-ban. Legalábbis a hd állítása szerint...

( mrev | 2014. 05. 13., k – 10:45 )

Teljesen friss 64 bites Trusty. Ma reggel be akarok tölteni egy oldalt az ff-be, zene elakad (lemez i/o!), figyelmeztető ablak: az ff nem válaszol, lelő, zene folytat.

Szerintem ennek nincs köze az ssd-hez vagy a fájlrendszerhez. Egy akkora programban, mint az ff mindig van valami. Hol itt csuklik, hol ott nyeklik. Hogy trey mit mond, nem érdekes, neki mindig minden működik.
--
ulysses.co.hu

Mert az esetek jó részében kiderül, hogy engem azért nem érint, mert én 32 bites rendszert használok, meg ext3, ext4 helyett ReiserFS-t és így tovább. :D

Illetve, mint említettem, nekem a Firefox cache könyvtára ramdisk-ben van. Neked hol van? Megpróbáltam már oda tenni? Úgy is jelentkezik a probléma?

Ha ennyire nem passzolnak a paraméterek, akkor mire föl vagy cinikus?

--
trey @ gépház

Ha a hiba a fájlrendszerben volna, az sokkal nagyobb baj volna. Egy fs hiba cégek sokaságát fenyegetne IT katasztrófával. Ehhez képest egy ff hiba nem érdekes, újraindítom és kész.

Nem akartam cinikus lenni. A Linux baromi jó, csak hát hibák mindig vannak. Amúgy, nálam a vinyón van a cache.

--
ulysses.co.hu

Nem feltétlen kell itt fájlrendszerhibára gondolni. Ext4 fájlrendszeren értelmezhető SSD esetén az TRIM, ami pl. ReiserFS-en nem. Ráadásul a 14.04-től alapértelmezetten bekapcsolták, vagy legalábbis ez volt a terv.

Nem tudom, hogy mi lett a vége, azt sem, hogy a "discard" vagy az fstrim mellett maradtak, de ennek pl. utánanéznék.

--
trey @ gépház

Én nem használok FF-et, szóval akkor az ff-hez sincs köze? :) Lehet, hogy az FF bugos, és indokolatlan lemez io-kat csinál, de egy jó ütemezőnek meg kéne oldania, hogy ne tudjon lefulladni a rendszer olyan szintre, hogy egy zenelejátszás megakad, akármennyire szenved egy másik program. Vagy én akarok túl sokat? :D

( ncc1701 | 2014. 05. 13., k – 12:39 )

Anno win7 alatt volt ilyenem egy olcsó ssd-vel. Játék közben elkezdett tekerni, és belagolt az egész. 4 magos, 4.1Ghz-es procival, 8G memóriával, képtelenség, elötte hdd-vel teljesen jó volt. Vmi occó kingfast 64G-ás ssd volt a rendszernek betéve, lassú is volt. Aztán lecseréltem egy intel 60-asra, azóta mint a villám, lag megszűnt, tökéletes.

( Laci04 | 2014. 05. 13., k – 15:44 )

A nagyobb lemezműveleteket előidéző folyamatok alkalmával nálam is előfordult akadás a rendszerben, igaz akkor csak a kijelzés akadhatott, mert az egérrel nem volt probléma.
Az írásomban kitértem arra, hogy a Firefox nem gyorsítótárazik az SSD-re (elvileg) mert ezt a beállításaiban letiltottam.
4GB ram mellett szerintem nem lenne szabad, hogy memóriaproblémák legyenek.
A processzor Intel® Core™ i5-3210M CPU @ 2.50GHz × 4
Grafika: Intel® Ivybridge Mobile HD 4000
A rendszer 14.04 LTS, (ezt talán már írtam) azt mondjuk nem írtam, hogy előtte 13.04 és 13.10 is volt a gépen és a hiba akkor is megvolt. A 13.04-ről frissítéssel mentem 13.10-re, a 14.04 teljes újratelepítés volt, de a hiba még most is megvan.

Azt tudom, hogy a /var mappában vannak mindeféle logok, de foglalmam sincs, hogy merre keresgéljek.
Én nem állítom, hogy Firefox hiba, de tény, hogy az esetek 100%-ában böngészés következtében jelentkezett a probléma, amikor nagyobb mennyiségű adatot (képeket) kellett gyorsítótáraznia.

Firmware frissítést megnézem, eddig ilyet még nem csináltam. Mielőtt kidobnám az SSD-t azért én meggyőződnék róla, hogy tényleg olyan baja van ami szoftveresen nem orvosolható.
Nekem nincs most felesleges 50K hirtelen egy Intel SSD-re ...mert gondolom azon kívül az összes többi a "nem rendes" kategória.

Ha csere lesz, akkor már inkább egy nagyobb hagyományos HDD-re lesz. Lehet korai volt még leváltanom a jól bevált technológiát.

( Laci04 | 2014. 05. 14., sze – 01:10 )

Ismét probléma, viszont ezúttal a háttérben volt a Firefox két egyszerű weblap volt benne megnyitva, viszont mellette elindítottam egy Android virtuális eszközt.
Töltés... töltés... egyszer csak extrém lemezművelet, processzorhasználat felugrik, egér akadozik... kb. 2 perc és automatikus logout. Természetesen minden alkalmazás, ami nyitva volt, ismét bezárt.
A RAM használat most is 80% felett volt, de nekem egyre inkább az SSD lesz gyanús.
Foglamam sincs ilyenkor mi történik. A splash screen a kilogolásnál egy pillanatra eltűnt, a szöveges felületen volt pár sor, de csak egy pillanatig láttam.

Mondom, hogy elfogy a RAM-od, a kernel megpróbálja megbecsülni, ki miatt, aztán azt megöli. Ha nagyon belenyúl, abból nagy borulás lesz.

Az persze nem kizárt, hogy memory leak, vagy sok /tmp-re írás az ok. Swap-nek makacsul ellenállsz? Nem kell SSD-re, mehet akár HDD-re.

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

Egyébként hogyan létezik az, hogy egy olyan fejlett rendszeren, mint a Linux ezt nem lehet biztosra kideríteni? Biztosan van rá mód. Én nem állítom, hogy nincs igazad, de ezek nyilván csak feltevések. A jelenség konkrét okát szeretném megtudni, csak ennyire nem ismerem a rendszert. Leginkább felhasználó vagyok, igaz nem félek a terminált sem használni, ha a helyzet úgy hozza. :) Tuti, hogy erről is van valami log valahol.

/var/log/messages file vagy journalctl parancs. De fene tudja, hogy mi megy logba.

Azért sejtem, mert volt, hogy szándékosan írtam teszt programot arra, hogy mi van, ha felfalom a memóriát. Néztem top-pal.

Egyrészt a foglaláskor semmi. Foglalhatsz többet a fizikai RAM-nál. A kernel lapul, mint nyúl a fűben, és reménykedik, hogy csak lefoglaltad, de nem fogod használni.

Ha címzel a területre, gyorsan alád lapoz egy lapot. Gondolom, 4 kiB - vagy 16? -, de lehet, nem így van ez már, nem tudom.

Ha fogytán a RAM, csökkenti a disk cache-t. Ha ez sem elég, akkor swap-re ír, már, ha van hova. Aztán, ha nagyon sarokba szorítod, akkor az Out of Memory Killer kinyírja a kernel által megbecsült process-t, és felszabadítja az általa foglalt területet.

Ekkor, a vége felé már elakad az egérkurzor, nem igazán válaszolékony a rendszer, de magához tér, miután felszabadította a helyet.

Ezen felül magad is mondtad, hogy igen magas a RAM használat, amikor ezek történnek.

Lehet, azért lassul le, mert a disk cache igen kicsi lett, s minden azonnal megy a háttértár felé.

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

( akkos v | 2014. 05. 14., sze – 11:39 )

Ugyanezzel a problémával találkoztam már én is. ssd+ext4+ubuntu.
firefox használat közben is előfordult, illetve source-os játékok betöltésénél játszotta el pontosan az általad leírt forgatókönyvet. (Egér akad+magas io, ha nem kapcsolok időben a teljes rendszer meghal, pontosabban használhatatlanra lassul. ssh-n is percekig tart csak a bejelentkezés.)

Nekem nem volt kedvem szöszölni vele, a lemezek és a memória tesztje után én inkább csináltam egy klónozást, és feldobtam próbára egy fedora 20-at btrfs-re.

Kicsit radikális váltás, de az elmúlt 1 hónapban még nem jelentekezett a probléma. A btrfs snapshot képességei meg nagyon megtetszettek.

szerk.:ja, szintén 4gb ramom volt. Egy ilyen borulás alkalmával egyszer rááldoztam fél(!) órát, amíg tty-n sikerült bejelntkeznem, és elindítanom egy top-ot. A memória csak 70%-ban volt kihasználva, + valamennyi cache-elt adat, de nem volt teljesen tele.
Ahhoz már nem volt energiám hogy kivárjak egy iotop-ot is :)

( Laci04 | 2014. 05. 14., sze – 12:27 )

Nah eszközöltem némi változtatást, remélem nem csesztem el semmit, de a rendszer újraindult így nem csinálhattam nagy kárt benne. :)

Íme az ftab módosítások:

# / was on /dev/sda1 during installation
UUID=f037c332-0c7e-4574-a37a-258bec9436a2 / ext4 discard,noatime,errors=remount-ro 0 1

# /home was on /dev/sda5 during installation
UUID=1798900d-ee38-43f4-afd8-47a2e3e0cd83 /home ext4 defaults,noatime 0 2

# tmpfs installation
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

4 új tmpfs, a "/" fájlrendszerhez hozzá lett adva a discard és noatime opció, a "/home" fájlrendszerhez csak a noatime lett beállítva. A noatime hatására a fájlok utolsó hozzáférési ideje ugyan nem kerül kiírásra, de ezáltal gyorsul az adatátvitel. (gondolom kevesebb adat és lekérdezési művelet)
A discard attribútumot elvileg a TRIM bekapcsolására használják, mondjuk ez nálam fut, ettől függetlenül beírtam, szerintem nagy kárt nem okozhatok vele, maximum így nincs semmi haszna.

Szó szerinti idézet: "Ezzel a konstrukcióval érdemes vigyázni, mert ha elfogy a hely a memóriából, akkor a swap-et fogja használni a rendszer, valamint egyes programok nem tudnak elindulni, ha nincsenek meg a /var/log-ban a saját mappáik.
Egy megoldás ezen mappák létrehozására, ha a rendszer indulásakor elkészítjük ezeket egy init.d szkriptben."

Itt létrehozásra került a mellékelt script:

sudo touch /etc/init.d/make-tmpfs-dirs

#!/bin/sh

### BEGIN INIT INFO
# Provides: make-tmpfs-dirs
# Required-Start:
# Required-Stop:
# Default-Start: 2
# Default-Stop:
# Short-Description: Create temporary directories on tmpfs.
# Description: Create temporary directories for Debconf, Apache2, GDM, ATD
### END INIT INFO

# Debconf
mkdir /var/cache/debconf

# Apache2
sudo mkdir /var/log/apache2
sudo chown root:adm /var/log/apache2
sudo chmod 750 /var/log/apache2

# GDM
sudo mkdir -p /var/log/gdm

# ATD
sudo mkdir -p /var/spool/cron/atjobs

exit 0

Majd jogosultságok beállítása:

sudo chmod u+x /etc/init.d/make-tmpfs-dirs
cd /etc/rc2.d
sudo ln -s ../init.d/make-tmpfs-dirs S02make-tmpfs-dirs

Végül a Firefox cache beállítása:

Jobb klikk -> New -> String
Névnek írjuk be a következőt: browser.cache.disk.parent_directory
Értéknek pedig: /tmp

A leírás, ami szerint eljártam itt található:
http://linuxtutorialok.blogspot.hu/2012/10/linux-optimalizalasa-ssd-hez…

( Laci04 | 2014. 05. 14., sze – 12:42 )

Ezek itt a Firefox beállításai. Szerintem nem teljesen jók, de ezekhez annyira nem értek, hogy minek mennyit érdemes beállítani.

browser.cache.check_doc_frequency;3
browser.cache.compression_level;0
browser.cache.disk.capacity;0
browser.cache.disk.enable;true
browser.cache.disk.max_entry_size;51200
browser.cache.disk.parent_directory;/tmp
browser.cache.disk.smart_size.enabled;false
browser.cache.disk.smart_size.first_run;false
browser.cache.disk.smart_size.use_old_max;false
browser.cache.disk.smart_size_cached_value;358400
browser.cache.disk_cache_ssl;true
browser.cache.memory.enable;true
browser.cache.memory.max_entry_size;5120
browser.cache.memory_limit;51200
browser.cache.offline.capacity;512000
browser.cache.offline.enable;false
browser.cache.use_new_backend;0

A rendszermonitor már alig mutat írást az SSD-re, ez már jó jel. Egyelőre figyelem a RAM használatot.

( trt | 2014. 05. 15., cs – 23:55 )

Sziasztok! Nálam is jelentkezett a hiba, hasonló tünetekkel. A rendszer szintén 64 bites, Kubuntu 14.04, C2D procival, ext4 fájlrendszer. Talán nem haszontalan leírni, hogy korábban a noteszgépemen 32 bites 10.04-es Ubuntu futott teljesen stabilan, még akkor is, ha két ablakban, egyenként 20-30 füllel volt megnyitva a FF. Aztán pár évvel később hibás szektorok jelentkezése miatt úgy döntöttem, ha már vinyócsere lesz, akkor kipróbálom a 64 bites változatot, egyúttal az éppen megjelenő 12.10-est teszem fel. Nos, azóta szenvedek a géppel: hosszú a történet, a lényeg az, a tünetek ugyanazok voltak, mint témaindító esetében. Memóriaellenőrzés, SMART-adatok lekérése megvolt, nem volt hiba. A lényeges momentum, hogy ekkor még nem SSD volt a gépben, hanem egy vadonatúj 500 GB-os HDD. (Tehát az SSD-nek szerintem semmi köze nincs a dologhoz, mint ahogy páran gondolják.) Ekkor viszont észrevettem, hogy az egyik SMART-paraméter, a Command timeout elkezdett növekedni, aami a nagy testvér szerint nem jó dolog. Na, gondoltam, biztos ez lesz a baj, a HDD-t lecseréltem SSD-re (60GB-os Kingstonra). Most is ez az SSD dolgozik, de sajnos a hiba csak jelentkezett egy hét hibamentes működés után... Viszont egy lényeges különbséget tapasztaltam: sokkal gyorsabban és könnyedebben tért magához a rendszer, egyszer sem kellett újraindítani a gépet; tehát az SSD-k előnye ebben is megmutatkozott. Minden ilyen eset után a SMART szerint 3-4 GB írási/olvasási művelet történik, tehát egyértelműen szweppel a rendszer, látszott is a top-ban a kswapd folyamat is.

Van swap, de a swappiness 0-ra van állítva, végszükség esetére. (2GB memória – tudom, hülyeség 64 bites rendszert rakni ennyivel rendelkező gépre, de tervezem a bővítést.) Nálam is csak FF alatt jelentkezett a dolog. Olyan is volt korábban, hogy nem volt cseretárhely, így előfordult, hogy elfogyott a memória; a logokban jelezte is a rendszer, sikeresen ki is lőtt pár alkalmazást, égett a HDD ledje olyankor is, de sokkal stabilabb maradt a rendszer. Most cseretárhellyel együtt nincs memóriahiányra való panaszkodás, de nem is sokat használ fel abból olyankor. Szóval szerintem nem a memóriával lehet a gond, bár elég sokat tud megenni a FF.

Én már csak arra tudok gondolni a hsz-k elolvasása után is, hogy magával a 64 bites rendszerrel (vagy a 64 bites FF-szal) lehet a gond... Korábban a 32 bites rendszeremen ilyen hibák nem mutatkoztak.

Mielőtt valaki felvetné, hogy csupán sima szweppelés volt, leírom: volt olyan eset, hogy fél órával a rendszerindulás után jelentkezett, alig pár használt füllel (FF), ráadásul semmi intenzív használat nem volt, szkájpon gépeltem, mikor észrevettem az akadozást. Bónusz: akkor teljesen meghalt a gép (HDD-vel), kikapcsológombra sem akart leállni a rendszer – fél óra várakozás után végül ki kellett lőni erőszakkal a rendszert, a fenti gomb hosszas nyomva tartásával...

( WG | 2014. 05. 16., p – 09:04 )

Sem az *SSD-hez, sem a Firefoxhoz, sem a 64 bithez, sem az ext4-hez nincs köze a hibának SZERINTEM.

Egy gépen 64 bites openSUSE megy évek óta hibátlanul.
Egy 60 GB-os SSD 10 GB-os partícióján van a / (ext4) és van még kb. 50 GB-nyi LUKS (ext4 ez is).
További 2 DB HDD-n szintén LUKS ext4-el.
Nincs SWAP, viszont van 32 GB RAM (akkor került a gépbe, amikor még szinte ingyen volt).
Mindig fut egy VirtualBox-ban valami, ami kap 4 GB-ot a RAM-ból, megy a FF 25-50+ nyitott tabbal, MetaTrader, Libreoffice Calc, KTorrent 800+ torrenttel, Thunderbird, 2 Konsole, egy Konqueror 2-5 tabbal, néha DVD írás, smplayer2-vel netrádió (, vagy FullHD sportesemény), TeamViewer... napi meló. Az összes program mindig fut és egyszerre.
Ezen a gépen fut még Apache, MySQL, PHP, kis terheléssel, továbbá Samba file-, és nyomtatószerver kicsit nagyobb terheléssel.

Amikor ezt a topicot elkezdtem tegnap olvasni, megnéztem és nálam 1 és 2 GB közötti RAM-ot eszik meg a Firefox és ez a folyamat fogyasztja a legtöbbet.

Soha nincs leállítva, vagy újraindítva a gép, hacsak nincs valami létfontosságú oka.
Persze tervezett leállások vannak és nyaralás alatt sem megy feleslegesen.

Tanácsot nem tudok adni, mivel sosem találkoztam ezzel a hibával, de hátha ebből valami okos következtetést tud valaki levonni.

Talán annyi lehet a konklúzió, hogy míg régebben volt a "csak netezni, meg tanulni kell"-gép, ill. a "játékra is alkalmas (komolyabb)" gép, addig ma már a netezéshez is olyan gép kell, ami meg van tömve minden földi jóval gazdagon. RAM, SSD, dedikált VGA (bár én pl. az I5 2500K integrált VGA-ját használom gond nélkül), mivel a mai webtartalom durván egy kisebb erőművet követel meg.

Szerk.: részlet a top-ból 


top - 01:33:56 up 7 days, 23:05,  4 users,  load average: 0,40, 0,29, 0,79
Tasks: 242 total,   1 running, 240 sleeping,   0 stopped,   1 zombie
%Cpu(s):  5,4 us,  1,5 sy,  0,0 ni, 93,0 id,  0,1 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:  32918592 total, 32174948 used,   743644 free,   851060 buffers
KiB Swap:        0 total,        0 used,        0 free, 23971480 cached

*OCZ SSD, ezekből volt Vertex 2, 3, Agility 3, 4, MAX IOPS, mindenféle, egyikkel sem volt soha baj. 

openSUSE 13.1 x86_64.

De, használok (+element hiding helper, noscript, flashblock ami említésre méltó). A notit ugyanis nem csak otthon használom, a router-re csak azért került "favágó adblock". (Mert a tököm tele lett vele, hogy android alatt az egyik kedvenc oldalamon a yahoo ads mindenféle alternatív market apk-kat tol az arcomba, meg redirect-el és ilyesmi.)

"viszont van 32 GB RAM"
Ja! Nálam nem tudom, hogy figyelted-e, de 4GB van. 32GB memória mellett lehet, hogy nem indítom ezt a topikot, mert nem lennének ilyen problémáim.

Nálam elindul a Virtualbox és a Firefox, kapásból 70% körülre ugrik a memória használat és akkor még nem csináltam semmit.

( vouilloz | 2014. 05. 16., p – 22:03 )

Szerintem sincs köze sem a memóriához sem az OS-hez, sem a fájlrendszerhez.
Ezt hibát én is tapasztaltam több különböző gépen és a megoldás (nekem) az SSD firmware frissítése volt.
A frissítés után a tünetek megszűntek.