Jump to content

# Stress testing (Polski)

2 languages

- English
- 日本語

From ArchWiki

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ę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ń.

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-develAUR.

    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

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

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(+).

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.
Category:

- CPU (Polski)