it-swarm-eu.dev

Mohu svůj systém Linux nakonfigurovat pro agresivnější ukládání do mezipaměti souborového systému?

Nemám obavy ani o využití RAM (jak mám dost), ani o ztrátě dat v případě náhodného vypnutí (protože moje energie je zálohována, systém je spolehlivý a data jsou nejsou kritické). Ale dělám spoustu zpracování souborů a mohu použít nějaké zvýšení výkonu.

Proto bych chtěl systém nastavit tak, aby používal více RAM pro ukládání a zápis do mezipaměti souborového systému, agresivní předběžné načítání souborů (např. Čtení celého souboru přístupného aplikací v případě, soubor má rozumnou velikost, nebo alespoň čte dopředu velký kus, jinak) a vyprázdnění psaní vyrovnávacích pamětí méně často. Jak toho dosáhnout (je to možné)?

Používám souborové systémy ext3 a ntfs (hodně používám ntfs!) S XUbuntu 11.10 x86.

124
Ivan

Zlepšení výkonu mezipaměti disku obecně znamená více než jen zvětšení velikosti mezipaměti souborového systému, pokud váš celý systém nezapadá do RAM, v tom případě byste měli použít RAM (tmpfs je dobrá, protože umožňuje pád zpět na disk, pokud potřebujete pro uložení za běhu (a možná i initrd skript) RAM v některých případech) zkopírujte systém z úložiště na RAM jednotka při spuštění).

Neřekli jste, zda je vaše úložné zařízení SSD nebo HDD. Tady je to, co jsem zjistil, že pro mě pracuje (v mém případě sda je HDD připojený na /home a sdb je připojeno SSD v /).

Nejprve optimalizujte část load-stuff-from-storage-to-cache:

Tady je moje nastavení pro HDD (ujistěte se, že AHCI + NCQ je povoleno v BIOSu, pokud máte přepínače):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

Za zmínku stojí případ HDD fifo_expire_async (obvykle psát) a dlouhé slice_sync pro umožnění jednoho procesu získat vysokou propustnost (set slice_sync na nižší číslo, pokud narazíte na situace, kdy několik procesů čeká na data z disku paralelně více procesů). The slice_idle je vždy kompromisem pro HDD, ale jeho nastavení někde v rozsahu 3-20 by mělo být v pořádku v závislosti na využití disku a firmwaru disku. Dávám přednost cílení na nízké hodnoty, ale nastavení příliš nízké zničí vaši propustnost. Zdá se, že nastavení quantum hodně ovlivňuje propustnost, ale zkuste to udržet co nejníže, aby latence zůstala na rozumné úrovni. Nastavení příliš nízké hodnoty quantum zničí propustnost. Zdá se, že hodnoty v rozmezí 3-8 s HDD fungují dobře. Nejhorší latence pro čtení je (quantum * slice_sync) + (slice_async_rq * slice_async) ms, pokud jsem správně porozuměl chování jádra. Async je většinou používán zápisy a protože jste ochotni zpoždění zápisu na disk, nastavte obojí slice_async_rq a slice_async na velmi nízká čísla. Nastavení slice_async_rq Příliš nízká hodnota může zastavit čtení, protože zápisy již nemohou být odloženy. Moje konfigurace se pokusí zapsat data na disk nejpozději po 10 sekundách poté, co byla data předána jádru, ale protože můžete tolerovat ztrátu dat při ztrátě energie, nastavte také fifo_expire_async to 3600000, abyste řekli, že 1 hodina je v pořádku pro zpoždění na disk. Jen mějte slice_async nízká, protože jinak můžete získat vysokou latenci čtení.

Příkaz hdparm je vyžadován, aby zabránil AAM zabíjet většinu výkonu, který AHCI + NCQ umožňuje. Pokud váš disk vydává příliš mnoho šumu, přeskočte toto.

Zde je moje nastavení pro SSD (řada Intel 320):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Zde stojí za zmínku nízké hodnoty pro různá nastavení řezů. Nejdůležitější nastavení SSD je slice_idle, které musí být nastaveno na 0-1. Nastavení na nulu přesune všechna rozhodnutí o řazení do nativního NCQ, zatímco nastavení na 1 umožňuje jádru objednávat žádosti (ale pokud je NCQ aktivní, hardware může částečně potlačit řazení jádra). Otestujte obě hodnoty, abyste zjistili, zda vidíte rozdíl. U řady Intel 320 se zdá, že nastavení slide_idle to 0 dává nejlepší propustnost, ale nastaví ji na 1 dává nejlepší (nejnižší) celkovou latenci.

Další informace o těchto laditelných souborech viz https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt .

