Strojenie szorowania ZFS, 141 KB / s działa przez 15 dni

14

Dość podstawowy system z uruchomionym lustrem + paskiem na dyskach Sas o prędkości 7.2k rpm, niezbyt obciążony. Bez deduplikacji, kompresja we wszystkich zestawach danych. Scrub działa od 15 dni z prędkością martwego ślimaka. Czy istnieje jakaś optymalizacja, którą należy wykonać, czy może to z powodu wadliwego sprzętu?

  • Dell R510 z obudową MD1200.
  • 2x Xeon E5620
  • 48 GB
  • NexentaStor 3.1.3, wydanie wspólnotowe

Trochę informacji:

scan: scrub in progress since Mon Apr  1 19:00:05 2013
171G scanned out of 747G at 141K/s, 1187h40m to go
0 repaired, 22.84% done
config:

    NAME                       STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        c7t5000C500414FB2CFd0  ONLINE       0     0     0
        c7t5000C500414FCA57d0  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        c7t5000C500415C3B1Bd0  ONLINE       0     0     0
        c7t5000C500415C5E4Fd0  ONLINE       0     0     0
      mirror-2                 ONLINE       0     0     0
        c7t5000C500415DC797d0  ONLINE       0     0     0
        c7t5000C500415DC933d0  ONLINE       0     0     0
    logs
      c7t5000A7203006D81Ed0    ONLINE       0     0     0
    cache
      c7t5000A72030068545d0    ONLINE       0     0     0


# iostat -en     
---- errors --- 
s/w h/w trn tot device
0 8887   0 8887 c2t0d0
0   0   0   0 c0t395301D6B0C8069Ad0
0   0   0   0 c7t5000C500415DC933d0
0   0   0   0 c7t5000A72030068545d0
0   0   0   0 c7t5000C500415DC797d0
0   0   0   0 c7t5000C500414FCA57d0
0   0   0   0 c7t5000C500415C3B1Bd0
0   0   0   0 c7t5000C500415C5E4Fd0
0   0   0   0 c7t5000C500414FB2CFd0
0   0   0   0 c7t5000A7203006D81Ed0

Spa_last_io jest zmieniane za każdym razem, gdy to uruchamiam

# echo "::walk spa | ::print spa_t spa_name spa_last_io spa_scrub_inflight" | mdb -k
spa_name = [ "syspool" ]
spa_last_io = 0x25661402
spa_scrub_inflight = 0
spa_name = [ "tank" ]
spa_last_io = 0x25661f84
spa_scrub_inflight = 0x21

Co 5 sekund zapisywane jest około 20-25 MB / s. Pomiędzy tymi zapisami zasadniczo nie ma odczytów ani zapisów.

                          capacity     operations    bandwidth      latency
    pool                       alloc   free   read  write   read  write   read  write
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    syspool                     427G   501G      0      0      0      0   0.00   0.00
      c0t395301D6B0C8069Ad0s0   427G   501G      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    tank                        903G  1.84T    810  5.21K  1.50M  20.8M   9.42   4.71
      mirror                    301G   627G     22  1.00K  53.0K  3.96M   8.96   3.93
        c7t5000C500414FB2CFd0      -      -     20    244  50.1K  3.97M   6.70   1.14
        c7t5000C500414FCA57d0      -      -     19    242  48.2K  3.97M   7.60   1.12
      mirror                    301G   627G     25   1016  46.8K  4.10M  16.11   5.28
        c7t5000C500415C3B1Bd0      -      -     21    257  41.6K  4.11M   4.63   1.24
        c7t5000C500415C5E4Fd0      -      -     21    255  43.0K  4.11M  16.54   1.15
      mirror                    301G   627G     62    754   119K  3.03M  19.72   3.78
        c7t5000C500415DC797d0      -      -     57    219   114K  3.03M   9.99   1.15
        c7t5000C500415DC933d0      -      -     56    220   119K  3.03M  13.20   1.22
      c7t5000A7203006D81Ed0     260K  46.5G      0      0      0      0   0.00   0.00
    cache                          -      -      -      -      -      -
      c7t5000A72030068545d0    93.1G     8M      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Czy iostaty mówią mi, że spędzam więcej czasu czekając na dysk, niż powinienem? W szczególności kolumna% b

