Ext4 wykorzystanie i wydajność

Mam klaster maszyn z węglem i grafitem, które muszę skalować, aby uzyskać więcej miejsca, ale nie jestem pewien, czy muszę zwiększyć lub zmniejszyć.

Klaster składa się obecnie z:

• 1 węzeł przekaźnikowy: odbiera wszystkie metryki i przekazuje do odpowiedniego węzła magazynowania
• 6 węzłów magazynowych: mieści wszystkie pliki DB Whisper

Problem polega na tym, że wydaje się, że kiedy dyski osiągnęły poziom 80% zużycia, wydajność spadła z klifu. Klaster zapisujący IOPS spadł z prawie stałej 13k do bardziej chaotycznej średniej wynoszącej około 7k, a czas oczekiwania IOwait wynosi średnio 54%.

Przejrzałem nasze repozytorium konfiguracji i od początku kwietnia nie ma żadnych zmian, więc nie jest to wynikiem zmiany konfiguracji.

Pytanie: Czy zwiększenie rozmiaru dysku przywróci kontrolę wydajności IO, czy też muszę dodać więcej węzłów magazynowania?

Uwaga: nie ma tutaj dysków SSD, tylko mnóstwo wrzecion.

Odpowiednie wykresy:

Statystyki i rzeczy:

e2freefrag:

[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)

Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    4K...    8K-  :          4008          4008    0.08%
    8K...   16K-  :          1723          3992    0.08%
   16K...   32K-  :           703          3495    0.07%
   32K...   64K-  :           637          7400    0.15%
   64K...  128K-  :          1590         29273    0.61%
  128K...  256K-  :          4711        236839    4.95%
  256K...  512K-  :          2664        265691    5.56%
  512K... 1024K-  :          2359        434427    9.08%
    1M...    2M-  :           595        213173    4.46%
    2M...    4M-  :            75         49182    1.03%
   64M...  128M-  :             6        118890    2.49%

e4defrag:

[root@graphite-storage-01 ~]# e4defrag -c /dev/vda3
<Fragmented files>                             now/best       size/ext
1. /opt/graphite/storage/graphite.db            17/1              4 KB
2. /var/log/cron                                13/1              4 KB
3. /var/log/wtmp                                16/1              4 KB
4. /root/.bash_history                           4/1              4 KB
5. /var/lib/rpm/Sha1header                      10/1              4 KB

 Total/best extents                             182256/159981
 Average size per extent                        183 KB
 Fragmentation score                            2
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/vda3) does not need defragmentation.
 Done.

iostat:

[root@graphite-storage-01 ~]# iostat -k -x 60 3
Linux 3.10.0-229.7.2.el7.x86_64 (graphite-storage-01)     07/05/2016      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.99    0.00    2.54   29.66    0.35   59.46

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00   100.34  177.48 1808.94  2715.66  7659.19    10.45     0.26    0.13    0.65    0.08   0.23  46.14

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.17    0.00    7.00   73.21    0.58   13.04

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    23.87  672.40  656.47  8729.87  2752.27    17.28     7.36    5.50    2.72    8.35   0.73  96.83

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.06    0.00    7.31   73.03    0.59   12.01

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    42.68  677.67  614.88  8634.93  2647.53    17.46     6.66    5.15    2.72    7.83   0.74  96.08

df:

