Improving performance (Polski)
Ten artykuł zawiera informacje na temat podstawowej diagnostyki systemu związanej z wydajnością, a także kroków, które można podjąć w celu zmniejszenia zużycia zasobów lub w inny sposób zoptymalizować system, a celem końcowym jest postrzegana lub udokumentowana poprawa wydajności systemu. Zobacz także Gaming#Improving performance, aby uzyskać dodatkowe porady dotyczące gier i niskich opóźnień.
Podstawy
Znaj swój system
Najlepszym sposobem na dostrojenie systemu jest skupienie się na wąskich gardłach lub podsystemach, które ograniczają ogólną prędkość. Specyfikacje systemu mogą pomóc w ich identyfikacji.
- Jeśli komputer działa wolno, gdy jednocześnie uruchomione są duże aplikacje (takie jak LibreOffice i Firefox), sprawdź, czy ilość pamięci RAM jest wystarczająca. Użyj następującego polecenia i sprawdź kolumnę "free":
$ free -h
- Jeśli czas uruchamiania jest powolny, a aplikacje ładują się długo przy pierwszym uruchomieniu (tylko), to prawdopodobnie winny jest dysk twardy. Szybkość dysku twardego można zmierzyć za pomocą polecenia
hdparm:# hdparm -t /dev/sdX
Note: hdparm wskazuje tylko czystą prędkość odczytu dysku twardego i nie jest odpowiednim punktem odniesienia. Wartość wyższa niż 40 MB/s (w stanie bezczynności) jest jednak akceptowalna dla przeciętnego systemu. - Jeśli obciążenie procesora jest stale wysokie, nawet przy wystarczającej ilości dostępnej pamięci RAM, spróbuj zmniejszyć użycie procesora, wyłączając uruchomione demony i/lub procesy. Można to monitorować na kilka sposobów, na przykład za pomocą htop,
pstreelub innego narzędzia do monitorowania systemu:$ htop
- Jeśli aplikacje korzystające z bezpośredniego renderowania są powolne (tj. te, które wykorzystują GPU, takie jak odtwarzacze wideo, gry, a nawet menedżer okien), to poprawa wydajności GPU powinna pomóc. Pierwszym krokiem jest sprawdzenie, czy renderowanie bezpośrednie jest rzeczywiście włączone. Wskazuje na to polecenie
glxinfo, będące częścią pakietu mesa-utils, które powinno zwrócićdirect rendering: Yes, gdy zostanie użyte w następujące sposób:$ glxinfo | grep "direct rendering"
- Podczas uruchamiania środowiska graficznego, wyłączenie (nieużywanych) wizualnych efektów pulpitu może zmniejszyć wykorzystanie GPU. Użyj lżejszego środowiska lub utwórz własne środowisko, jeśli obecne nie spełnia wymagań sprzętowych i/lub osobistych.
- Używanie zoptymalizowanego kernela poprawia wydajność. Ogólnie rzecz biorąc, linux-zen jest dobrą opcją. Jednakże, domyślne jądro może być ulepszone, jak pokazano w niektórych częściach tego artykułu, aby działało lepiej.
Benchmarking
Efekty optymalizacji są często trudne do oceny. Można je jednak zmierzyć za pomocą narzędzi benchmarkingowych.
Urządzenia pamięci masowej
Kilka ścieżek sprzętowych
Wewnętrzna ścieżka sprzętowa opisuje sposób podłączenia urządzenia pamięci masowej do płyty głównej. Istnieją różne sposoby połączenia przez płytę główną, takie jak NIC, PCIe, Firewire, karta Raid, USB itp. Rozłożenie urządzeń pamięci masowej na wiele punktów połączeń pozwala uniknąć bottlenecków. Powodem jest to, że każda "ścieżka wejściowa" do płyty głównej jest jak "rura" i istnieje określony limit ilości danych, które mogą przez nią przejść w danym momencie. Można tego uniknąć, ponieważ płyty główne mają zwykle kilka "rur".
Konkretnym przykładem może być sytuacja, w której masz dwa porty USB z przodu urządzenia, cztery porty USB z tyłu i cztery dyski: zwykle szybciej będzie podłączyć dwa dyski z przodu i dwa z tyłu niż trzy z tyłu i jeden z przodu. Wynika to z faktu, że w większości przypadków przednie i tylne porty są wewnętrznie podłączone do oddzielnych koncentratorów głównych USB, co oznacza, że można przesyłać więcej danych w tym samym czasie, używając obu zamiast jednego.
Poniższe polecenia pomogą określić różne ścieżki na komputerze.
Drzewo urządzeń USB
$ lsusb -t
Drzewo urządzeń PCI
$ lspci -tv
Partycjonowanie
Upewnij się, że partycje są odpowiednio wyrównane.
Wiele dysków
Jeśli masz do dyspozycji wiele dysków, możesz skonfigurować je jako programowy RAID, aby uzyskać znaczną poprawę prędkości.
Utworzenie swapu na oddzielnym dysku również może być bardzo pomocne, zwłaszcza jeśli maszyna często go używa.
Układ na dyskach twardych
W przypadku korzystania z tradycyjnego wirującego dysku twardego układ partycji może mieć wpływ na wydajność systemu. Sektory na początku dysku (bliżej zewnętrznej części dysku) są szybsze niż te na końcu. Ponadto mniejsza partycja wymaga mniej ruchów głowicy dysku, a tym samym przyspiesza operacje dyskowe. Dlatego zaleca się utworzenie małej partycji (15-20 GB, mniej lub więcej w zależności od potrzeb) tylko dla systemu, jak najbliżej początku dysku. Inne dane (zdjęcia, filmy) powinny być przechowywane na osobnej partycji, co zwykle osiąga się poprzez oddzielenie katalogu domowego (/home) od systemowego (/).
Wybór i dostrajanie systemu plików
Wybór najlepszego systemu plików dla konkretnego systemu jest bardzo ważny, ponieważ każdy z nich ma swoje mocne strony. Artykuł Systemy plików zawiera krótkie podsumowanie najpopularniejszych z nich. Odpowiednie artykuły można również znaleźć w Category:File systems (wersja polska tej kategorii zawiera mało artykułów na ten moment).
Opcje montowania
Różne opcje *atime mogą złagodzić negatywny wpływ strictatime na wydajność.
Inne opcje montowania są specyficzne dla systemu plików, dlatego należy zapoznać się z odpowiednimi artykułami dotyczącymi systemów plików:
- Ext3
- Ext4#Improving performance
- JFS#Optimizations
- XFS#Performance
- Btrfs#Defragmentation, Btrfs#Compression, and btrfs(5)
- ZFS#Tuning
- NTFS#Improving performance
Dostrajanie parametrów jądra
Istnieje kilka kluczowych ustawień wpływających na wydajność urządzeń blokowych, zobacz sysctl#Virtual memory, aby uzyskać więcej informacji.
Dyspozytor wejścia/wyjścia
Podstawowe informacje
Dyspozytor wejścia/wyjścia (I/O) jest komponentem jądra, który decyduje, w jakiej kolejności blokowe operacje wejścia/wyjścia są przesyłane do urządzeń pamięci masowej. Warto przypomnieć tutaj niektóre specyfikacje dwóch głównych typów dysków, ponieważ celem harmonogramu I/O jest optymalizacja sposobu, w jaki są one w stanie obsługiwać żądania odczytu:
- Dysk HDD ma wirujące talerze i głowicę, która fizycznie przemieszcza się do wymaganej lokalizacji. Dlatego też losowe opóźnienie jest dość wysokie i wynosi od 3 do 12 ms (niezależnie od tego, czy jest to wysokiej klasy dysk serwerowy, czy dysk do laptopa i omija bufor zapisu kontrolera dysku), podczas gdy dostęp sekwencyjny zapewnia znacznie wyższą przepustowość. Typowa przepustowość dysku twardego wynosi około 200 operacji wejścia/wyjścia na sekundę (IOPS).
- Dysk SSD nie ma ruchomych części, dostęp losowy jest równie szybki jak sekwencyjny, zwykle poniżej 0,1 ms, i może obsługiwać wiele jednoczesnych żądań. Typowa przepustowość dysku SSD przekracza 10 000 IOPS, co jest więcej niż potrzeba w przypadku typowych obciążeń.
Jeśli istnieje wiele procesów wykonujących żądania we/wy do różnych części pamięci masowej, można wygenerować tysiące operacji wejścia/wyjścia na sekundę, podczas gdy typowy dysk twardy może obsłużyć tylko około 200 operacji wejścia/wyjścia na sekundę. Istnieje kolejka żądań, które muszą czekać na dostęp do pamięci masowej. W tym miejscu dyspozytory I/O odgrywają rolę optymalizacyjną.
Algorytmy planowania
Jednym ze sposobów na poprawę przepustowości jest linearyzacja dostępu: poprzez porządkowanie oczekujących żądań według ich adresu logicznego i grupowanie najbliższych. Historycznie był to pierwszy linuksowy dyspozytor I/O o nazwie elevator - winda.
Jednym z problemów algorytmu windy jest to, że nie jest on optymalny dla procesu wykonującego dostęp sekwencyjny: odczyt bloku danych, przetwarzanie go przez kilka mikrosekund, a następnie odczyt kolejnego bloku i tak dalej. Harmonogram windy nie wie, że proces ma zamiar odczytać inny blok w pobliżu, a zatem przenosi się do innego żądania przez inny proces w innej lokalizacji. W dyspozytorze I/O anticipatory (przewidującym) radzi sobie z tym problemem: zatrzymuje się na kilka milisekund w oczekiwaniu na kolejną operację odczytu w pobliżu, zanim zajmie się kolejnym żądaniem.
Podczas gdy te harmonogramy starają się poprawić całkowitą przepustowość, mogą pozostawić niektóre pechowe żądania czekające przez bardzo długi czas. Dla przykładu, wyobraźmy sobie, że większość procesów zgłasza żądania na początku przestrzeni dyskowej, podczas gdy pechowy proces zgłasza żądanie na drugim końcu przestrzeni dyskowej. To potencjalnie nieskończone opóźnienie procesu nazywane jest "głodem" (ang. starvation). Aby poprawić sprawiedliwość, opracowano algorytm deadline (na pl. - termin końcowy). Posiada on kolejkę uporządkowaną według adresu, podobną do windy, ale jeśli jakieś żądanie znajduje się w tej kolejce zbyt długo, to przenosi się do kolejki "wygasłej" uporządkowanej według czasu wygaśnięcia. Dyspozytor sprawdza najpierw kolejkę wygasłą i przetwarza żądania z niej, a dopiero potem przechodzi do kolejki windy. Należy zauważyć, że ta sprawiedliwość ma negatywny wpływ na ogólną przepustowość.
Kolejka Completely Fair Queuing (CFQ) podchodzi do tego problemu w inny sposób, przydzielając przedział czasowy i liczbę dozwolonych żądań dla kolejki w zależności od priorytetu procesu, który je zgłasza. Obsługuje cgroup, która pozwala zarezerwować pewną ilość I/O dla określonej kolekcji procesów. Jest to szczególnie przydatne w przypadku hostingu współdzielonego i hostingu w chmurze: użytkownicy, którzy zapłacili za pewien IOPS, chcą otrzymać swoją część, gdy tylko zajdzie taka potrzeba. Ponadto bezczynnie czeka na koniec synchronicznego I/O, czekając na inne operacje w pobliżu, przejmując tę funkcję od dyspozytora przewidującego i wprowadzając pewne ulepszenia. Zarówno przewidujący, jak i windowy dyspozytor zostały wycofane z jądra Linux i zastąpione bardziej zaawansowanymi alternatywami przedstawionymi poniżej.
System Budget Fair Queuing (BFQ) bazuje na kodzie CFQ i wprowadza pewne ulepszenia. Nie przyznaje on dysku każdemu procesowi na określony czas, ale przypisuje procesowi "budżet" mierzony liczbą sektorów i wykorzystuje heurystykę. Jest to stosunkowo złożony harmonogram, który może być bardziej dostosowany do dysków obrotowych i powolnych dysków SSD, ponieważ jego wysoki narzut na operację, zwłaszcza jeśli jest powiązany z powolnym procesorem, może spowolnić szybkie urządzenia. Celem BFQ w systemach osobistych jest to, aby w przypadku zadań interaktywnych urządzenie pamięci masowej było praktycznie tak responsywne, jakby było bezczynne. W domyślnej konfiguracji koncentruje się na dostarczaniu najniższych opóźnień, a nie na osiąganiu maksymalnej przepustowości, co czasami może znacznie przyspieszyć uruchamianie aplikacji na dyskach twardych.
Kyber to najnowszy dyspozytor inspirowany technikami aktywnego zarządzania kolejkami wykorzystywanymi do routingu sieciowego. Implementacja opiera się na "tokenach", które służą jako mechanizm ograniczania żądań. Do przydzielenia żądania wymagany jest token kolejkowania, który służy do zapobiegania głodowaniu żądań. Potrzebny jest również token wysyłki, który ogranicza operacje o określonym priorytecie na danym urządzeniu. Na koniec definiowane jest docelowe opóźnienie odczytu, a planista dostraja się, aby osiągnąć ten cel opóźnienia. Implementacja algorytmu jest stosunkowo prosta i jest uważana za skuteczną dla szybkich urządzeń.
Dyspozytory I/O jądra
Podczas gdy niektóre z wczesnych algorytmów zostały już wycofane, oficjalne jądro Linuksa obsługuje szereg dyspozytorów I/O, które można podzielić na dwie kategorie:
- Dyspozytory wielo-kolejkowe są domyślnie dostępne w jądrze. Mechanizm Multi-Queue Block I/O Queuing Mechanism (blk-mq) mapuje zapytania I/O do wielu kolejek, zadania są dystrybuowane między wątkami, a tym samym rdzeniami procesora. W ramach tego mechanizmu dostępne są następujące dyspozytory:
- None, kiedy nie jest stosowany żaden algorytm kolejkowania.
- mq-deadline, dostosowanie planisty deadline (patrz poniżej) do wielowątkowości.
- Kyber
- BFQ
- Dyspozytory jedno-kolejkowe są starszymi rozwiązaniami:
- NOOP to najprostszy planista, który wstawia wszystkie przychodzące żądania I/O do prostej kolejki FIFO i implementuje scalanie żądań. Algorytm ten nie zmienia kolejności żądań w oparciu o numer sektora. W związku z tym może być używany, jeśli kolejność jest obsługiwana na innej warstwie, na przykład na poziomie urządzenia, lub jeśli nie ma to znaczenia, na przykład w przypadku dysków SSD.
- Deadline
- CFQ
- Note: Dyspozytory jedno-kolejkowe zostały usunięte z jądra Linux w wersji 5.0.
Zmiana dyspozytora I/O
Aby wyświetlić dostępne dyspozytory dla urządzenia i aktywny dyspozytor (w nawiasach):
$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none
Aby wyświetlić listę dostępnych planistów dla wszystkich urządzeń:
$ grep "" /sys/block/*/queue/scheduler
/sys/block/pktcdvd0/queue/scheduler:none /sys/block/sda/queue/scheduler:mq-deadline kyber [bfq] none /sys/block/sr0/queue/scheduler:[mq-deadline] kyber bfq none
Aby zmienić aktywny dyspozytor I/O na bfq dla urządzenia sda, użyj:
# echo bfq > /sys/block/sda/queue/scheduler
Proces zmiany planisty I/O, w zależności od tego, czy dysk jest obrotowy, czy nie, może być zautomatyzowany i utrzymywać się po ponownym uruchomieniu systemu. Na przykład poniższe reguły udev ustawiają harmonogram na bfq dla dysków rotacyjnych, bfq dla dysków SSD/eMMC i none dla dysków NVMe:
/etc/udev/rules.d/60-ioschedulers.rules
# HDD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
# SSD
ACTION=="add|change", KERNEL=="sd[a-z]*|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"
# SSD (NVMe)
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
Uruchom ponownie lub wymuś wczytanie nowych reguł udev.
Dostrajanie dyspozytora I/O
Każdy z dyspozytorów I/O jądra ma swoje własne ustawienia, takie jak czas opóźnienia, czas wygaśnięcia lub parametry FIFO. Są one pomocne w dostosowaniu algorytmu do konkretnej kombinacji urządzenia i obciążenia. Zazwyczaj ma to na celu osiągnięcie wyższej przepustowości lub niższego opóźnienia dla danego wykorzystania. Dostrajacze i ich opis można znaleźć w dokumentacji jądra.
Aby wyświetlić dostępne dostrojenia dla urządzenia, w poniższym przykładzie sdb, który używa deadline, użyj:
$ ls /sys/block/sdb/queue/iosched
fifo_batch front_merges read_expire write_expire writes_starved
Aby poprawić przepustowość deadline kosztem opóźnienia, można zwiększyć fifo_batch za pomocą polecenia:
# echo 32 > /sys/block/sdb/queue/iosched/fifo_batch
Konfiguracja zarządzania energią i pamięć podręczna zapisu
W przypadku tradycyjnych dysków obrotowych (HDD) warto całkowicie wyłączyć lub ograniczyć funkcje oszczędzania energii i sprawdzić, czy włączona jest pamięć podręczna zapisu.
Zobacz Hdparm#Power management configuration oraz Hdparm#Write cache.
Następnie można utworzyć regułę udev, aby zastosować je podczas uruchamiania systemu.
Zmniejszenie liczby odczytów/zapisów na dysku
Unikanie niepotrzebnego dostępu do wolnych dysków pamięci masowej jest korzystne dla wydajności, a także zwiększa żywotność urządzeń, chociaż na nowoczesnym sprzęcie różnica w oczekiwanej żywotności jest zwykle znikoma.
Pokaż zapisy na dysku
Pakiet iotop może sortować po zapisach na dysku i pokazywać jak dużo i jak często programy zapisują na dysku. Zobacz iotop(8) po szczegóły.
Przeniesienie plików do tmpfs
Przenieś pliki, takie jak profil przeglądarki, do systemu plików tmpfs, aby poprawić reakcję aplikacji, ponieważ wszystkie pliki są teraz przechowywane w pamięci RAM:
- Patrz Profile-sync-daemon dla synchronizacji profili przeglądarek. Niektóre przeglądarki mogą wymagać szczególnej uwagi, patrz np. Firefox w RAM.
- Patrz Anything-sync-daemon, aby zsynchronizować dowolny określony folder.
- Patrz Makepkg#Improving build times by poprawić czas kompilacji poprzez budowanie pakietów w tmpfs.
Systemy plików
Odnieś się do odpowiedniej strony file system w przypadku instrukcji poprawy wydajności, np. Ext4#Improving performance i XFS#Performance.
Przestrzeń wymiany
Zobacz Swap#Performance.
Interwał zapisu zwrotnego i rozmiar bufora
Zobacz Sysctl#Virtual memory po szczegóły.
Wyłącz zrzuty rdzenia
Zobacz Core dump#Disabling automatic core dumps.
Planowanie pamięci masowej I/O z ionice
Wiele zadań, takich jak tworzenie kopii zapasowych, nie polega na krótkim opóźnieniu we/wy pamięci masowej lub wysokiej przepustowości we/wy pamięci masowej, aby wykonać swoje zadanie, można je sklasyfikować jako zadania w tle. Z drugiej strony, szybkie I/O jest niezbędne dla dobrej responsywności interfejsu użytkownika na pulpicie. Dlatego też korzystne jest zmniejszenie przepustowości pamięci masowej dostępnej dla zadań w tle, podczas gdy inne zadania wymagają operacji we/wy pamięci masowej. Można to osiągnąć poprzez wykorzystanie linuksowego dyspozytora I/O CFQ, który pozwala na ustawienie różnych priorytetów dla procesów.
Priorytet I/O procesu działającego w tle może zostać zredukowany do poziomu "Bezczynności" (Idle) poprzez uruchomienie go za pomocą polecenia
# ionice -c 3 command
Więcej informacji można znaleźć na stronach krótki wstęp do ionice i ionice(1).
CPU
Przetaktowywanie
Przetaktowywanie poprawia wydajność obliczeniową procesora poprzez zwiększenie jego szczytowej częstotliwości taktowania. Możliwość podkręcania zależy od modelu procesora i płyty głównej. Najczęściej odbywa się to poprzez BIOS. Podkręcanie ma również wady i wiąże się z ryzykiem. Nie jest ono tutaj ani zalecane, ani odradzane.
Wiele układów Intela nie zgłasza poprawnie częstotliwości taktowania do acpi_cpufreq i większości innych narzędzi. Spowoduje to nadmiar komunikatów w dmesg, czego można uniknąć poprzez wyładowanie i umieszczenie na czarnej liście modułu jądra acpi_cpufreq.
Aby odczytać ich prędkość zegara użyj i7z z pakietu i7z. Aby sprawdzić poprawność działania podkręconego procesora, zaleca się wykonanie testów obciążeniowych.
Skalowanie częstotliwości
Zobacz CPU frequency scaling.
Dyspozytor CPU
Domyślnym dyspozytorem procesora w głównym jądrze Linux jest EEVDF.
- MuQSS — Multiple Queue Skiplist Scheduler. Dostępne z zestawem poprawek
-ckopracowanym przez Con Kolivas.
- PDS — Oparty na priorytetach i deadlinach planista wielu kolejek Skiplist koncentruje się na responsywności pulpitu.
- https://cchalpha.blogspot.com/ || linux-pdsAUR[broken link: package not found]
- BMQ — Planista BMQ "BitMap Queue" został stworzony w oparciu o istniejące doświadczenie w rozwoju PDS i zainspirowany harmonogramem znalezionym w Zircon firmy Google, jądrze, na którym działa ich inicjatywa Fuchsia OS. Dostępny z zestawem poprawek z CachyOS.
- Project C — Projekt krzyżowy dla refaktoryzacji BMQ do Projektu C, z ponownym utworzeniem PDS w oparciu o bazę kodu Projektu C. Jest to więc połączenie dwóch projektów, z późniejszą aktualizacją PDS jako Project C. Zalecane jako nowsze rozwiązanie.
- TT — Celem dyspozytora typu zadania (TT) jest wykrywanie typów zadań na podstawie ich zachowań i kontrolowanie planowania na podstawie ich typów.
- BORE — Planista BORE koncentruje się na poświęceniu pewnej sprawiedliwości na rzecz mniejszych opóźnień w planowaniu zadań interaktywnych, jest zbudowany na bazie CFS i jest dostosowywany tylko do aktualizacji kodu vruntime, więc ogólne zmiany są dość niewielkie w porównaniu do innych nieoficjalnych planistów CPU.
Jądro działające w czasie rzeczywistym
Niektóre aplikacje, takie jak uruchamianie karty tunera TV w pełnej rozdzielczości HD (1080p), mogą korzystać z jądra działającego w czasie rzeczywistym.
Dostosowanie priorytetów procesów
Zobacz także nice(1) i renice(1).
Ananicy
Ananicy jest demonem, dostępnym jako ananicy-gitAUR lub ananicy-cppAUR, służącym do automatycznego dostosowywania poziomów nice plików wykonywalnych. Poziom nice reprezentuje priorytet pliku wykonywalnego podczas przydzielania zasobów procesora.
cgroups
Zobacz cgroups.
Cpulimit
Cpulimit to program do ograniczania procentowego wykorzystania procesora przez określony proces. Po zainstalowaniu cpulimitAUR, możesz ograniczyć użycie procesora przez PID procesu używając skali od 0 do 100 razy liczba rdzeni CPU, które posiada komputer. Na przykład, przy ośmiu rdzeniach CPU zakres procentowy będzie wynosił od 0 do 800. Użycie:
$ cpulimit -l 50 -p 5081
irqbalance
Celem irqbalance jest dystrybucja przerwań sprzętowych pomiędzy procesorami w systemie wieloprocesorowym w celu zwiększenia wydajności. Może on być kontrolowany przez dostarczony irqbalance.service.
Wyłączenie zabezpieczeń przed exploitami CPU
Wyłączenie zabezpieczeń przed exploitami CPU może poprawić wydajność. Użyj poniższego parametru jądra, aby wyłączyć je wszystkie:
mitigations=off
Wyjaśnienia wszystkich przełączników są podane na stronie kernel.org. Do sprawdzania podatności można użyć spectre-meltdown-checkerAUR lub lscpu(1) (z util-linux).
Grafika
Konfiguracja Xorg
Wydajność grafiki może zależeć od ustawień w xorg.conf(5); zobacz artykuły NVIDIA, AMDGPU i Intel. Nieprawidłowe ustawienia mogą uniemożliwić działanie Xorg, dlatego zaleca się ostrożność.
Konfiguracja Mesa
Wydajność sterowników Mesa można skonfigurować za pośrednictwem strony drirc. Dostępne są narzędzia konfiguracyjne GUI:
- adriconf (Advanced DRI Configurator) — Narzędzie GUI do konfigurowania sterowników Mesa poprzez ustawianie opcji i zapisywanie ich w standardowym pliku drirc.
- DRIconf — Aplet konfiguracyjny dla infrastruktury renderowania bezpośredniego. Umożliwia dostosowanie wydajności i ustawień jakości wizualnej sterowników OpenGL na poziomie sterownika, ekranu i/lub aplikacji.
Sprzętowa akceleracja wideo
Srzętowa akceleracja wideo umożliwia karcie graficznej dekodowanie/kodowanie wideo.
Przetaktowywanie
Podobnie jak w przypadku procesorów, podkręcanie może bezpośrednio poprawić wydajność, ale jest ogólnie niezalecane. Istnieje kilka pakietów, takich jak rovclockAUR (karty ATI), rocm-smi-lib (najnowsze karty AMD), nvvclockAUR[broken link: package not found] (najnowsze karty AMD). (najnowsze karty AMD), nvclockAUR (stare NVIDIA - do Geforce 9) i nvidia-utils dla najnowszych kart NVIDIA.
Zobacz AMDGPU#Overclocking bądź NVIDIA/Tips and tricks#Enabling overclocking.
Włączenie możliwości zmiany rozmiaru PCI BAR
- W niektórych systemach włączenie funkcji PCI resizable BAR może spowodować znaczny spadek wydajności. Aby upewnić się, że zwiększa to wydajność, należy przeprowadzić testy porównawcze systemu.
- Compatibility Support Module (CSM) musi być wyłączone, aby to zadziałało.
Specyfikacja PCI pozwala na użycie większych rejestrów adresów bazowych w celu udostępnienia pamięci urządzeń PCI kontrolerowi PCI. Może to skutkować wzrostem wydajności kart graficznych. Dostęp do pełnej pamięci wideo poprawia wydajność, ale także umożliwia optymalizację sterownika graficznego. Połączenie BAR o zmiennym rozmiarze, dekodowania powyżej 4G i tych optymalizacji sterownika jest tym, co AMD nazywa AMD Smart Access Memory, dostępnym początkowo na płytach głównych z chipsetem AMD Serii 500, później rozszerzonym na AMD Serii 400 i Intel Serii 300, a następnie poprzez aktualizacje UEFI. To ustawienie może nie być dostępne na wszystkich płytach głównych i wiadomo, że czasami powoduje problemy z uruchamianiem na niektórych płytach.
Jeśli BAR ma rozmiar 256M, funkcja ta nie jest włączona lub nie jest obsługiwana:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=256M
Aby ją włączyć, włącz ustawienie o nazwie "Above 4G Decode" lub ">4GB MMIO" w ustawieniach płyty głównej. Sprawdź, czy BAR jest teraz większy:
# dmesg | grep BAR=
[drm] Detected VRAM RAM=8176M, BAR=8192M
Obsługa pamięci RAM, wymiany i OOM
Częstotliwość i taktowanie zegara
Pamięć RAM może działać z różnymi częstotliwościami taktowania i timingami, które można skonfigurować w BIOS-ie. Wydajność pamięci zależy od obu tych wartości. Wybranie najwyższego ustawienia prezentowanego przez BIOS zazwyczaj poprawia wydajność w stosunku do ustawienia domyślnego. Należy pamiętać, że zwiększanie częstotliwości do wartości nieobsługiwanych przez producenta płyty głównej i pamięci RAM jest podkręcaniem, a podobne ryzyko i wady mają zastosowanie, patrz #Przetaktowywanie.
Root na nakładce RAM
Jeśli korzystasz z wolno zapisującego nośnika (USB, wirujące dyski twarde), a wymagania dotyczące pamięci masowej są niskie, root może być uruchomiony na nakładce RAM na root tylko do odczytu (na dysku). Może to znacznie poprawić wydajność kosztem ograniczonej przestrzeni do zapisu dla roota. Zobacz liverootAUR.
zram lub zswap
Podobne korzyści (przy podobnych kosztach) można osiągnąć za pomocą zswap lub zram. Oba są generalnie podobne w intencji, choć nie w działaniu: zswap działa jako skompresowana pamięć podręczna RAM i nie wymaga (ani nie pozwala) na rozbudowaną konfigurację przestrzeni użytkownika, podczas gdy zram jest modułem jądra, który może być użyty do utworzenia skompresowanego urządzenia blokowego w pamięci RAM. zswap działa w połączeniu z urządzeniem wymiany, podczas gdy zram nie wymaga zapasowego urządzenia wymiany.
Korzystanie z pamięci RAM karty graficznej
W mało prawdopodobnym przypadku, gdy masz bardzo mało pamięci RAM i nadmiar pamięci RAM wideo, możesz użyć tej ostatniej jako wymiany. Zobacz Pamięć wymiany na RAMie GPU.
Poprawa responsywności systemu w warunkach małej ilości pamięci
W tradycyjnym systemie GNU/Linux, zwłaszcza w przypadku graficznych stacji roboczych, gdy przydzielona pamięć jest nadmiernie zajęta, ogólna responsywność systemu może spaść do stanu prawie bezużytecznego, zanim albo uruchomi się zabójca OOM w jądrze, albo wystarczająca ilość pamięci zostanie zwolniona (co jest mało prawdopodobne, aby nastąpiło szybko, gdy system nie reaguje, ponieważ prawie nie można zamknąć żadnych aplikacji wymagających dużej ilości pamięci, które mogą nadal przydzielać więcej pamięci). Zachowanie zależy również od konkretnych konfiguracji i warunków, powrót do normalnego stanu responsywności może zająć od kilku sekund do ponad pół godziny, co może być uciążliwe w poważnym scenariuszu, takim jak podczas prezentacji konferencyjnej.
Podczas gdy zachowanie jądra, a także rzeczy przestrzeni użytkownika w warunkach niskiej pamięci może ulec poprawie w przyszłości, jak omówiono na listach mailingowych kernela i Fedory, użytkownicy mogą korzystać z bardziej wykonalnych i skutecznych opcji niż twardy reset systemu lub dostrajanie parametrów vm.overcommit_*. parametrów sysctl:
- Ręczne uruchomienie zabójcy OOM jądra za pomocą Magiczny klawisz SysRq, a mianowicie
Alt+SysRq+f. - Użyj demona OOM w przestrzeni użytkownika, aby poradzić sobie z nimi automatycznie (lub interaktywnie).
Czasami użytkownik może preferować demona OOM zamiast SysRq, ponieważ z kernelowym OOM-killerem nie można ustawić priorytetu procesu do (lub nie) zakończenia.
Poniżej zostało wymienione kilka demnów OOM:
- systemd-oomd — Dostarczany przez systemd jako
systemd-oomd.service, który wykorzystuje cgroups-v2 i informacje o PSI do monitorowania i podejmowania działań wobec procesów przed wystąpieniem OOM w przestrzeni jądra.
- earlyoom — Prosta implementacja OOM-killera w przestrzeni użytkownika napisana w C.
- oomd — Implementacja OOM-killera oparta na PSI, wymaga jądra Linux w wersji 4.20+. Konfiguracja jest w JSON i jest dość złożona. Potwierdzono, że działa w środowisku produkcyjnym Facebooka.
- nohang — Zaawansowana obsługa OOM napisana w Pythonie, z opcjonalną obsługą PSI, bardziej konfigurowalna niż earlyoom.
- low-memory-monitor — Wysiłek deweloperów GNOME, który ma na celu zapewnienie lepszej komunikacji z aplikacjami przestrzeni użytkownika w celu wskazania niskiego stanu pamięci, poza tym można go skonfigurować tak, aby uruchamiał zabójcę OOM jądra. Oparty na PSI, wymaga Linuksa 5.2+.
- uresourced — Mały demon, który włącza ochronę zasobów opartą na cgroup dla aktywnej sesji użytkownika graficznego.
Sieć
- Sieć jądra: patrz Sysctl#Improving performance
- Karty sieciowe: patrz Network configuration#Set device MTU and queue length
- DNS: rozważyć użycie buforującego serwera DNS, zob. Domain name resolution#DNS servers
- Samba: patrz Samba#Improve throughput
Watchdogi
Według Wikipedia:Watchdog timer:
- Timer watchdog [...] to elektroniczny zegar, który służy do wykrywania i przywracania sprawności komputera. Podczas normalnej pracy, komputer regularnie resetuje watchdog timer [...]. Jeśli [...], komputer nie zresetuje watchdoga, timer upłynie i wygeneruje sygnał przekroczenia limitu czasu [...] używany do zainicjowania [...] działań naprawczych [...] zazwyczaj obejmujących umieszczenie systemu komputerowego w bezpiecznym stanie i przywrócenie normalnego działania systemu.
Wielu użytkowników potrzebuje tej funkcji ze względu na krytyczną rolę ich systemu (np. serwery) lub z powodu braku resetowania zasilania (np. urządzenia wbudowane). Tak więc funkcja ta jest wymagana do dobrego działania w niektórych sytuacjach. Z drugiej strony, zwykli użytkownicy (np. komputerów stacjonarnych i laptopów) nie potrzebują tej funkcji i mogą ją wyłączyć.
Aby wyłączyć watchdog timery (zarówno programowe jak i sprzętowe), należy dodać nowatchdog do parametrów startowych.
Parametr startowy nowatchdog może nie działać dla sprzętowego watchdoga Intel TCO [1]. W takiej sytuacji moduł jądra dla TCO może zostać wyłączony przy użyciu parametru jądra modprobe.blacklist=iTCO_wdt.
Jeśli używasz procesorów AMD Ryzen, sprawdź również sp5100-tco w swoim dzienniku. Jest to sprzętowy watchdog wewnątrz serii chipsetów AMD 700. Aby go wyłączyć:
/etc/modprobe.d/disable-sp5100-watchdog.conf
blacklist sp5100_tco
Albo użyj parametru jądra modprobe.blacklist=sp5100_tco.
Sprawdź nową konfigurację za pomocą cat /proc/sys/kernel/watchdog lub wdctl.
Każda z tych czynności przyspieszy uruchamianie i zamykanie systemu, ponieważ załadowany zostanie jeden moduł mniej. Dodatkowo wyłączenie watchdog timerów zwiększa wydajność i obniża pobór mocy.
Zobacz [2], [3], [4], i [5] po więcej informacji.