Czy mogę skonfigurować mój system Linux pod kątem bardziej agresywnego buforowania systemu plików?

Nie martwię się ani o użycie pamięci RAM (ponieważ mam już dość), ani o utratę danych w przypadku przypadkowego wyłączenia (ponieważ moja moc jest podtrzymywana, system jest niezawodny, a dane nie są krytyczne). Ale dużo przetwarzam pliki i przydałby mi się wzrost wydajności.

Dlatego chciałbym skonfigurować system tak, aby używał więcej pamięci RAM do buforowania odczytu i zapisu systemu plików, aby pobierać pliki agresywnie (np. Z wyprzedzeniem odczytaj cały plik, do którego aplikacja ma dostęp, jeśli plik ma rozsądny rozmiar lub przynajmniej w przeciwnym razie przeczytaj duży fragment) i rzadziej opróżniaj bufory zapisu. Jak to osiągnąć (czy to możliwe)?

Używam systemów plików ext3 i NTFS (często używam NTFS!) Z XUbuntu 11.10 x86.

Ogólnie rzecz biorąc, poprawa wydajności pamięci podręcznej dysku jest czymś więcej niż tylko zwiększeniem wielkości pamięci podręcznej systemu plików, chyba że cały system mieści się w pamięci RAM. W takim przypadku należy użyć napędu RAM ( tmpfsjest to dobre, ponieważ w niektórych przypadkach umożliwia powrót do dysku) do przechowywania w środowisku wykonawczym (i być może skrypt initrd do kopiowania systemu z pamięci na dysk RAM podczas uruchamiania).

Nie wiesz, czy twoim urządzeniem pamięci jest dysk SSD czy HDD. Oto, co dla mnie działa (w moim przypadku sdajest to dysk twardy zamontowany w, /homea sdbdysk SSD zamontowany w /).

Najpierw zoptymalizuj część load-stuff-from-storage-to-cache:

Oto moja konfiguracja dysku twardego (upewnij się, że AHCI + NCQ jest włączony w systemie BIOS, jeśli masz przełączniki):

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

Warto zauważyć, że przypadek dysku twardego jest wysoki fifo_expire_async(zwykle zapis) i długi, slice_syncaby umożliwić pojedynczemu procesowi uzyskanie wysokiej przepustowości (ustaw slice_syncniższą liczbę, jeśli trafisz na sytuacje, w których wiele procesów czeka równolegle na niektóre dane z dysku). Jest slice_idleto zawsze kompromis w przypadku dysków twardych, ale ustawienie go gdzieś w zakresie 3-20 powinno być w porządku, w zależności od użycia dysku i oprogramowania układowego dysku. Wolę celować na niskie wartości, ale ustawienie go zbyt nisko zniszczy Twoją przepustowość. To quantumustawienie wydaje się mieć duży wpływ na przepustowość, ale staraj się utrzymywać ją na jak najniższym poziomie, aby utrzymać opóźnienie na rozsądnym poziomie. Ustawienie quantumzbyt niskiej wartości zniszczy przepustowość. Wartości w zakresie 3-8 wydają się dobrze współpracować z dyskami twardymi. Najgorsze opóźnienie dla odczytu to ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms, jeśli poprawnie zrozumiałem zachowanie jądra. Asynchronizacja jest najczęściej używana przez zapisy, a ponieważ chcesz opóźnić zapis na dysk, ustaw zarówno slice_async_rqi slice_asyncbardzo niskie liczby. Jednak ustawienie slice_async_rqzbyt niskiej wartości może opóźnić odczyty, ponieważ zapisy nie mogą być dłużej opóźniane po odczytach. Mój config spróbuje zapisać danych na dysku co najwyżej po 10 sekundach po dane zostały przekazane do jądra, ale ponieważ można tolerować utratę danych dotyczących strat mocy również zestaw fifo_expire_asyncdo 3600000powiedzieć, że 1 godzina jest w porządku za opóźnienie na dysku. Po prostu utrzymuj slice_asyncniski poziom, ponieważ w przeciwnym razie możesz uzyskać duże opóźnienie odczytu.