# iostat -xe
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
sd3       5.1   43.9   20.6  643.8  0.0  0.1    2.9   0   5   0   0   0   0 
sd4       9.4    1.8  141.1  169.6  0.0  0.0    0.5   0   0   0   0   0   0 
sd5       3.1   43.8   15.8  643.8  0.0  0.1    1.4   0   3   0   0   0   0 
sd6       5.2   38.1   14.3  494.4  0.0  0.1    3.0   0   7   0   0   0   0 
sd7       4.2   40.2   11.1  623.2  0.0  0.1    2.7   0   7   0   0   0   0 
sd8       3.6   44.3    9.7  623.2  0.0  0.1    1.5   0   4   0   0   0   0 
sd9       2.9   37.4    7.0  494.4  0.0  0.1    1.3   0   2   0   0   0   0 
sd10      0.7    0.4    3.4    0.0  0.0  0.0    0.0   0   0   0   0   0   0

Opóźnienie odrobinę po wysokiej stronie?

# zpool iostat 10 10
               capacity     operations    bandwidth      latency
pool        alloc   free   read  write   read  write   read  write
tank         909G  1.83T     86  2.82K   208K  12.7M  22.68  13.63
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     29    857  42.4K  3.50M  17.86   4.47
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     30    947  46.1K  3.54M  15.55   5.67

Zastosowałem trochę poprawek, które nie miały większego znaczenia. zfs_top_maxinflight ustawiony na 127, zfs_scrub_delay na 0, a zfs_scan_idle na 0.

# echo zfs_top_maxinflight | mdb -k
zfs_top_maxinflight:
zfs_top_maxinflight:            127

# echo zfs_scrub_delay/D |mdb -k
zfs_scrub_delay:
zfs_scrub_delay:0

# echo zfs_scan_idle/D |mdb -k
zfs_scan_idle:
zfs_scan_idle:  0


 scan: scrub in progress since Wed Apr 17 20:47:23 2013
    1.85G scanned out of 918G at 1.14M/s, 229h36m to go
    0 repaired, 0.20% done

przed modyfikacją mdb, zauważ raczej wysoką kolumnę b%

$ iostat -nx -M 5 

  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t395301D6B0C8069Ad0
 35.2   44.2    0.3    0.7  0.0  0.4    0.0    5.3   0  32 c7t5000C500415DC933d0
 19.8    3.2    0.2    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A72030068545d0
 31.2   46.2    0.2    0.7  0.0  0.3    0.0    4.4   0  27 c7t5000C500415DC797d0
 30.6   46.8    0.2    0.8  0.0  0.4    0.0    4.6   0  28 c7t5000C500414FCA57d0
 37.6   53.0    0.3    0.8  0.0  0.4    0.0    4.7   0  33 c7t5000C500415C3B1Bd0
 37.6   53.6    0.3    0.8  0.0  0.5    0.0    5.6   0  39 c7t5000C500415C5E4Fd0
 33.2   46.8    0.3    0.8  0.0  0.5    0.0    6.1   0  33 c7t5000C500414FB2CFd0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c7t5000A7203006D81Ed0

po ulepszeniu mdb, zauważ kolumnę b%, 80-85% czasu w zajętym oczekiwaniu

$ iostat -nx -M 5 
  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.2   27.2    0.0    0.3  0.0  1.0    0.0   35.4   0  18 c0t395301D6B0C8069Ad0
129.6   20.2    0.9    0.4  0.0  2.9    0.0   19.5   0  85 c7t5000C500415DC933d0
 48.4    4.0    0.4    0.0  0.0  0.0    0.0    0.1   0   1 c7t5000A72030068545d0
130.4   19.8    0.9    0.4  0.0  3.0    0.0   20.2   0  84 c7t5000C500415DC797d0
125.8   25.8    0.9    0.5  0.0  2.9    0.0   19.2   0  80 c7t5000C500414FCA57d0
131.2   24.2    0.9    0.5  0.0  3.1    0.0   20.3   0  83 c7t5000C500415C3B1Bd0
130.6   25.8    0.9    0.5  0.0  3.5    0.0   22.5   0  88 c7t5000C500415C5E4Fd0
126.8   28.0    0.9    0.5  0.0  2.8    0.0   18.0   0  79 c7t5000C500414FB2CFd0
  0.2    0.0    0.0    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A7203006D81Ed0
zfs  nexenta 
— 3molo
źródło
Jakie wielokrotne wystąpienie iostatu -XnE | grep Błędy mówi? zrobić jakieś zwiększenie liczby błędów?
Zero we wszystkich kolumnach
— 3molo 16.04.13
Co smartctl -A /dev/diskmówi o każdym dysku (może być konieczne zainstalowanie smartctl, nie jestem pewien, czy pochodzi z podstawowej instalacji).
— Chris S
1
Nic ciekawego oprócz „Non-medium error error: 8071” na jednym dysku. Wszystkie dyski siedzą w JBOD (Dell MD1200) na tym samym (pojedynczym) pasie sas
— 3molo

