Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Laitealue => Aiheen aloitti: CoReD - 04.06.12 - klo:12.12
-
Koneessa:
- Xubuntu 12.04
- 4Gb rammia (~900megaa käytössä ja ~700megaa cahcena)
- Levynä WD:n 7200rpm 2TB (ikää vuoden verran, SMART OK)
- Swappia 2x RAM ja swappines vaihdettu arvoon 5 (swap myös pysyy tyhjänä, joten swappauksesta ei ole kyse)
- / , /var ja /home omilla osioillaan. (kaikki osiot ext4)
Kiitos jatkuvan raksutuksen tyhjensin koko levyn ja tein vain tarvittavan kokoiset osiot levyn alkupäähän ja jätin loppulevyn tyhjäksi, jotta kaikki data on mahdollisimman nopealla osalla levyä. Sama ongelma on myös Ubuntulla ja eri työpöytäympäristöillä, oli käytössä sitten Cinnamon, Unity, Gnome-panel tai openbox.
Idlenä jbd2/sda*-* kirjoittaa levylle jatkuvasti parin sekunnin välein. En tiedä onko jbd2 ainoa syypää, mutta oli kone käytössä tai idlenä niin tasaisen tappava raksutus kuuluu kiintolevystä. Raksutuksen aikana kone tahmaa, ihan valikoista lähtien.
Jbd2 liittyy ilmeisesti ext4 journalointiin..? Olisiko sitten aika siirtyä vaikka btfrs:n pariin, kun tämä levyn jatkuva raksutus tuntuu olevan ext4 ominaisuus...?
Koneella ei ole mitään ajastettuja/automaattisia varmuuskopiointeja/synkronointeja ja käynnistettävistä ohjelmista on karsittu turhat pois. Myöskään mitään automaattisesti päivittyviä sähköpostiohjelmia tai vastaavia ei ole käynnissä.
Suurin ongelma onkin sitten Chrome. Teki Chromella sitten mitä tahansa; avaa uuden välilehden, menee sivustolle, sulkee välilehden, kirjoittaa osoiteriville, niin iotop näyttää parikin chrome-prosessia jotka alkavat kirjoittelemaan ja raksutus on sen mukainen.
Tässä on se ärsyttävä puoli, että ilmiselvästi selain jää välillä odottamaan että kirjoittelut on kirjoiteltu, ennenkuin saa sivuston naaman eteen (eli hidastaa surffailua) ja aiheuttaa tahmailua esim. vierityksessä. Pahimmillaan sivu latautuu, mutta kiintolevy raksuttaa vielä muutaman sekunnin latauksen jälkeen, eikä itse sivustolla pysty tekemään tänä aikana mitään. Eroa paljon käytettyjen ja vähemmän käytettyjen sivustojen välillä ei ole. Raksutus kuuluu aina ja pahemmat jämähtelyt tulevat satunnaisesti sivustosta riippumatta.
Jotkut sivut aiheuttavat myös säännöllistä kirjoittelua, ollessaan vain taustalla ja kun joku taustalla oleva sivu aiheuttaa Chromelle kirjoitushaluja tahmaavat sitten kaikki välilehdet.
Pystyykö tuon Chromen kirjoitusintoa jotenkin rajoittamaan? En näe tuossa mitään järkeä, että tuo kirjoittaa kaiken mahdollisen levylle ja tahmauttaa itsensä ja samalla muutakin järjestelmää.
En tiedä sitten, auttaisiko preload ongelmiin? Viimeksi tosin, kun preloadia 12.04:ssä käytin, järjestelmä veti itsensä aivan juntturaan aina muutaman tunnin uptimen jälkeen. Ja käyttäähän järjestelmä jo nytkin keskusmuistia ihan kiitettävästi cachena, ainakin free -m mukaan. Se ei tosin näy käytännössä, koska levy raksuttaa jatkuvasti.
Olisiko vinkkejä miten edetä?
Olen SSD:täkin tässä jo miettinyt hyvän aikaa, kun vain raaskisi ostaa, mutta sitä suuremmalla syyllä olisi mukava tietää mistä tuo jatkuva raksutus aiheutuu ja miten sitä voisi hillitä. SSD:n käyttöikä kun lasketaan kirjoituskerroissa ja tällä raksutuksella en laittaisi ikäpäivänä kallista SSD:tä Ubuntu-koneeseen.
Mainitaan vielä, että käynnistyminen on ripeää ja levytoiminnot eivät muuten vaikuta hitailta. Prosessoritehokaan ei lopu kesken ja lämmöt on kurissa.
Ja iotopin mukaan kyse on nimenomaan kirjoituksesta. Chrome:n tapauksessa chrome-prosessit toki myös lukevat samalla, mutta kirjoitusta tapahtuu huomattavasti enemmän. jbd2 vain ja ainoastaan kirjoittaa.
Ja raksutus ei toki ole kateamatonta, vaan ruksruks, parin sekunnin tauko ja taas ruksruks. Välillä sitten oikein kunnolla ruksruksruksruksruks, vaikkei koneella mitään sellaista tapahtuisikaan, joka tuon selittäisi.
Edit:
Kysytääs tässä samalla kun kiintolevyyn liittyy yhtä lailla.
Eli tuossa kun tyhjentelin levyä huomasin, että vaikka asennusohjelmassa valitsin osioinnin itse, poistin kaikki osiot, tein uuden osiotaulun ja tein uudet osiot, järjestelmä numeroi nuo osiot ihan miten sattuu. Levyllä oli ennen iso tukku osioita (koska koneella oli useita eri distroja asennettuna) ja osiointiohjelma tuntui arpovan vanhoja numerointeja näille uusille osioille (joita siis lisäsin "tyhjälle" levylle). Tästä kun siirryin itse asennukseen, niin seuraavassa ruudussa oli jo valmiiksi vanhat nimi ja käyttäjätiedot, eli asennusohjelma haistoi jostain nekin, vaikka juuri "tyhjentämälleni" levylle oltiin asentamassa.
Tämän jälkeen kävinkin live-cd:llä poistamassa jälleen ne juuri tekemäni osiot ja loin yhden koko levyn kokoisen ext2 osion. Tämän jälkeen rebootin kautta asennus ja asennusohjelman kautta tuon ext2 osion poisto ja nykyiset ext4 osiot ja nyt asennusohjelma numeroi osiot oikein, eikä kaivanut nimi ja käyttäjätietoja jostain levyn syövereistä..
Tiedä häntä, eikö tuo asennusohjelma osaa oikeasti poistaa ja alustaa osioita kunnolla?
Edit2: tekstiä vähän selkeytetty
-
Vastaan itse itselleni Chromen osalta. Itseasiassa tein parikin muutosta.
Ensinnäkin; otin haittaohjelmasuojauksen pois päältä, poistin kaikki mahdolliset selaustiedot ja muutin
~/.cache/google-chrome
Kansion oikeudet "Vain luku" tilaan. Kansioihin ei enää ilmestynyt tavaraa, mutta iotop näytti Chromen kirjoittelevan edelleen johonkin.
Seuraavaksi:
sudo leafpad /usr/share/applications/google-chrome.desktop
Josta etsin seuraavan rivin:
Exec=/opt/google/chrome/google-chrome %U
Jonka muutin muotoon:
Exec=/opt/google/chrome/google-chrome --disk-cache-dir=/dev/null
Nyt iotopissa ei enää chromet heilu ja sen sijaan näkyy vain välistä null siellä pomppivan, mutta sepä ei kiintolevylle mitään todellisuudessa raksuta. Myös korvakuulolla eron huomaa.
Hetken pelkäsin, että menee selailu hitaaksi kun koko cachen käytön menee estämään, mutta eipä tämä nyt kovin hitaalta vaikuta vaikka mokkulayhteyden perässä olenkin. Kunnon kaapelin perässä ei varmaan huomaa mitään eroa.
Jbd2 on edelleen arvoitus.. Ei huvittaisi tehdä uutta asennusta esim. btrfs:llä ja katsoa onko sen kanssa elämä helpompaa, joten vinkkejä kaivataan edelleen :)
-
Hetken pelkäsin, että menee selailu hitaaksi kun koko cachen käytön menee estämään, mutta eipä tämä nyt kovin hitaalta vaikuta vaikka mokkulayhteyden perässä olenkin. Kunnon kaapelin perässä ei varmaan huomaa mitään eroa.
Sen cachen voisi varmaan työntää muistiinkin (jos ei jo ole siellä Chromen toimesta) esimerkiksi tmpfs:llä. Vähemmän ympäristökuormitustahan siitä tulisi (oikeastikin).
-
Hetken pelkäsin, että menee selailu hitaaksi kun koko cachen käytön menee estämään, mutta eipä tämä nyt kovin hitaalta vaikuta vaikka mokkulayhteyden perässä olenkin. Kunnon kaapelin perässä ei varmaan huomaa mitään eroa.
Sen cachen voisi varmaan työntää muistiinkin (jos ei jo ole siellä Chromen toimesta) esimerkiksi tmpfs:llä. Vähemmän ympäristökuormitustahan siitä tulisi (oikeastikin).
Tmpfs:ää tuossa jo jonkin aikaa mietiskelin. Lähinnä nyt vain haetaan kynnystä lähteä säätämään lisää kun näinkin toimii.
Mitä tässä olen googletellut, niin ongelmat jpd2:en kanssa johtuisi ilmeisesti ihan kernelbugista joka vaivaa nyt ext3 ja ext4:ää. Arch-käyttäjät yrittäneet enemmänkin selvitellä, mutta mitään kikkakolmosta ei kait ole vielä löytynyt. Noatimie, commit yms. eivät tuohon auta.
Oliskos se sitten Btrfs vai ReiserFS ? ::)
Edit: vilkaiskaas ny piruuttaan muutkin iotopilla, pomppiiko teilläkin tuo jpd2/sda*-* siellä 2-10sek välein.. Jos kyseessä on tosissaa kernelbugi niin tuon pitäisi olla muillakin vaivana. Eri juttu tietysti onko niin tehokkaat koneet ja nopeat levyt että huomaisi käytössä mitään, mutta mekaanisien limppujen omistajien pitäisi kyllä jo äänestä kuulla, että joku siellä jauhaa levyä ihan turhan päiten.
Edit2: katsoin piruuttaan läppärilläkin, jossa ihan sama homma. Muutaman päivän vanha Xubuntu 12.04 ja ext4 kaikilla osioilla. Pahimmillaan pomppii kolmekin jpd2/sda*-* prosessia samanaikaisesti.. Läppärillä en ole tuota edes huomannut, kun ei kiintolevyn äänet kuulu rungon läpi ja ledikin sellaisessa paikassa ettei sitä tule huomioitua. Ajatellut että hidastelee vanhuuttaan.
-
Enimmän ajasta tämmönen kiltisit tuolla listassa alempana, joskus tulee (toinen?) tuommoinen näkyviin ja käyttää kymmenestä viiteenkymmeneenkin prosenssia io:ta. Ei kuitenkaan hyvin usein.
91 be/3 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [jbd2/sda1-8]Alla Arch Linux uusimmilla päivityksillä. Tiedostojärjestelmänä ext4.
Muokkaus: Pistin koneen kiinni verkkovirtaan ja nepomuk alkoi indeksoida. Nyt näkyy jbd2 ylimpänä aina sillon tällön ja niitä on kaksi. Prosentteja ei kuitenakaan ole kuin muutamia.
Huomasin myös, että kone lämpesi aika mukavasti (ei olisi pitänyt, kun ei ollut juurikaan kuormaa). Katsoin topilla ja näköjään iotop oli siellä kuluttamassa noin 100% suoritinajasta. Miksihän...? Olin jo sulkenut sen (olevinaan), joten tapoin pois kuluttamasta.
-
Itsellä noita pomppii pahimmillaan kolmekin samanaikaisesti. sda1-8 , 5-8 ja 7-8. IO:ta vievät samaa luokkaa. Levy on ehkä parhaimmillaan 20sek kirjoittamatta, mutta pääsääntöisesti tuo aikaväli vaihtelee siinä 2-10sek välillä.
En sitten tiedä, pitäisikö kokeilla poistaa journalointi noista ext4 osioista kokonaan. Sehän taitaa olla mahollista tune2fs:llä livecd:ltä? Työpöytäkäytössä nyt pitäisi mitään mainittavaa haittaakaan aiheuttaa.
Toisaalta voisi suosiolla (ja kokeilemisen ilosta) kokeilla suoriltaan vaikka ReiserFS:ää. Eipähän tarvitse pähkäillä tuon kanssa :P Voi saada kiintolevy useammankin tunnin lisää käyttöikää ja pääsee turhista raksutteluista ja tahmailuista eroon.
Edit:
Itsellä ei tuo iotop vie suoritinaikaa juuri lainkaan..? Olisiko sitten Archin repoissa joku epävakaampi versio ohjelmasta joka päässyt kaatumaan? Noh, anyway, jotain epätavallista on joka tapauksessa tapahtunut jos iotop on jäänyt taustalle vaikka se olisi jo suljettu. Ei tosiaan tuon iotopin kanssa itsellä mitään ongelmia.
Nepomukin kanssa jbd2 tekee varmasti sitä mitä sen pitääkin, mutta idlenä sillä ei ole mitään syytä eikä tarkoitusta kirjoitella jatkuvasti levylle.
Juttua muualla:
http://ubuntuforums.org/showthread.php?t=1862774
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560
https://bbs.archlinux.org/viewtopic.php?pid=1094987
https://bugzilla.kernel.org/show_bug.cgi?id=42895
https://bbs.archlinux.org/viewtopic.php?pid=765666
-
Onko kyseessä Western Digitalin Caviar Green kiintolevy? Jos on kannattaa checkata tämä linkki: http://mato78.com/uutiset/hardware/3549-western-digitalin-caviar-green-sarjan-kiintolevyissae-kriittinen-suunnitteluvirhe (http://mato78.com/uutiset/hardware/3549-western-digitalin-caviar-green-sarjan-kiintolevyissae-kriittinen-suunnitteluvirhe)
-
Onko kyseessä Western Digitalin Caviar Green kiintolevy? Jos on kannattaa checkata tämä linkki: http://mato78.com/uutiset/hardware/3549-western-digitalin-caviar-green-sarjan-kiintolevyissae-kriittinen-suunnitteluvirhe (http://mato78.com/uutiset/hardware/3549-western-digitalin-caviar-green-sarjan-kiintolevyissae-kriittinen-suunnitteluvirhe)
On. Tarkemmin ottaen WD20EARS. Kyseiselle limpulle on myös tehty tuo samainen ajastustemppu samana päivänä, kun tuo linkkaamasi uutinen on julkaistu ;)
Itse kovalevyssä ei ole mitään vikaa (vähän ihmettelenkin miksi tämä siirettiin laitealueelle, koska "vian" aiheuttaa itse käyttöjärjestelmä/ohjelmisto (chromepulma on jo ratkaistu)). Kyse on vain siitä, että jbd2 kirjoittaa levylle jatkuvasti aiheuttaen luonnollisesti ärsyttävää raksutusta, aiheuttaen huolta kiintolevyn eliniästä ja toisaalta heijastuu myös itse käyttökokemukseen tahmailuna.
Ja koska SSD on jokatapauksessa ostoslistalla, niin tämä ongelma kiinnostaa entistä enemmän, koska en todellakaan halua uhrata sitä tiedostojärjestelmälle jonka "ominaisuus" on "syödä levyn elinikää" turhanpäiväisellä kirjoittelulla. Mutta kuten sanottua ja linkitettyä, tähän ei ole taidettu keksiä ratkaisua vielä lainkaan. Mielenkiintoista on myös se, että heillä joilla samaa ongelmaa on, ei löydy yhtenäistä tekijää, taustaprosessia, distroa, kerneliä tai kokoonpanoa. Ja mitä ilmeisemmin, ongelmaa ei kuitenkaan ole kaikilla Linuxin käyttäjillä.
Sen myötä kiinnostaa toki myös se, että kuinka monella tätä samaa ongelmaa esiintyy tietämättä ja voisiko tämä bugi olla useammallakin käyttäjällä mahdollisen tahmailun aiheuttaja. Ilmiselvää, että hitaalla levyllä/muuten hitaalla raudalla tälläinen ylimääräinen kirjoitusoperaatio voi vaikuttaa suorituskykyyn paljonkin. Yhtälailla kuin esim. läppärin akun kestoon, kiintolevyn lämpöongelmiin yms.
-
Tjoo, iotop jää päälle jos terminaalin ikkunan sulkee. En tiedä onko bugi vai omituisuus (siis ominaisuus). Kokeilen huomenna pöytäkoneella (Ubuntu 12.04 LTS), mutta tällä läppärillä (Arch Linux) sitä ei ainakaan tapahdu. Odottelin pari minuuttia iotop auki, nepomuk sammutettuna eikä mitään tapahtunut.
Muokkaus: Testasin pöytäkoneella, ei ongelmaa.
-
Ja koska SSD on jokatapauksessa ostoslistalla, niin tämä ongelma kiinnostaa entistä enemmän...
Itsellä on kolmessa EeePC.ssä SSD:t ja olen koittanut minimoida levyn käytön siirtämällä kaiken 'turhan' sekä cachet RAM:lle (2 GB).
Olisi kuitenkin mukava varmistaa, että homma on vireessä.
Onko selvää komentoa, joka näyttäisi, miten paljon ja kenen toimesta on kirjoitustoimintaa SSD:lle ? Levyn merkkivalo ei kerro kaikkea.
-
Onko selvää komentoa, joka näyttäisi, miten paljon ja kenen toimesta on kirjoitustoimintaa SSD:lle ? Levyn merkkivalo ei kerro kaikkea.
No tuo em. iotop.
Kokeilin juuri omalla läppärillä (xubuntu 12.04). Painoin ensin 'o', ettei iotop näytä mitään ylimääräistä. Jonkin aikaa odoteltuani firefox tuli näkyviin ja sitten (muutaman sekunnin kuluttua) jfscommit (käytössä jfs) ja flush, samalla levyvalo vilahti. Muutaman minuutin tuijottelun jälkeen näyttää että nuo vuorottelevat epäsäännöllisesti. Kerran vilahti myös joku xfce-ohjelma, en muista nimeä.
Se että ff ajoittain kirjoittelee, on minusta normaalia. Enkä ole mitenkään yrittänyt sitä estää. Sitten kun on aika piikata data levylle, aktivoituvat jfscommit ja flush. Cachesta johtuen syy-seuraus suhteet voi olla hankalia hahmottaa. Journaloinnin tuunaus tai poisto keventää io:ta vaikkei poistaisikaan kirjoittelua.
-
Kokeilin eilen Xubuntua / ja /home XFS osioilla, mutta oli kyllä käynnistyminen niin hidasta (yli 2x hitaampaa kuin ext4:llä), että päätin unohtaa koko jutun ja asentelin taas tuoreen Xubuntun EXT4:llä, niinkuin ennenkin.
Räpeltäessäni heitin koko ~/.cache hakemiston tmpfs:llä RAMmin puolelle (saa nähdä miten tuo määrittämäni 1024MB sille pitemmällä uptimellä piisaa) ja olen tässä koittanut löytää tuon jbd2:en ylivilkkaudelle jotain järkevää syytä. Pähkäilin tuossa eilen illalla asiaa enemmänkin ja vaikka tuo on tosiaan kernelbugina raportoitu (ja sellaisena sitä itsekkin tästä syystä olen likipitäen kokoajan pitänyt) niin tuntuu uskomattomalta, että ongelmaa ei olisi sitten täälläkin kaikilla.
Kiitos tuon retun 'o'-vinkin, bongasin lopulta myös 'chrome --no-startup-window' prosessin kirjoittelevan samaan aikaan jbd2:en kanssa parin sekunnin välein. Tätä ei ole tuossa perusnäkymässä näkynyt kertaakaan, joten on näyttänyt siltä, että jbd2 kirjoittelee yksinään.
Googlaus selvensi asiaa tämän verran:
"Does not automatically open a browser window on startup (used when launching Chrome for the purpose of hosting background apps)."
Chromen asetuksista tosin on tämä asetus ollut aina pois päältä:
'Continue running background apps when Google Chrome is closed'
Mutta, killall chrome ja chromen uudelleenkäynnistys hävitti tuon prosessin ja rauhoitti jbd2:enkin.
Täytyy katsoa, palaako tuo samainen 'chrome --no-startup-window' rebootin jälkeen taas takaisin, tarvitsee se sitten kaivaa jostain, että saa sen suorituksen käynnistyksessä estettyä..
Mielenkiintoista on myös se, että heillä joilla samaa ongelmaa on, ei löydy yhtenäistä tekijää, taustaprosessia, distroa, kerneliä tai kokoonpanoa.
Onko tämä yhteinen tekijä sitten Chrome? :D
-
Entäs sitten kaikenlaiset logitukset /var/log ...
Sinnehän tulee koko ajan tavaraa...
-
Eipä Linux taida sekunti sekuntilta turhia loggailla, jos ei koneellakaan mitään tehdä. :P Ongelmahan oli alusta asti se, että kone pommitti levyä idlenäkin.
Anyway... Poistin ja asensin Chromen uudelleen, laitoin tuoreen asennuksen asetuksista tuon ''Continue running background apps when Google Chrome is closed' pois päältä ja vasta tämän jälkeen synkkasin Chromen G-tilini kanssa.
Vahva epäilys, että jostain syystä tuo Chrome on asennuksen jälkeen asettanut tuon 'chrome --no-startup-desktop' suoritettavaksi, muttei ole osannut sitä sitten asettaa pois kun olen asetukset synkannut G-tilin kautta. Siksi tein tuon nyt näin ja vaikuttaisi jopa toimivan. Tiedä häntä, jännä juttu.
Asentelin myös Archista tutun profile-sync-daemonin (http://ubuntuforums.org/showthread.php?t=1921800) ja räpeltelin fstabin ja tmpfs:n kanssa vähän enemmänkin. Nyt pyörii sitten Chrome profiileineen RAMissa, samoin kun spotify cachet yms. levyntappajat :P
Nyt kiintolevy on hiljaa, turhia kirjoituksia ei näy ja homma toimii niinkuin pitääkin. Tällä erää siis näyttää, että Chrome olikin kaiken pahan takana, vaikka tässä ehdittiinkin jo ext4:ää syyttää ;D
[RATKAISTU]
Seuraavaksi sitten läppärin kimppuun. :)
-
Kiitos "iotop" vinkistä, tuo onkin hyödyllinen apuväline. Sillä saa kätevästi myös pitkäaikaista kumulatiivista tilastoa kun antaa "-ao" -vivut perään:
sudo iotop -ao
jolloin tiedot myös pysyvät näytöllä jatkuvasti.
-
räpeltelin fstabin ja tmpfs:n kanssa vähän enemmänkin.
Haluaisitko kertoa muillekin tarkemmin, mitä kaikkea lopulta jouduit tekemään? Alkaa nimittäin vähitellen ärsyttää ihan tosissaan tuo juuri kuvailusi mukainen kovalevyn rouskuttaminen. Sama jbd2 täälläkin näyttäisi kirjoittelevan idlenäkin. Tämä sama ongelma näyttäisi noiden linkkiesi perusteella vaivanneen muitakin jo vuodesta 2010 lähtien, joten mitään "viralliselta" taholta tulevaa korjausta minä en tähän vaivaan ainakaan henkeä pidätellen enää odottelisi...
Omien kokemusteni mukaan 10.04:ssä tätä vikaa ei vielä ollut, mutta kun siirryin suoraan 12.04:ään niin rouskutus alkoi.