Stress testing (Polski)

Powiązane artykuły
Benchmarking
Sysstat
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.
Warning
Przed rozpoczęciem
wysoce
zalecane jest, aby użytkownicy mieli sposób na monitorowanie temperatur sprzętu. Zobacz
Lm_sensors
.
Intensywność
Testowany sprzęt
1
Zadanie
Opis
Lekka
2
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+
.
Realistyczna
3
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-heaven
AUR
to benchmark karty graficznej, który się zapętla. Jest to przyzwoity test obciążeniowy dla kart graficznych. Zobacz
Benchmarking#Graphics
.
Syntetyczna
4
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-bin
AUR
jest doskonałym sposobem na obciążenie procesora i pamięci. Zobacz
#MPrime
.
CPU
Obliczenia algebraiczne
linpack
AUR
- 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
systester
AUR
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
stressapptest
AUR
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ń.
Tip
Aby zapewnić stabilność systemu, zaleca się przeprowadzanie takich testów przez długi czas, od kilku godzin do kilku dni, w różnych warunkach temperaturowych. Jeśli temperatura w pomieszczeniu może na przykład znacznie różnić się między okresem zimowym i letnim, należy wziąć to pod uwagę.
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.
Note
Wymaganych będzia kilka pakietów, w tym git oraz curl, podczas gdy większość innych powinna zostać dostarczona przez
meta-pakiet
base-devel
. Aby być bezpiecznym, użytkownicy mogą zawsze zainstalować meta-pakiet
openwrt-devel
AUR
.
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ę
mprime
AUR
.
Aby uruchomić mprime, wystarczy uruchomić powłokę i wpisać "mprime":
$ mprime
Note
W przypadku korzystania ze
skalowania częstotliwości procesora
, czasami użytkownicy muszą ręcznie ustawić procesor, aby działał z najwyższym mnożnikiem, ponieważ mprime używa ładnej wartości, która nie zawsze wyzwala zwiększenie mnożnika.
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!
...
Note
Użytkownicy podejrzewający uszkodzenie pamięci lub kontrolerów pamięci powinni najpierw wypróbować test mieszania, ponieważ test FFT małych rozmiarów zużywa bardzo mało pamięci.
Linpack
linpack
AUR
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
Systester
AUR
(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-efi
AUR
.
Po instalacji, użytkownicy mogą
zaktualizować GRUBa
: automatycznie wykryje on  pakiet i pozwoli użytkownikom na bezpośrednie uruchomienie memtest86(+).
Tip
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
Note
Numeracja może się różnić w zależności od modelu procesora i dostawcy, ale generalnie zarówno rdzenie, jak i procesory zaczynają się od 0, a nie od 1.