Nyní, když jsme nakonfigurovali jádro tak, aby načítalo věci z disku do mezipaměti s rozumným výkonem, je čas upravit chování mezipaměti:

Podle měřítek, které jsem udělal, bych se vůbec neobtěžoval nastavovat čtení napřed přes blockdev. Výchozí nastavení jádra je v pořádku.

Nastavte systém, aby upřednostňoval výměnu dat souboru před kódem aplikace (nezáleží na tom, zda máte dost RAM, aby celý souborový systém a všechny kód aplikace a veškerá virtuální paměť přidělená aplikacemi v paměti RAM), což snižuje latenci pro výměnu mezi různými aplikacemi za latenci pro přístup k velkým souborům z jedné aplikace:

echo 15 > /proc/sys/vm/swappiness

Pokud dáváte přednost tomu, aby aplikace zůstaly téměř vždy v RAM, mohli byste to nastavit na 1. Pokud nastavíte nulu, jádro se vůbec nevymění, pokud to není nezbytně nutné, aby se zabránilo OOM. Pokud jste měli paměť omezené a práce s velkými soubory (např. HD video editace), pak by mohlo být rozumné nastavit toto blízko 100.

Dnes (2017) raději nemám vůbec swap, pokud máte dostatek paměti RAM. Bez swapu obvykle ztratí 200-1000 MB RAM = na dlouho běžícím stolním počítači). Jsem ochoten obětovat tolik, abych se vyhnul latenci scénáře nejhoršího případu (zaměnit kód aplikace, když RAM je plný). V praxi to znamená, že dávám přednost OOM Killerovi před swapováním. Pokud povolíte/potřebujete swapování, možná budete chtít zvýšit /proc/sys/vm/watermark_scale_factor také, abychom se vyhnuli určité latenci. Navrhoval bych hodnoty mezi 100 a 500. Toto nastavení můžete považovat za obchodování s CPU za nižší swapovou latenci. Výchozí hodnota je 10 a maximální možné je 1000. Vyšší hodnota by měla (podle dokumentace k jádr ) vést k vyššímu využití CPU pro procesy kswapd a nižší celkové latenci swapování).

Dále řekněte jádru, aby upřednostňovalo uchovávání hierarchie adresářů v paměti před obsahem souboru v případě, že je třeba uvolnit některé RAM (znovu, pokud se vše vejde do RAM, toto nastavení neudělá nic):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Nastavení vfs_cache_pressure na nízkou hodnotu má smysl, protože ve většině případů musí jádro znát strukturu adresářů, než bude moci použít obsah souboru z mezipaměti a příliš brzy vyprázdnění adresářové mezipaměti způsobí, že mezipaměť souborů bude bezcenná. Pokud máte spoustu malých souborů, zvažte nastavení až na 1, pokud máte spoustu malých souborů (můj systém má asi 150 kB 10 megapixelových fotografií a počítá se jako systém „spousty malých souborů“). Nikdy nenastavujte na nulu nebo struktura adresářů je vždy uchována v paměti, i když je systém v paměti nedostatek. Nastavení této hodnoty na vysokou hodnotu je smysluplné pouze v případě, že máte jen několik velkých souborů, které se neustále znovu čtou (opět by bylo možné editovat HD video bez dostatečného množství RAM by byl příkladem). dokumentace říká, že „zvýšení vfs_cache_pressure výrazně nad 100 může mít negativní dopad na výkon“.

Výjimka: , pokud máte skutečně obrovské množství souborů a adresářů a zřídka se dotknete/přečtete/vypíšete nastavení všech souborů vfs_cache_pressure vyšší než 100 může být moudré. To platí pouze v případě, že nemáte dost RAM a nemůžete udržet celou strukturu adresářů v RAM a stále máte dost RAM) pro normální mezipaměť souborů a procesy (např. souborový server společnosti se spoustou archivního obsahu). Pokud máte pocit, že je třeba zvýšit vfs_cache_pressure nad 100 běžíte bez dostatečného množství paměti RAM. Vzrůstající vfs_cache_pressure může pomoci, ale jediná skutečná oprava je získat více paměti RAM. Mít vfs_cache_pressure nastaven na vysoký počet obětí průměrný výkon za celkově stabilnější výkon (tj. můžete se vyhnout opravdu špatnému chování v nejhorším případě, ale musíte se vypořádat s horším celkovým výkonem).

Nakonec řekněte jádru, aby použilo až 99% z RAM jako mezipaměť pro zápisy), a přikáže jádru použít až 50% RAM) před zpomalením proces, který zapisuje (výchozí pro dirty_background_ratio je 10). pozornění: Já osobně bych to neudělal, ale tvrdili jste, že máte dost RAM a jste ochotni data ztratit.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