hdparmKomenda jest wymagane, aby zapobiec AAM od zabijania wiele spektaklu, który pozwala AHCI + NCQ. Jeśli dysk robi zbyt dużo hałasu, pomiń to.

Oto moja konfiguracja dysku SSD (seria 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

Tutaj warto zauważyć niskie wartości dla różnych ustawień wycinków. Najważniejszym ustawieniem dla dysku SSD jest to, slice_idlektóre musi być ustawione na 0-1. Ustawienie go na zero przenosi wszystkie decyzje dotyczące porządkowania do natywnego NCQ, a ustawienie go na 1 pozwala jądru na porządkowanie żądań (ale jeśli NCQ jest aktywne, sprzęt może częściowo zastąpić porządkowanie jądra). Przetestuj obie wartości, aby zobaczyć, czy widzisz różnicę. Intel serii 320, wydaje się, że ustawienie slide_idledo 0daje najlepszą wydajność, ale ustawienie go 1daje najlepszą (najniższy) ogólną latencję.

Aby uzyskać więcej informacji o tych tunach, zobacz http://www.linux-mag.com/id/7572/ .

Teraz, gdy skonfigurowaliśmy jądro do ładowania rzeczy z dysku do pamięci podręcznej z rozsądną wydajnością, nadszedł czas, aby dostosować zachowanie pamięci podręcznej:

Według przeprowadzonych przeze mnie testów nie zawracałbym sobie głowy ustawieniem odczytu blockdev. Domyślne ustawienia jądra są w porządku.

Ustaw system tak, aby wolał zamieniać dane pliku niż kod aplikacji (nie ma to znaczenia, jeśli masz wystarczającą ilość pamięci RAM, aby utrzymać cały system plików i cały kod aplikacji oraz całą pamięć wirtualną przydzieloną przez aplikacje w pamięci RAM). Zmniejsza to opóźnienie przełączania między różnymi aplikacjami w porównaniu z opóźnieniem dostępu do dużych plików z jednej aplikacji:

echo 15 > /proc/sys/vm/swappiness

Jeśli wolisz przechowywać aplikacje prawie zawsze w pamięci RAM, możesz ustawić to na 1. Jeśli ustawisz to na zero, jądro nie będzie w ogóle zamieniać, chyba że jest to absolutnie konieczne dla uniknięcia OOM. Jeśli masz ograniczoną pamięć i pracujesz z dużymi plikami (np. Edycja wideo HD), warto ustawić tę wartość na 100.

Ja obecnie (2017) wolę w ogóle nie zamieniać, jeśli masz wystarczającą ilość pamięci RAM. Brak wymiany zwykle powoduje utratę 200-1000 MB pamięci RAM na długo działającym komputerze stacjonarnym. Jestem gotów poświęcić tyle, aby uniknąć opóźnień w najgorszym przypadku (zamiana kodu aplikacji, gdy pamięć RAM jest pełna). W praktyce oznacza to, że wolę OOM Killera niż zamianę. Jeśli zezwolisz / potrzebujesz zamiany, możesz też chcieć zwiększyć /proc/sys/vm/watermark_scale_factor, aby uniknąć opóźnień. Sugerowałbym wartości od 100 do 500. Możesz rozważyć to ustawienie jako zamianę wykorzystania procesora na mniejsze opóźnienia wymiany. Domyślnie jest to 10, a maksymalna możliwa to 1000. Wyższa wartość powinna (zgodnie z dokumentacją jądra ) skutkować większym zużyciem procesora dla kswapdprocesów i niższym całkowitym opóźnieniem zamiany.

Następnie powiedz jądru, aby wolało utrzymywać hierarchię katalogów w pamięci nad zawartością pliku na wypadek, gdyby część pamięci RAM musiała zostać zwolniona (ponownie, jeśli wszystko mieści się w pamięci RAM, to ustawienie nic nie robi):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Oprawa vfs_cache_pressurezbyt niska wartość ma sens, ponieważ w większości przypadków jądro musi znać strukturę katalogów, zanim będzie mogło użyć zawartości pliku z pamięci podręcznej, a zbyt szybkie opróżnienie pamięci podręcznej katalogu sprawi, że pamięć podręczna plików będzie prawie bezwartościowa. Zastanów się nad przejściem do 1 z tym ustawieniem, jeśli masz dużo małych plików (mój system ma około 150 000 zdjęć o rozdzielczości 10 megapikseli i liczy się jako system „dużo małych plików”). Nigdy nie ustawiaj go na zero lub struktura katalogów jest zawsze przechowywana w pamięci, nawet jeśli w systemie kończy się pamięć. Ustawienie tej dużej wartości jest sensowne tylko wtedy, gdy masz tylko kilka dużych plików, które są ciągle odczytywane ponownie (ponownie, przykładowo, edycja wideo HD bez wystarczającej ilości pamięci RAM). Oficjalna dokumentacja jądra mówi, że „

Wyjątek: jeśli masz naprawdę ogromną liczbę plików i katalogów i rzadko dotykasz / odczytujesz / wyświetlasz listę, wszystkie pliki vfs_cache_pressurepowyżej 100 mogą być mądre. Dotyczy to tylko sytuacji, gdy nie masz wystarczającej ilości pamięci RAM i nie możesz utrzymać całej struktury katalogów w pamięci RAM, a nadal masz wystarczającą ilość pamięci RAM do normalnej pamięci podręcznej plików i procesów (np. Serwer plików dla całej firmy z dużą ilością zawartości archiwalnej). Jeśli uważasz, że musisz zwiększyć vfs_cache_pressurepowyżej 100, biegniesz bez wystarczającej ilości pamięci RAM. Zwiększenie vfs_cache_pressuremoże pomóc, ale jedynym prawdziwym rozwiązaniem jest uzyskanie większej ilości pamięci RAM. Po vfs_cache_pressureustawiony na dużą liczbę poświęca średnią wydajność na posiadanie więcej stabilną wydajność ogólna (czyli można uniknąć naprawdę złe zachowanie najgorszy przypadek, ale mamy do czynienia z gorszą ogólną wydajność).

Na koniec powiedz jądru, aby używało do 99% pamięci RAM jako pamięci podręcznej dla zapisów i poinstruuj jądro, aby używało do 50% pamięci RAM przed spowolnieniem procesu pisania (domyślnie dirty_background_ratiojest to 10). Ostrzeżenie: osobiście nie zrobiłbym tego, ale twierdziłeś, że masz wystarczającą ilość pamięci RAM i jesteś gotów stracić dane.

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

I powiedz, że opóźnienie zapisu 1h jest w porządku, aby nawet zacząć zapisywać rzeczy na dysku (ponownie, nie zrobiłbym tego):

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

Jeśli umieścisz je wszystkie /etc/rc.locali na końcu dołączasz, wszystko będzie w pamięci podręcznej jak najszybciej po starcie (zrób to tylko, jeśli twój system plików naprawdę pasuje do pamięci 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)&

Lub nieco prostsza alternatywa, która może działać lepiej (pamięć tylko /homei /usrwyłącznie to zrobić jeśli /homei /usrnaprawdę zmieścić się w pamięci RAM):

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

Po pierwsze, NIE zalecam dalszego korzystania z NTFS, ponieważ implementacja NTFS w Linuksie będzie w dowolnym momencie powodowała problemy z wydajnością i bezpieczeństwem.

Istnieje kilka rzeczy, które możesz zrobić:

• użyj niektórych nowszych fs, takich jak ext4lubbtrfs
• na przykład spróbuj zmienić harmonogram bfq
• wyłącz zamianę
• użyj jakiegoś automatycznego programu do wstępnego ładowania preload
• użyj czegoś takiego jak systemdwstępne ładowanie podczas uruchamiania
• ... i coś więcej

Może chcesz spróbować :-)

