Використання та продуктивність Ext4

У мене є група машин, на яких працює карбон і графіт, які мені потрібно масштабувати для збільшення обсягу зберігання, але я не впевнений, чи потрібно мені масштабувати або зменшувати.

В даний час кластер складається з:

• 1 Релейний вузол: отримує всі показники та пересилає до відповідного вузла зберігання
• 6 вузлів зберігання: вміщує всі файли БД Whisper

Проблема полягає в тому, що, здається, коли диски потрапляли в сусідство з 80% використанням, продуктивність відвалилася від обриву. IOPS запису кластерів впав з майже постійної 13k до більш хаотичного середнього в середньому 7k, а час IOwait в середньому становить 54%.

Я переглянув наше конфігураційне репо і не було змін з початку квітня, тому це не є результатом зміни конфігурації.

Запитання: Чи збільшить розмір диска повернення продуктивності IO під контроль, чи мені потрібно додати більше вузлів пам’яті?

Примітка: тут немає SSD, просто багато і багато шпинделів.

Відповідні графіки:

Статистика та речі:

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

Редагувати: я змінив розмір одного з вузлів зберігання, але це не вплинуло. Я також знайшов cachestatутиліту в [ https://github.com/brendangregg/perf-toolsSense(a колекція перф-інструментів), яка дала мені заглянути в кеш VFS. На даний момент, схоже, я досяг границі пропускної здатності вводу-виводу, яку може забезпечити моє сховище.

На даний момент я думаю, що мені або доведеться продовжувати масштабувати більше членів кластера, або бачити рішення щодо більш ефективного для запису рішення для зберігання часових рядів.

Приклад виведення з 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

Супер пізнє редагування: з тих пір ми перейшли на іншу платформу, де доступні SSD-диски, і, хоча все було добре протягом певного часу, ми врешті-решт спостерігали таке ж різке зниження продуктивності, як ми додавали все більше показників. Хоча я не маю жодних остаточних доказів, я вважаю, що це важливий випадок між тим, як працює зберігання вуглецю / Шепіт, і великою кількістю метрик, які ми зберігаємо.

В основному, поки система має достатню кількість оперативної пам’яті, щоб зручно кешувати файли Whisper для читання IO, це майже чисто записування, і все задоволено. Однак, як тільки голод FS кешу наступає і файли Whisper потрібно постійно читати з диска, який потрапляє у вашу пропускну здатність IO, і все починає проходити.

Здається, що ви використовуєте SSD, які можуть мати деякі приємні характеристики продуктивності по мірі їх повноцінного використання. Факт, що коли використання зменшилося на рівні 6/1, продуктивність не повернулася до нормального, підтверджує цю теорію.

Причина цього все досить складна, але в основному зводиться до необхідності очистити написані, але наразі невикористані шматки спалаху, перш ніж його можна буде записати знову. Схоже, ви пишете досить важко, тому процес блокування, що працює на диску, не має шансу зберегти достатню кількість запасних фрагментів, коли всі вони записані один раз.

У різних моделях накопичувача є різні контролери, і різну кількість «запасних» флеш-флешів для використання, а більші диски, очевидно, мають більше шматочків для запису, перш ніж у них закінчуються свіжі біти, тому майже впевнене, що оновлення до більш великих дисків «вирішить» проблема для вас, принаймні тимчасово. У цьому відношенні накопичувачі «Корпоративного», як правило, краще, але нові моделі флеш-контролера, тому це трохи нерозумно, за відсутності надійного стороннього тестування певної моделі приводів у схемі використання, подібній до ваш власний.

Можливо, вам також вдасться піти з використанням накопичувачів, які у вас є, ще на деякий час, якщо ви будете махати чимось на кшталт fstrimних, щоб сказати накопичувачу, "ви можете точно витерти всі ці шматки прямо зараз ", хоча це робити в системі вам потрібно одночасно робити інші речі, можливо, це не знизиться (ви хочете добре відзначити попередження про ефективність на сторінці сторінки fstrim).

Щодо того, чи потрібно вам більше вузлів, я не можу сказати точно, але не думаю. Процесор не виглядає поза контролем, і я сумніваюся, що ви наситили б систему вводу / виводу в іншому місці.

Добре відомо, що Ext3 / 4 страждає з точки зору продуктивності, використовуючи вище 80-85%. Це пояснюється посиленою фрагментацією та зниженням продуктивності запису.

Чи можете ви надати два iostat -k -x 60 3вихідні показники: один, коли є менше 80%, і один, коли понад 80%?

EDIT: з вашого боку, e2freefragздається, /dev/vda3є багато вільного місця. Чи можете ви додати результат dfі df -i?

У будь-якому випадку, ваші iostatрезультати в поєднанні з вашими графіками (особливо "Disk IOPS") є досить цікавими. Здається, ваша завантаженість дуже зосереджена на записі; коли> 95% всього виданого IOPS записується, у вас немає проблем. Однак, коли ваша продуктивність знижується, ваші диски починають обслуговувати послідовно прочитаний IOPS. Це змішане читання / запис порушує здатність дисків до комбінування декількох менших записів у більші (зчитування, як правило, блокують операції), що призводить до набагато більш повільної продуктивності.

Наприклад, дозвольте побачити результат кулаків, показаний iostat: коли в загальному диску IOPS домінують записи (як у цьому випадку), ваш avgqu-szі awaitобидва дуже низькі.

Але у другому та третьому iostatми бачимо ще багато зчитувань, які, блокуючи / зупиняючи операції (див. rrqm/sСтовпець: він показує 0, тому жодне читання не може бути об'єднане у вашому випадку), порушує як затримку ( await), так і пропускну здатність (КБ / с) .

Я бачив подібну поведінку, коли у хоста закінчується кеш inode, можливо, через велику кількість збережених невеликих файлів. Щоб налаштувати вашу систему, віддаючи перевагу кеш-пам'яті inode / dentry за рахунок кешу даних, спробуйте видати echo 10 > /proc/sys/vm/vfs_cache_pressureі почекайте кілька хвилин: чи щось змінить?