A řekněte, že 1h zpoždění zápisu je v pořádku, dokonce start ​​zápis věcí na disk (znovu bych to neudělal):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Další informace o těchto laditelných souborech viz https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Pokud všechny umístíte na /etc/rc.local a na konci zahrňte následující, vše bude v mezipaměti co nejdříve po spuštění (to jen pokud váš souborový systém opravdu zapadá do RAM):

(Nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | Nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Nebo o něco jednodušší alternativu, která by mohla fungovat lépe (pouze mezipaměť /home a /usr, udělejte to, pouze pokud vaše /home a /usr opravdu zapadá do paměti RAM):

(Nice find /home /usr -type f -print0 | Nice ionice -c 3 wc -l --files0-from - > /dev/null)&
113

Nejprve nedoporučuji pokračovat v používání systému NTFS, protože implementace systému NTFS v systému Linux by byla kdykoli problémem s výkonem a zabezpečením.

Můžete udělat několik věcí:

  • použijte novější fs, jako je ext4 nebo btrfs
  • zkuste změnit plánovač io, například bfq
  • vypněte swap
  • použít nějaký automatický předpínač jako preload
  • před zavedením při zavádění použijte něco jako systemd
  • ... a něco víc

Možná to chcete zkusit :-)

16
Felix Yan

Čtěte dopředu:

Na 32bitových systémech:

blockdev --setra 8388607 /dev/sda

V 64bitových systémech:

blockdev --setra 4294967295 /dev/sda

Zápis za mezipaměť:

echo 100 > /proc/sys/vm/dirty_ratio

To využije až 100% volné paměti jako mezipaměť pro zápis.

Nebo můžete jít ven a používat tmpfs. To je relevantní pouze v případě, že máte dost RAM). Vložte to do /etc/fstab. Nahraďte 100G množstvím fyzické paměti RAM.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Pak:

mkdir /mnt/tmpfs; mount -a

Pak použijte/mnt/tmpfs.

8
Ole Tange

Velikost pro čtení předem můžete nastavit pomocí blockdev --setra sectors /dev/sda1, kde sektory je velikost, kterou chcete v 512 bytových sektorech.

6
psusi

Moje nastavení vraha je velmi jednoduché a velmi efektivní:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

Vysvětlení od dokumentace k jádr :

vfs_cache_pressure

Řídí tendenci jádra získat zpět paměť, která se používá pro ukládání do mezipaměti adresářových a inode objektů.

Při výchozí hodnotě vfs_cache_pressure = 100 se jádro pokusí získat zpětný odběr a inody za "spravedlivou" sazbu s ohledem na regeneraci stránky a swapcache. Snížení vfs_cache_pressure způsobí, že jádro upřednostňuje uchování mezipaměti a inode. Když je vfs_cache_pressure = 0, jádro nikdy nebude získávat zpětné vazby a inody kvůli tlaku v paměti, což může snadno vést k podmínkám nedostatku paměti. Zvyšující se tlak vfs_cache_pressure nad 100 způsobí, že jádro upřednostňuje regeneraci protéz a inod.

vfs_cache_pressure v roce 2000 způsobí, že většina práce na počítači se odehrává v RAM a velmi pozdě zapisovaných discích).

2
user55518

Nesouvisí s mezipamětí zápisu, ale týká se zápisů:

  • Pro systém ext4 byste mohli úplně zakázat žurnálování

    Tím se sníží počet zápisů na disk pro každou konkrétní aktualizaci, ale po neočekávaném vypnutí může dojít k nekonzistentnímu stavu souborového systému, který vyžaduje fsck nebo horší.

Chcete-li zastavit čtení disku z spouštění zápisu na disk:

  • Připojte se s volbou relatime nebo noatime

    Při čtení souboru se obvykle aktualizují metadata „posledního přístupového času“ pro tento soubor. Volba noatime toto chování zakáže. Tím se sníží zbytečné zápisy na disk, ale tato metadata již nebudete mít. Některé distribuce (např. Manjaro) toto přijaly jako výchozí na všech diskových oddílech (pravděpodobně ke zvýšení životnosti starších SSD disků).

    relatime aktualizuje čas přístupu méně často, podle heuristiky, která pomáhá podporovat aplikace, které používají atime. Toto je výchozí nastavení v Red Hat Enterprise Linux.

Jiné možnosti:

  • Ve výše uvedených komentářích Mikko sdílel možnost montáže s možností nobarrier . Ale Ivailo citováno RedHat kdo varuje před tím. Jak moc chcete, že navíc 3%?
1
joeytwiddle