Ext4 использование и производительность

У меня есть кластер машин, на котором запущены Carbon и Graphite, которые мне нужно масштабировать для большего объема хранения, но я не уверен, нужно ли мне увеличивать или уменьшать масштаб.

Кластер в настоящее время состоит из:

• 1 узел ретрансляции: получает все метрики и пересылает на соответствующий узел хранения
• 6 узлов хранения: содержит все файлы Whisper DB

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

Я просмотрел наше конфигурационное хранилище, и с начала апреля изменений не было, так что это не результат изменения конфигурации.

Вопрос: Возьмет ли увеличение размера диска под контроль производительность ввода-вывода или мне нужно добавить больше узлов хранения?

Примечание: здесь нет 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-tools](a сборник инструментов perf), которая дала мне возможность заглянуть в кеш 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

Super Late Edit: с тех пор мы перешли на другую платформу, где доступны твердотельные накопители, и, хотя в течение некоторого времени все было хорошо, в конечном итоге мы наблюдали такое же резкое снижение производительности, когда добавляли все больше и больше показателей. Хотя у меня нет точных доказательств, я считаю, что это ключевой случай между тем, как работает хранилище Carbon / Whisper, и огромным количеством показателей, которые мы храним.

По сути, до тех пор, пока в системе достаточно ОЗУ для удобного кэширования файлов Whisper для чтения, ввод-вывод почти чистая запись, и все устраивает. Однако, как только начинается голодание кеша FS, и файлы Whisper должны постоянно считываться с диска, который съедает вашу пропускную способность ввода-вывода, и все начинает расти.

Похоже, вы используете SSD, у которых могут быть некоторые странные характеристики производительности по мере их заполнения. Тот факт, что когда использование упало около 6/1, производительность не вернулась к норме, подтверждает эту теорию.

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

Разные модели накопителей имеют разные контроллеры и разное количество «запасных» блоков флэш-памяти для использования, и более крупные диски, очевидно, имеют больше блоков для записи, прежде чем заканчиваются свежие биты, поэтому почти наверняка переход на более крупные диски «решит» проблема для вас, по крайней мере, временно. В этом отношении накопители класса «Enterprise», как правило, работают лучше, но и более новые модели контроллеров флэш-памяти, так что это довольно круто, в отсутствие надежного стороннего тестирования конкретной модели накопителя в схеме использования, аналогичной твой собственный.

Вы также можете избежать использования дисков, которые у вас сейчас есть, еще некоторое время, если вы махнете что-то вроде fstrimних, чтобы сказать диску «вы определенно можете стереть все эти блоки прямо сейчас », хотя это делается в системе. вам нужно заниматься другими делами, в то же время, возможно, все не так хорошо (вы должны хорошо отметить предупреждения о производительности на fstrimстранице руководства ).

Что касается того, нужно ли вам больше узлов, я не могу сказать точно, но я так не думаю. Процессор не выглядит неуправляемым, и я сомневаюсь, что в других местах вы будете насыщать систему ввода-вывода.

Известно, что Ext3 / 4 страдает с точки зрения производительности при использовании более 80-85%. Это связано с повышенной фрагментацией и сниженной производительностью обратной записи.

Можете ли вы предоставить два iostat -k -x 60 3выходных сигнала: один при емкости менее 80%, а другой - более 80%?

РЕДАКТИРОВАТЬ: от вашего, e2freefragкажется, /dev/vda3есть много свободного места. Можете ли вы добавить вывод dfи df -i?

В любом случае, ваши iostatрезультаты в сочетании с вашими графиками (особенно «Disk IOPS») довольно интересны. Кажется, ваша рабочая нагрузка очень ориентирована на запись; когда> 95% от общего количества выпущенных операций ввода-вывода в секунду записывается, у вас нет проблем. Однако, когда ваша производительность ухудшается, ваши диски начинают обслуживать постоянные операции чтения-ввода-вывода в секунду. Это смешанное чтение / запись нарушает способность дисков объединять несколько меньших записей в большие (операции чтения обычно являются блокирующими операциями), что приводит к гораздо более низкой производительности.

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

Но во втором и третьем iostatмы видим еще много операций чтения, которые, будучи блокирующими / блокирующими операциями (см. rrqm/sСтолбец: он показывает 0, поэтому никакие операции чтения не могут быть объединены в вашем случае), нарушают как latency ( await), так и пропускную способность (КБ / с) ,

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