Stress testing (Polski)
Testy obciążeniowe to proces uruchamiania różnych obciążeń roboczych na komputerze w celu oceny jego stabilności. Jest to często wykorzystywane do niezawodnego sprawdzania stabilności podkręconego sprzętu i monitorowania zachowania termicznego systemu (np. maksymalnych temperatur, ograniczania wydajności, poziomów hałasu). Dostępnych jest kilka programów do testowania różnych części systemu, takich jak CPU, GPU, pamięć RAM i pamięć masowa, przy użyciu różnych rodzajów obciążeń.
Czynności obciążeniowe
Poniższa tabela zawiera poszczególne oprogramowania mogące służyć do testów obciążeniowych. Ważne jest to, żeby wykonywać testy używając obciążeń różnego rodzaju. Ma to służyć zweryfikowaniu stabilności systemu pod różnymi kątami.
| Intensywność | Testowany sprzęt1 | Zadanie | Opis |
|---|---|---|---|
| Lekka2 | |||
| CPU, pamięć masowa | Aktualizowanie łatek | Niestandardowy skrypt aktualizujący setki łatek kernela w projekcie OpenWRT. Zobacz #Aktualizowanie łatek w OpenWRT. | |
| CPU, pamięć masowa | Zapisywanie obrazu dysku | Zobacz #Zapisywanie obrazu dysku. | |
| RAM | Testy obciążeniowe pamięci | Zobacz #MemTest86+. | |
| Realistyczna3 | |||
| CPU, RAM, pamięć masowa | Kompilacja | Równoległa kompilacja to dobry sposób na testowanie obciążeniowe procesora. Zobacz #GCC. | |
| CPU, RAM | Enkodowanie wideo | ffmpeg, x264, handbrake-cli, itd. mogą zostać użyte do enkodowania wideo. Zobacz #Enkodowanie wideo. | |
| CPU, RAM | Kopanie kryptowalut |
xmrig - polecenie xmrig --stress będzie używało poszczególnych algorytmów kopania (bazując na modelu procesora), aby wygenerować największe, możliwe obciążenie. Dobry sposób na testowanie stabilności i temperatur.
|
|
| GPU | Renderowanie 3D | unigine-heavenAUR to benchmark karty graficznej, który się zapętla. Jest to przyzwoity test obciążeniowy dla kart graficznych. Zobacz Benchmarking#Graphics. | |
| Syntetyczna4 | CPU, RAM, pamięć masowa | Testy syntetyczne | stress to prosty generator obciążenia procesora, pamięci, I/O oraz dysku zaimplementowany w C. Zobacz #stress. |
| CPU, RAM | Obliczanie liczb pierwszych | mprime-binAUR jest doskonałym sposobem na obciążenie procesora i pamięci. Zobacz #MPrime. | |
| CPU | Obliczenia algebraiczne | linpackAUR - Linpack wykorzystuje biblioteki BLAS (Basic Linear Algebra Subprograms) do wykonywania podstawowych operacji na wektorach i macierzach i jest doskonałym sposobem na sprawdzenie stabilności procesorów. Zobacz #Linpack. | |
| CPU | Obliczanie miejsc dziesiętnych Pi | systesterAUR to wielowątkowe oprogramowanie zdolne do wyznaczania wartości liczby pi z dokładnością do 128 000 000 miejsc po przecinku. Posiada wbudowaną kontrolę stabilności systemu. Zobacz #Systester. | |
| RAM | Testy obciążeniowe pamięci | stressapptestAUR to test interfejsu pamięci. |
- 1 Główny cel testu, praktycznie wszystkie testy będą w jakiś sposób wykorzystywały procesor i RAM.
- 2 Testy o niskiej instensywności nie męczą komponentów zbyt mocno (jeżeli chodzi o limity prądu/termiczne). Testy te są przydatne, aby sprawdzić jak sprzęt zachowuje się w niższych poziomach mocy (tzw P states), zwłaszcza dla systemów, w których napięcie zostało obniżone (a nie podkręcone).
- 3 Testy realistyczne bazowane są na realistycznych scenariuszach działania/obciążeniach.
- 4 Testy syntetyczne są jawnie projektowane, aby torturować sprzęt jak najbardziej się da i mogą nie być reprezentatywne dla rzeczywistych obciążeń.
Aktualizowanie łatek w OpenWRT
Dobrym testem stabilności przy niskim obciążeniu jest aktualizacja zestawów poprawek w projekcie OpenWRT. Wykonaj następujące kroki.
git clone --depth 1 git@github.com:openwrt/openwrt.git cd openwrt mkdir -p staging_dir/host/bin cp /usr/bin/sed ./staging_dir/host/bin curl -Os https://raw.githubusercontent.com/KanjiMonster/maintainer-tools/master/update_kernel.sh chmod +x update_kernel.sh ./update_kernel.sh -v -u 5.15
stress
stress wykonuje pętlę, która oblicza pierwiastek kwadratowy z losowej liczby w celu obciążenia procesora. Może uruchomić jednocześnie kilka instancji, na przykład w celu obciążenia wszystkich rdzeni procesora. Może również generować obciążenie pamięci, I/O lub dysku w zależności od przekazanych parametrów. Strona często zadawanych pytań dostarcza przykłady i wyjaśnienia.
Aby uruchomić 4 instancje liczące pierwiastek kwadratowy, użyj polecenia:
$ stress --cpu 4
MPrime
MPrime (znany również jako Prime95 w implementacji Windows i MacOS) jest powszechnie uznawany za defacto miarę stabilności systemu. MPrime w trybie testu tortur wykona serię bardzo intensywnych obliczeń procesora i porówna uzyskane wartości ze znanymi dobrymi wartościami.
Implementacja na Linux nazywa się mprimeAUR.
Aby uruchomić mprime, wystarczy uruchomić powłokę i wpisać "mprime":
$ mprime
Kiedy program załaduje się, wystarczy odpowiedzieć 'N' na pierwsze pytanie, aby rozpocząć testowanie:
Main Menu 1. Test/Primenet 2. Test/Worker threads 3. Test/Status 4. Test/Continue 5. Test/Exit 6. Advanced/Test 7. Advanced/Time 8. Advanced/P-1 9. Advanced/ECM 10. Advanced/Manual Communication 11. Advanced/Unreserve Exponent 12. Advanced/Quit Gimps 13. Options/CPU 14. Options/Preferences 15. Options/Torture Test 16. Options/Benchmark 17. Help/About 18. Help/About PrimeNet Server
Istnieje kilka opcji dotyczących testów torturowych (15. opcja menu).
- FFT małych rozmiarów (opcja 1), aby obciążyć procesor
- FFT in-place, dużych rozmiarów (opcja 2), aby obciążyć zarówno procesor jak i kontroler pamięci
- Mieszanka (opcja 3) to opcja domyślna i oznacza tryb hybrydowy, który obciąża procesor i RAM.
Błędy będą zgłaszane, jeśli wystąpią, zarówno na wyjście standardowe (stdout), jak i do ~/results.txt w celu późniejszego sprawdzenia. Wiele osób nie uważa systemu za "stabilny", jeśli nie może on wykonywać dużych FFT przez okres 24 godzin.
Przykład pliku ~/results.txt; zauważ, że dwie sesje z 26. czerwca wskazują na usterkę sprzętu. W tym przypadku jest to spowodowane zbyt małym napięciem procesora (vcore).
[Sun Jun 26 20:10:35 2011] FATAL ERROR: Rounding was 0.5, expected less than 0.4 Hardware failure detected, consult stress.txt file. FATAL ERROR: Rounding was 0.5, expected less than 0.4 Hardware failure detected, consult stress.txt file. [Sat Aug 20 10:50:45 2011] Self-test 480K passed! Self-test 480K passed! [Sat Aug 20 11:06:02 2011] Self-test 128K passed! Self-test 128K passed! [Sat Aug 20 11:22:10 2011] Self-test 560K passed! Self-test 560K passed! ...
Linpack
linpackAUR wykorzystuje biblioteki BLAS (Basic Linear Algebra Subprograms) do wykonywania podstawowych operacji na wektorach i macierzach. Jest to doskonały sposób na przetestowanie procesorów pod kątem stabilności (obsługiwane są tylko procesory Intel). Po instalacji użytkownicy powinni skopiować /usr/share/linpack/linpack.conf do ~/.config/linpack.conf i dostosować go do ilości pamięci w systemie.
Systester
SystesterAUR (aka SuperPi dla Windows) jest dostępny zarówno w wersji CLI, jak i GUI. Testuje stabilność systemu, obliczając do 128 milionów cyfr po przecinku liczby Pi i obejmuje sprawdzanie błędów. Można wybrać jeden z dwóch różnych algorytmów obliczeniowych: Quadratic Convergence of Borwein i Gauss-Legendre. Ten ostatni jest tą samą metodą, której używa popularny SuperPi dla Windows.
Poniżej przykład CLI wykorzystujący 8 wątków:
$ systester-cli -gausslg 64M -threads 8
MemTest86+
Możesz użyć MemTest86 (zamknięto-źródłowy) lub Memtest86+ (na licencji GPL), aby przetestować RAM.
- Wersja GPL jest dostępna w obrazie instlacyjnym Arch Linuxa. Jest dostępna (do zainstalowania) dla:
- systemów EFI - w pakiecie memtest86+-efi,
- systemów BIOS - w pakiecie memtest86+
- Wersje zamknięto-źródłowe nie wspierają systemów BIOS. Dostępne są pod pakietem memtest86-efiAUR.
- Po instalacji, użytkownicy mogą zaktualizować GRUBa: automatycznie wykryje on pakiet i pozwoli użytkownikom na bezpośrednie uruchomienie memtest86(+).
- Wiarygodnym źródłem historii wersji jest sekcja History of MemTest86 na stronie memtest86.com, w szczególności sekcja "2002 - 2004" i kolejne. Należy zauważyć, że własnościowy MemTest86 od wersji 5 do 7 twierdzi, że obsługuje zarówno BIOS, jak i UEFI, ale po prostu łączy stare i nowe wersje.
- Zwykle wystarczające jest umożliwienie testom wykonania co najmniej 10 cykli bez błędów.
Zapisywanie obrazu dysku
Dobrym testem stabilności przy niskim obciążeniu jest użycie dd do sformatowania obrazu. Może to być dysk fizyczny lub obraz zamontowany w pętli (loop). Poniższy skrypt wykorzystuje zamontowany obraz i cyklicznie przechodzi przez każdy rdzeń jeden po drugim. Zauważ, że powinieneś dostosować zmienne w górnej części skryptu, aby pasowały do twojego systemu. Domyślnie skrypt uruchamia polecenie tylko raz na rdzeń. Można go łatwo dostosować, aby działał na znanych słabych rdzeniach, zamiast skanować wszystkie rdzenie od 0 do n, zmieniając pętlę for. Uruchom skrypt jako root.
format-test.sh
#!/bin/bash
# zdefiuniuj scieżkę zapisu obrazu, zalecane jest, aby była to lokalizacja zamontowana jako tmpfs, aby uniknąć odczytów/zapisów
img=/scratch/image.img
# zdefiniuj punkt montowania
mnt=/mnt/loop
# wielkość argumentu time do przekazania do truncate, upewnij się, aby wybrać liczbę mniejszą od ilości wolnej pamięci systemu
# zobacz truncate --help po więcej opcji
size=40G
# domyślnie 1, powinno być mniejsze niż liczba wątków, opcjonalnie można zdefiniować ręcznie
max=$(($(nproc) - 1))
if [[ ! -f $img ]]; then
truncate -s $size $img
mkfs.ext4 $img
[[ -d $mnt ]] || mkdir -p $mnt
if ! mountpoint -q $mnt; then
mount -o loop $img $mnt || exit 1
fi
fi
for i in $(eval echo "{0..$max}"); do
echo "używam rdzenia $i z $max"
taskset -c "$i" time dd if=/dev/zero of=$mnt/zerofill status=progress
done
umount $mnt
rm $img
GCC
Równoległa kompilacja przy użyciu GCC (lub innych kompilatorów) spowoduje duże obciążenie procesora i pamięci. Aby uniknąć zadławienia I/O, kompiluj na dysku SSD lub w tmpfs.
Dobrym przykładem może być kompilacja jądra: zobacz Kernel/Arch build system po szczegółowe instrukcje, uruchom makepkg -sf MAKEFLAGS="-j$(nproc)" w Kernel/Arch build system#Compiling.
Enkodowanie wideo
Większość koderów wideo jest wysoce równoległa i zaprojektowana tak, aby wykorzystywać większość możliwości procesora. Poniższy przykład koduje szum przy użyciu x265 i odrzuca wynik. Spowoduje to znaczne obciążenie procesora.
ffmpeg -y -f rawvideo -video_size 1920x1080 -pixel_format yuv420p -framerate 60 -i /dev/urandom -c:v libx265 -preset placebo -f matroska /dev/null
Wykrywanie błędów
Niektóre aplikacje stresujące, takie jak #MPrime lub #Linpack, mają wbudowane kontrole spójności, aby wykryć błędy spowodowane niepasującymi wynikami. Bardziej ogólną i prostą metodę pomiaru niestabilności sprzętu można znaleźć w samym jądrze. Aby z niej skorzystać, wystarczy przefiltrować dziennik awarii w następujący sposób:
# journalctl -k --grep=mce
Chipy wielordzeniowe mogą również podawać informacje o tym, który rdzeń fizyczny/logiczny spowodował błąd. Może to być ważne, jeśli użytkownicy optymalizują ustawienia dla poszczególnych rdzeni.
Jądro może wyrzucać te błędy podczas działania obciążającej aplikacji, zanim zakończy obliczenia i zgłosi błąd, zapewniając w ten sposób bardzo czułą metodę oceny stabilności. Rozważmy poniższy przykład z procesora Ryzen 5900X:
mce: [Hardware Error]: Machine check events logged mce: [Hardware Error]: CPU 21: Machine Check: 0 Bank 5: baa0000000030150 mce: [Hardware Error]: TSC 0 MISC d012000100000000 SYND 4d000002 IPID 500b000000000 mce: [Hardware Error]: PROCESSOR 2:a20f10 TIME 1625265814 SOCKET 0 APIC 4 microcode a201016
Ten układ ma 12 fizycznych rdzeni. W tym przypadku CPU 21 można przypisać do fizycznego rdzenia 10. Użyj lstopo z hwloc aby wyświetlić topologię sprzętu.
Core 0 = CPU 0 + CPU 1 Core 1 = CPU 2 + CPU 3 Core 2 = CPU 4 + CPU 5 Core 3 = CPU 6 + CPU 7 Core 4 = CPU 8 + CPU 9 Core 5 = CPU 10 + CPU 11 Core 6 = CPU 12 + CPU 13 Core 7 = CPU 14 + CPU 15 Core 8 = CPU 16 + CPU 17 Core 9 = CPU 18 + CPU 19 Core 10 = CPU 20 + CPU 21 Core 11 = CPU 22 + CPU 23