Использование и производительность Ext4
У меня есть кластер машин с Carbon и Graphite, который мне нужно масштабировать для увеличения хранилища, но я не уверен, нужно ли мне масштабировать или расширять.
В настоящее время кластер состоит из:
- 1 узел ретрансляции: получает все показатели и пересылает на соответствующий узел хранения.
- 6 узлов хранения: вмещает все файлы Whisper DB
Проблема в том, что кажется, что когда диски использовались примерно на 80%, производительность упала со скалы. IOPS записи кластера упало с почти постоянных 13k до более хаотичного среднего значения около 7k, а время ожидания ввода-вывода составляет в среднем 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-toolspting(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
Супер позднее редактирование: С тех пор мы перешли на другую платформу, где доступны твердотельные накопители, и, хотя некоторое время все было хорошо, в конечном итоге мы увидели такое же резкое снижение производительности, поскольку мы добавляли все больше и больше показателей. Хотя у меня нет окончательных доказательств, я считаю, что это угловой случай между тем, как работает хранилище Carbon / Whisper, и огромным количеством показателей, которые мы храним.
По сути, пока в системе достаточно ОЗУ для удобного кэширования файлов Whisper для чтения, ввод-вывод - это почти чистая запись, и все в порядке. Однако, как только наступает нехватка кеша FS и файлы Whisper должны постоянно считываться с диска, который съедает вашу пропускную способность ввода-вывода, и все начинает работать.
Похоже, вы используете твердотельные накопители, которые при заполнении могут иметь некоторые забавные характеристики производительности. Тот факт, что когда использование упало примерно на 6/1, производительность не вернулась к норме, подтверждает эту теорию.
Причина этого довольно сложна, но в основном сводится к необходимости очистить записанные, но в настоящее время неиспользуемые фрагменты флеш-памяти, прежде чем ее можно будет записать снова. Похоже, вы пишете довольно сложно, поэтому у процесса гашения, запущенного на диске, нет возможности поддерживать достаточный запас пустых блоков, когда все они записываются один раз.
Разные модели дисков имеют разные контроллеры и разное количество «запасных» фрагментов флеш-памяти для использования, а на более крупных дисках, очевидно, есть больше фрагментов для записи, прежде чем у них закончатся свежие биты, поэтому почти наверняка обновление до более крупных дисков «решит» проблема для вас, хотя бы временно. Диски корпоративного класса, как правило, работают лучше в этом отношении, но также и более новые модели флэш-контроллеров, так что это немного дурацкая работа в отсутствие надежного стороннего тестирования конкретной модели диска в схеме использования, аналогичной твой собственный.
Возможно, вам также удастся обойтись без накопителей, которые у вас есть сейчас, на некоторое время, если вы помашите чем-то вроде fstrim над ними, чтобы сообщить диску "вы определенно можете стереть все эти куски сейчас", хотя выполнение этого в системе, в которой вам нужно одновременно заниматься другими делами, может не сработать так хорошо (вы захотите хорошо отметить предупреждения о производительности в fstrim страница руководства).
Что касается того, нужно ли вам больше узлов, я не могу точно сказать, но я так не думаю. ЦП не выходит из-под контроля, и я сомневаюсь, что вы переполните систему ввода-вывода где-нибудь еще.
Хорошо известно, что Ext3 / 4 страдает с точки зрения производительности при использовании выше 80-85%. Это связано с повышенной фрагментацией и сниженной производительностью обратной записи.
Вы можете предоставить два iostat -k -x 60 3 выход, один при емкости менее 80% и один при более 80%?
РЕДАКТИРОВАТЬ: от твоего e2freefrag похоже на то /dev/vda3 имеет много свободного места. Можете ли вы добавить вывод df и df -i?
Во всяком случае, ваш iostat результаты в сочетании с вашими графиками (особенно «Disk IOPS») весьма интересны. Кажется, ваша рабочая нагрузка очень сильно ориентирована на запись; когда> 95% от общего числа выданных операций ввода-вывода в секунду приходятся на запись, у вас нет проблем. Однако, когда ваша производительность снижается, ваши диски начинают обслуживать постоянное количество операций ввода-вывода в секунду при чтении. Это смешанное чтение / запись нарушает способность дисков объединять несколько меньших операций записи в более крупные (операции чтения обычно блокируют операции), что приводит к гораздо более низкой производительности.
Например, давайте посмотрим на результат кулаков, показанный iostat: когда в общем объеме операций ввода-вывода на диск преобладают записи (как в этом случае), ваш avgqu-sz и await оба очень низкие.
Но во втором и третьем iostat мы видим гораздо больше операций чтения, которые блокируют / останавливают операции (см. rrqm/s столбец: он показывает 0, поэтому в вашем случае считывания не могут быть объединены), нарушить обе задержки (await) и пропускной способности (КБ / с).
Я видел подобное поведение, когда у хоста закончился кеш inode, возможно, из-за огромного количества сохраненных небольших файлов. Чтобы настроить вашу систему так, чтобы она предпочитала кеш inode / dentry за счет кеша данных, попробуйте выполнить echo 10 > /proc/sys/vm/vfs_cache_pressure и подождите несколько минут: это что-то меняет?