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ż cachestat
narzę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ąć.
źródło
Odpowiedzi:
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ś
fstrim
na 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 stroniefstrim
podrę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.
źródło
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 3
wyjścia, jeden przy 80% pojemności i jeden przy 80%?EDYCJA:
e2freefrag
wydaje się, że masz/dev/vda3
dużo wolnego miejsca. Czy możesz dodać dane wyjściowedf
idf -i
?W każdym razie
iostat
wyniki 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), twojeavgqu-sz
iawait
oba są bardzo niskie.Ale w drugim i trzecim
iostat
widzimy o wiele więcej odczytów, które jako operacje blokowania / przeciągania (patrzrrqm/s
kolumna: 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_pressure
i poczekaj kilka minut: czy coś to zmienia?źródło
iostat
[dodane na dole mojego pytania], ponieważ żaden z węzłów magazynowych nie jest poniżej. Mam inne wystąpienia o zużyciu poniżej 80%, ale nic z podobnym obciążeniem do nich.