Odpowiedzi:

11

Operacje szorowania w ZFS działają na zasadzie dość nieprzytomnej. Przede wszystkim szoruje czas tylko wtedy, gdy nic innego się nie dzieje. Jeśli wciśniesz pulę z niewielkim dostępem do danych na dość stałym poziomie, scrub skutecznie się zagłodzi i prawie nic nie zrobi.

Tunables do eksploracji, z moimi krótkimi notatkami na temat tego, co robi (chociaż ostatnio temu przyglądałem się):

  • zfs_scan_idle - jeśli wystąpi we / wy użytkownika w tak wielu tyknięciach zegara, opóźnij szorowanie we / wy przez taktowanie zegara zfs_scrub_delay
  • zfs_scrub_delay - ile tyknięć zegara opóźnia operację szorowania, jeśli zostanie wywołane przez zfs_scan_idle
  • zfs_top_maxinflight - maksymalna liczba operacji we / wy szorowania na vdev najwyższego poziomu
  • zfs_scrub_limit - maksymalna liczba operacji we / wy szorowania na vdev liścia
  • zfs_scan_min_time_ms - minimalny czas ms na txg na operacje szorowania
  • zfs_no_scrub_io - brak notatek
  • zfs_no_scrub_prefetch - brak notatek, nazwa sugeruje, że nie powoduje pobierania wstępnego w operacjach scrub

Wszystkie te można zmieniać w locie za pomocą „echo [przestrajalne] / W0t [liczba]”, aby zmienić, i „echo [przestrajalne] / D”, aby wyświetlić bieżące ustawienie (które zalecam zrobić przed zmianą).

Więc teoretycznie i w ogólnej praktyce, jeśli chcesz, powiedzmy, zmienić zfs_scan_idle na 10 (lub 1 - lub 0, jeśli to obsługuje, trzeba sprawdzić kod) i zfs_scrub_delay na 1 (lub 0, jeśli obsługuje to), a jeśli twoje ustawienie txg_synctime_ms wynosi 5000 lub więcej, może nieco zmienić zfs_scan_min_time_ms, powinno stać się o wiele bardziej agresywne w kwestii wykonywania operacji szorowania nawet przy pewnym poziomie we / wy użytkownika.

W twoim konkretnym przypadku zgłoszone% b i asvc_t sugerują, że dzieje się bardzo, bardzo losowe obciążenie odczytu (wirowanie dysków powinno być lepsze, jeśli jest naprawdę sekwencyjne), a już wykonałeś „łatwe” czynności, jak wyjaśniono powyżej . Najpierw włączę zfs_no_scrub_prefetch, aby wyłączyć pobieranie wstępne operacji scrub, aby zobaczyć, czy to pomogło. Jeśli nie ma radości, w zależności od wersji Nexenta, na której jesteś - być może korzystasz z wersji 30/5, 5/1 lub 10/5 (to jest skrót, którego używamy do ustawień zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)). Zmień zfs_txg_timeout na 10 i zfs_txg_synctime_ms na 5000, a następnie spróbuj zwiększyć zfs_scan_min_time_ms do 3000 lub 4000. To mówi ZFS, że może spędzać dużo dłużej na scrubach, w porównaniu do ustawień domyślnych w starszych instalacjach NexentaStor, które domyślnie używają 5/1 ostrożny,

Mam nadzieję że to pomoże. Powodzenia!

