- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Meggyi001: Nyilvános wc-k.....még mindig hiánypótló...
- Elektromos rásegítésű kerékpárok
- eBay-es kütyük kis pénzért
Hirdetés
Aktív témák
-
decoati
aktív tag
szóval ez az egész cache-esdi tudtommal arról szól, hogy az i/o műveletek nem akkor hajtódnak végre fizikailag a háttértáron amikor az logikailag megtörténik, mivel van egy "disk leképeződés" a memóriában. Ennek különösen nagy jelentősége van ssd háttértáraknál, wear leveling ide vagy oda. Ennek a kiírásnak a gyakoriságát/agresszivitását szabályozza az i/o scheduler.
A sync, echo 3 > proc/sys/vm/drop_caches egy réges-régi linux versike, ami kisynceli a dirty tartalmakat, (tehát minden kiírás megtörténik fizikailag), és dobja a cache-t. (mellesleg sgs-en létezik a path...)
A kérdésem első fele az lett volna hogy ez a cache cleaner ekvivalens-e a drop_cache időzített futtatásával, a második része megy hogy van-e arról gyakorlati tapasztalatod hogy mennyivel célszerűbb ezt időnként automatizáltan végrehajtani, mint választani pl. egy BFQ schedulert?
szerk.: ez a cache cleaner egyáltalán automatikus, vagy manuális? tényleg nem ismerem
Aktív témák
Hirdetés
- Szép HP EliteBook 840 G9 Fémházas Hordozható Érintős Ultrabook 14" -40% i5-1235U 32/1TB Iris Xe FHD+
- Logitech G935
- Creative Sound Blaster Live! 5.1-es digitális PCI hangkártya
- Rock Shox Recon Silver Air gyorszáras villa eladó (29-es)!
- ÚJ Nvidia RTX 5060/TI 8-16Gb GDDR7 DLSS4.0 Ryzen 7 5800X 16x4.7Ghz/32GB/512Gb/1TB M SSD/2ÉV gamer PC
Állásajánlatok
Cég: FOTC
Város: Budapest