Hirdetés

  2. Fórumok
  3. OS, alkalmazások
  4. Linux haladóknak
  5. (kiemelt téma)
  • Téma összefoglaló
    Utoljára frissítve: 2013-09-30 15:51

    LOGOUT

    Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.

Új hozzászólás Aktív témák

  • #22078 janos666 nagyúr #40553216 #22077
    Új Válasz #22078
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    janos666

    nagyúr

    válasz #40553216 #22077 üzenetére

    A drop_caches, mint chron job? For és While loop-olt bash script-ként is belebotlottam már az ötletbe, de ez legfeljebb is egy csúnya workaround (az elegáns workaround-okat jobb szeretem a bonyolult korrekt megoldásoktól, de szerintem ez ronda), amit viszonylag nehéz jól méretezni (egy 150 Mb/s lemez/kötet sebességet alapul véve legalább 1s-enként le kell futtatni, de a <<1s talán jelentékeny CPU terhelést és/vagy IO lassulást is okozhat).

    A másik, hogy nálam egy drop_cache után a memória 10%-a page cache, 1%-a buffer marad (egy magasabb értékről erre dobja vissza, akkor is ha előtte sync-elek). Ezek a számok gondolom nem véletlenül adódnak, főleg hogy most nem is kerek értékek (most épp 1300 Mb-ot adtam a VM-nek, és ezek így rendre 130 és 1.3 Mb méretűek). A 10% az alapértelmezett lazy_write határértékre emlékeztet, de azt hittem, hogy az az írási buffer felső határa, nem pedig a page cache része.

    Van a kommentek közt egy link glibc wrapper-hez, ami minden file-elérési műveletet direct_io-ra cserél. Ezt majd talán kipróbálom. De a 10+1%-ot szerintem ez sem tünteti el, ami ilyenkor feleslegessé válik. Bár egy sync mount opció talán igen.

Új hozzászólás Aktív témák