— Nex7
źródło
Przypuszczam, że powinienem zauważyć, że modyfikujesz te ustawienia w bash przy użyciu „echo <następne> / W0t <numer> | mdb -kw”. I przeglądasz bieżące wartości za pomocą „echo <następne> / D | mdb -k”. Moje notatki mówią, że wszystko to można zmienić w locie, żadna z nich nie wymaga modyfikacji / etc / systemu i zrestartowania, aby zadziałało.
— Nex7
Powinienem również przeczytać całe pytanie przed udzieleniem odpowiedzi - i przestać przeglądać ServerFault podczas połączeń konferencyjnych. :)
— Nex7
Zgłoszone% b i asvc_t sugerują, że dzieje się bardzo, bardzo losowe obciążenie odczytu (wirujące dyski powinny działać lepiej, jeśli jest to naprawdę sekwencyjne). Najpierw włączyłem zfs_no_scrub_prefetch, aby wyłączyć pobieranie wstępne w operacjach scrub, aby zobaczyć, czy to pomogło. Jeśli nie ma radości, w zależności od wersji Nexenta, na której jesteś - być może korzystasz z wersji 30/5, 5/1 lub 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000). Zmień zfs_txg_timeout na 10 i zfs_txg_synctime_ms na 5000, a następnie spróbuj podniesienie zfs_scan_min_time_ms do 3000 lub 4000. To mówi ZFS, że może spędzać znacznie więcej czasu na szorowaniu, może zagłodzić normalne
— operacje
Myślę, że przekazujesz bardzo cenny wkład, ale byłoby o wiele bardziej pomocne, gdybyś mógł dodać komentarze do jednej dobrej odpowiedzi.
— 3molo
2
Więcej tuningu mogło pomóc, ale niekoniecznie. Należy zauważyć, że szorowanie ZFS toczy się po strukturze danych, NIE sektor po sektorze na dyskach. To znaczy, w zależności od tego, jak struktura danych ZFS wygląda na dyskach, operacja szorowania może wyglądać niesamowicie losowo - dyski mogą być w stanie> 100 MB / s sekwencyjnego odczytu, ale całkowicie losowy odczyt będzie zupełnie inną historią . Średni rozmiar bloku również miałby tutaj znaczenie.
— Nex7
3

Podejrzewam sprzęt ...

Dlaczego miałbyś pozwolić temu działać przez 15 dni? To nie jest normalne. Zatrzymaj szorowanie - zpool scrub -s tanki sprawdź system.

  • Z jakich kontrolerów korzystasz?
  • Czy to pierwszy peeling, jaki kiedykolwiek uruchomiłeś w tej puli?
  • Czy pojawił się problem, który skłonił Cię do uruchomienia szorowania?
— ewwhite
źródło
1
LSI SAS9200-8e (oprogramowanie IT). Nie pierwsze szorowanie. Nie, żadnych prawdziwych problemów (ale od jakiegoś czasu kwestionuję wydajność sekwencyjnego odczytu / zapisu).
— 3molo
Aktualizowany z opóźnieniami i czasami oczekiwania, zaczynając podejrzewać, że zawsze jest trochę czasu na obsługę zgłoszeń, a priorytetem jest szorowanie tak niskie, że czołganie się zatrzymuje. Każdy wgląd jest bardzo pomocny!
— 3molo
Scruby są ważne do okresowego uruchamiania. Oczekiwanie, aż wystąpi problem z uruchomieniem czyszczenia, wymaga, aby problem ten wybuchł w wyniku utraty danych. Scrubsy służą do wykrywania cichego uszkodzenia danych (bitrot). Wolno działające szorowanie nie jest oznaką problemu systemowego, tylko pulę, która jest wystarczająco zajęta, aby nie przyspieszyć szorowania.
— lschweiss
0

Moja odpowiedź przychodzi trochę później, ale jeśli coś takiego przydarzy się komukolwiek innemu, oto moje zdanie: po prostu wypróbuj „dmesg”. W moim przypadku nie przeprowadzałem szorowania, ale kopiowałem pliki na dyski i wyraźnie słyszałem, że dyski są aktywne przez kilka sekund, a potem zatrzymują się na dłużej, i znów działają i tak dalej. Było to spowodowane awarią jednego kontrolera SATA i dmesg dał mi wszystkie błędy. Początkowo myślałem, że to dysk ulegający awarii, ale potem zdałem sobie sprawę, że to właściwie kontroler.

— jytou
źródło
-3

Scrub wykorzystuje dostępne przestoje systemu, nawet na nieobciążonym serwerze, dotyczy dostępności. Ram i procesor są kluczami do wykorzystania szorowania, a nie dysku. Im więcej z nich jest dostępnych, tym lepsza będzie wydajność szorowania. Z pewnością jednak w tym przypadku, im lepsze są Twoje dyski, pod względem ZPools, tym lepsza będzie również wydajność szorowania.

Tak więc, jeśli Twoja wydajność była niska i wydaje się, że tak jest, uważam, że są to potencjalne powody.

— użytkownik169761
źródło
1
Nie widzę żadnych oznak, że brakuje zasobów.
— 3molo
1
To jest prawie całkowicie nieprawdziwe. Procesor i pamięć RAM mają zerowy wpływ na operacje szorowania (przy założeniu, że w ogóle są wolne). Posiadanie dużej ilości wolnej pamięci RAM i procesora nie przyspieszy operacji szorowania. Scrub jest ograniczony przez obserwowanie przychodzących I / O do puli, a nie przez sprawdzanie „dostępnego przestoju systemu”, cokolwiek to jest.
— Nex7
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.