Czytaj dalej:

W systemach 32-bitowych:

blockdev --setra 8388607 /dev/sda

W systemach 64-bitowych:

blockdev --setra 4294967295 /dev/sda

Napisz za cache:

echo 100 > /proc/sys/vm/dirty_ratio

Spowoduje to wykorzystanie do 100% wolnej pamięci jako pamięci podręcznej zapisu.

Lub możesz wyjść na całość i użyć tmpfs. Jest to istotne tylko, jeśli masz wystarczającą ilość pamięci RAM. Włóż to /etc/fstab. Zamień 100G na ilość fizycznej pamięci RAM.

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

Następnie:

mkdir /mnt/tmpfs; mount -a

Następnie użyj / mnt / tmpfs.

Możesz ustawić rozmiar odczytu z wyprzedzeniem blockdev --setra sectors /dev/sda1, gdzie sektory to żądany rozmiar w sektorach 512-bajtowych.

Moje ustawienie zabójcy jest bardzo proste i bardzo skuteczne:

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

Wyjaśnienie z dokumentacji jądra :

vfs_cache_pressure

Kontroluje tendencję jądra do odzyskiwania pamięci używanej do buforowania obiektów katalogów i i-węzłów.

Przy domyślnej wartości vfs_cache_pressure = 100 jądro będzie próbowało odzyskać dentries i i-węzły z „uczciwą” szybkością w odniesieniu do odzyskiwania pagecache i swapcache. Zmniejszenie vfs_cache_pressure powoduje, że jądro woli zachować pamięć podręczną dentysty i i-węzła. Gdy vfs_cache_pressure = 0, jądro nigdy nie odzyska dentrali i i-węzłów z powodu presji pamięci i może to łatwo doprowadzić do stanu braku pamięci. Zwiększenie vfs_cache_pressure powyżej 100 powoduje, że jądro woli odzyskać dentries i i-węzły.