[root@graphite-storage-01 ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda3       39153856 33689468   3822852  90% /
devtmpfs         1933092        0   1933092   0% /dev
tmpfs            1941380        0   1941380   0% /dev/shm
tmpfs            1941380   188700   1752680  10% /run
tmpfs            1941380        0   1941380   0% /sys/fs/cgroup
/dev/vda2         999320     2584    980352   1% /tmp
[root@graphite-storage-01 ~]# df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda3      2490368 239389 2250979   10% /
devtmpfs        483273    304  482969    1% /dev
tmpfs           485345      1  485344    1% /dev/shm
tmpfs           485345    322  485023    1% /run
tmpfs           485345     13  485332    1% /sys/fs/cgroup
/dev/vda2        65536     22   65514    1% /tmp

Edycja: Zmieniłem rozmiar jednego z węzłów magazynowania, ale to nie miało żadnego efektu. Znalazłem również cachestatnarzędzie w [ https://github.com/brendangregg/perf-tools](a zbiór narzędzi perf), które pozwoliło mi zajrzeć do pamięci podręcznej VFS. W tym momencie wygląda na to, że osiągnąłem limit przepustowości we / wy, który może zapewnić moja pamięć.

W tym momencie myślę, że albo będę musiał kontynuować skalowanie do większej liczby członków klastra, albo dowiedzieć się, jak znaleźć bardziej wydajne rozwiązanie do przechowywania szeregów czasowych.

Przykładowe dane wyjściowe z cachestat:

storage-01 [resized disk]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    9691    14566     7821    40.0%          160       2628
   36181    14689     7802    71.1%          160       2631
    8649    13617     7003    38.8%          159       2628
   15567    13399     6857    53.7%          160       2627
    9045    14002     7049    39.2%          160       2627
    7533    12503     6153    37.6%          159       2620

storage-02 [not resized]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    5097    11629     4740    30.5%          143       2365
    5977    11045     4843    35.1%          142       2344
    4356    10479     4199    29.4%          143       2364
    6611    11188     4946    37.1%          143       2348
   33734    14511     5930    69.9%          143       2347
    7885    16353     7090    32.5%          143       2358

Bardzo późna edycja: Od tego czasu przeprowadziliśmy migrację na inną platformę, na której dostępne są dyski SSD, i chociaż przez pewien czas wszystko było dobrze, w końcu zauważyliśmy ten sam gwałtowny spadek wydajności, ponieważ dodawaliśmy coraz więcej wskaźników. Chociaż nie mam żadnego ostatecznego dowodu, uważam, że jest to kluczowy przypadek między działaniem magazynu Carbon / Whisper a samą liczbą przechowywanych danych.

Zasadniczo, o ile system ma wystarczającą ilość pamięci RAM, aby wygodnie buforować pliki Whisper do odczytu, IO jest prawie czystym zapisem i wszystko jest szczęśliwe. Jednak po włączeniu głodzenia pamięci podręcznej FS i szeptaniu pliki muszą być stale odczytywane poza dyskiem, który zjada się do przepustowości we / wy i wszystko zaczyna rosnąć.

Wygląda na to, że używasz dysków SSD, które mogą mieć trochę funky, gdy się zapełni. Fakt, że gdy zużycie spadło około 6/1, wydajność nie wróciła do normy, potwierdza tę teorię.

Powód tego wszystkiego jest dość skomplikowany, ale w zasadzie sprowadza się do konieczności usunięcia napisanych, ale obecnie nieużywanych fragmentów pamięci flash, zanim będzie można ją ponownie napisać. Wygląda na to, że piszesz dość mocno, więc proces wygaszania w napędzie nie ma szans na utrzymanie wystarczającej ilości pustych fragmentów, gdy wszystkie zostaną zapisane.

Różne modele napędów mają różne kontrolery i różne ilości „zapasowych” fragmentów pamięci flash do użycia, a większe dyski mają oczywiście więcej fragmentów do zapisania, zanim zabraknie im nowych bitów, więc jest prawie pewne, że uaktualnienie do większych dysków „rozwiąże” problem dla ciebie, przynajmniej tymczasowo. Dyski klasy „Enterprise” zwykle radzą sobie lepiej pod tym względem, ale nowsze modele kontrolerów flash, więc to trochę bzdura, przy braku wiarygodnych testów stron trzecich konkretnego modelu dysku na wzór podobny do Twój własny.

Może również być w stanie uciec z wykorzystaniem dysków masz teraz na trochę więcej czasu, jeśli fala coś fstrimna nich powiedzieć napędu „na pewno można wytrzeć wszystkie te kawałki prawo teraz ”, choć robi to w systemie musisz robić inne rzeczy w tym samym czasie, może nie pójść tak dobrze (będziesz chciał dobrze zanotować ostrzeżenia o wydajności na stronie fstrimpodręcznika).

Co do tego, czy potrzebujesz więcej węzłów, nie mogę powiedzieć na pewno, ale nie sądzę. Procesor nie wygląda na wymykający się spod kontroli i wątpię, byś nasycił system I / O gdzie indziej.

Ext3 / 4 są znane z tego, że cierpią z punktu widzenia wydajności, z wykorzystaniem powyżej 80-85%. Jest to spowodowane zwiększoną fragmentacją i zmniejszoną wydajnością zapisu.

Czy możesz zapewnić dwa iostat -k -x 60 3wyjścia, jeden przy 80% pojemności i jeden przy 80%?

EDYCJA:e2freefrag wydaje się, że masz /dev/vda3dużo wolnego miejsca. Czy możesz dodać dane wyjściowe dfi df -i?

W każdym razie iostatwyniki w połączeniu z wykresami (szczególnie „Disk IOPS”) są dość interesujące. Wygląda na to, że twoje obciążenie jest bardzo skoncentrowane na pisaniu; gdy> 95% wszystkich wydanych IOPS jest zapisywanych, nie ma problemu. Jednak, gdy wydajność spada, dyski zaczynają obsługiwać spójny odczyt IOPS. Ten zmieszany odczyt / zapis zakłóca zdolność dysków do łączenia wielu mniejszych zapisów w większe (odczyty zwykle są operacjami blokującymi), co prowadzi do znacznie wolniejszej pracy.

Na przykład zobaczmy wynik pięści pokazany przez iostat: gdy całkowite operacje IOPS na dysku są zdominowane przez zapisy (jak w tym przypadku), twoje avgqu-szi awaitoba są bardzo niskie.

Ale w drugim i trzecim iostatwidzimy o wiele więcej odczytów, które jako operacje blokowania / przeciągania (patrz rrqm/skolumna: pokazuje 0, więc nie można scalić odczytów w twoim przypadku), zakłócają zarówno opóźnienie ( await), jak i przepustowość (KB / s) .

Widziałem podobne zachowanie, gdy hostowi zabrakło pamięci podręcznej i-węzłów, być może z powodu dużej liczby przechowywanych małych plików. Aby dostroić system do preferowania pamięci podręcznej i-węzłów dentystycznych kosztem pamięci podręcznej danych, spróbuj wydać echo 10 > /proc/sys/vm/vfs_cache_pressurei poczekaj kilka minut: czy coś to zmienia?