vfs_cache_pressure w 2000 roku powoduje, że większość obliczeń odbywa się w pamięci RAM i bardzo późne zapisywanie na dysku.

Nie związane z buforowaniem zapisu, ale związane z zapisami:

• W przypadku systemu ext4 można całkowicie wyłączyć rejestrowanie

  Zmniejszy to liczbę zapisów na dysku dla poszczególnych aktualizacji, ale może spowodować, że system plików będzie niespójny po nieoczekiwanym zamknięciu, wymagając fsck lub gorzej.

Aby zatrzymać odczytywanie dysku z wyzwalaczy zapisów dysku:

• Montuj z opcją relatime lub noatime

  Podczas odczytywania pliku metadane „ostatniego dostępu” dla tego pliku są zwykle aktualizowane. Ta noatimeopcja wyłączy to zachowanie. Zmniejsza to niepotrzebne zapisy na dysku, ale nie będziesz już mieć tych metadanych. Niektóre dystrybucje (np. Manjaro) przyjęły to ustawienie domyślne na wszystkich partycjach (prawdopodobnie w celu zwiększenia żywotności wcześniejszych dysków SSD).

  relatimerzadziej aktualizuje czas dostępu, zgodnie z heurystykami, które pomagają w obsłudze aplikacji korzystających z tego czasu. Jest to ustawienie domyślne w systemie Red Hat Enterprise Linux.

Inne opcje:

• W powyższych komentarzach Mikko podzielił się możliwością montażu z opcją nobarrier . Ale Ivailo zacytował RedHata, który ostrzega przed tym. Jak bardzo chcesz tych dodatkowych 3%?