LINUX.ORG.RU

Тюнинг диска, барахлит жутко I\O

 , , ,


0

1

Копаюсь тута в virtualbox, шаманю с жестким диском, колдую в общем. Сама проблема в том, что на реальном сервере в некоторые моменты времени очень большая задержка отправки\приема с rabbitMQ сервера. Тама отваливаются некоторые службы из-за этого по таймауту (можно конечно выставить большие тайауты, но хочу все же оттюнинговать диск и проблему решить в корне, если получится). То есть послал сообщение в rabbitMQ, тебе ответ пришел, обычно это занимает миллисекунды, но в некоторые моменты доходит аж до 3-6 сек! Графики(zabbix) показывают iowait 5%\48% (средн.\макс. значения за месяц). В связи с этим я пришел к выводу, что причина и узкое место на сервере это I\O и из-за него такие лаги с rabbitMQ.

Потом я начал грешить на raid1. Ядренный процесс jbd (в моем случае это jbd2/md2-8) который отвечает за журнализацию ext4, постоянно, без остановки, чем то занят, iotop этого процесса постоянно скачет 5..10...99%! Хотя, по сути, должен отрабатывать каждые 15 сек., ибо в параметрах монтирования raid1 я указал commit=15. То есть каждые 15 сек. должен записывать в журнал. Ещё я заметил, что если отключить zabbix-server, то процесс этот запускается как положено через каждые 15 сек. Почему так?

Посмотрел iotop ещё раз, нет других процессов с большим %, ну mysql промелькивает 0.05%, nginx и прочие потроха.

Что пробовал (три раза запуск)

dd if=/dev/zero of=/tmp/output.img bs=16k count=30k
838860800 bytes (839 MB, 800 MiB) copied, 1.05715 s, 794 MB/s
838860800 bytes (839 MB, 800 MiB) copied, 0.442051 s, 1.9 GB/s
838860800 bytes (839 MB, 800 MiB) copied, 9.11132 s, 92.1 MB/s

Скорость записи скачет в 10 раз...какие-то блокировки ужасные

А вот если больший count поставить 70k, но уже rabbitMQ идет с задержкой и все потроха валятся из-за timeout и процессу jbd2/md2-8 сносит голову до 99% I\O
dd if=/dev/zero of=/tmp/output.img bs=16k count=70k
1174405120 bytes (1.2 GB, 1.1 GiB) copied, 6.25328 s, 188 MB/s


cat /etc/fstab
/dev/md3        /       ext4    commit=15,errors=remount-ro,relatime    0       1
/dev/md2        /boot   ext4    errors=remount-ro,relatime      0       1
/dev/sda4       swap    swap    defaults        0       0
/dev/sdb4       swap    swap    defaults        0       0
proc            /proc   proc    defaults                0       0
sysfs           /sys    sysfs   defaults                0       0
tmpfs           /dev/shm        tmpfs   defaults        0       0
devpts          /dev/pts        devpts  defaults        0       0

mount | grep "/dev/md3"
/dev/md3 on / type ext4 (rw,relatime,errors=remount-ro,commit=15,data=ordered) 

cat /proc/mdstat
md2 : active raid1 sdb2[1] sda2[0]
      523200 blocks [2/2] [UU]

md3 : active raid1 sdb3[1] sda3[0]
      1952461760 blocks [2/2] [UU]
      bitmap: 15/15 pages [60KB], 65536KB chunk

unused devices: <none>


df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       1.8T  1.4T  312G  83% /
devtmpfs        7.9G     0  7.9G   0% /dev
tmpfs           7.9G     0  7.9G   0% /dev/shm
tmpfs           7.9G  772M  7.1G  10% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/md2        487M   23M  435M   5% /boot
overlay         1.8T  1.4T  312G  83% /var/lib/docker/overlay2/29d42b8f520821ac9c12919a53c6eb7f4b1cf25c63cd03fe7f2a3341e547a42f/merged
shm              64M     0   64M   0% /var/lib/docker/containers/c1d856a4dce5aeb0d0e67e4bdb1e2123a1a2fbecfbb4c4fdfe91b1d75bf0b8a8/mounts/shm




Выхлоп iotop
Total DISK READ :      68.09 K/s | Total DISK WRITE :       9.27 M/s
Actual DISK READ:      68.09 K/s | Actual DISK WRITE:     594.86 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
  313 be/3 root        0.00 B/s  426.44 K/s  0.00 % 73.82 % [jbd2/md3-8]
13682 be/4 bib       0.00 B/s  215.01 K/s  0.00 % 43.27 % nginx: worker process
15381 be/4 mysql       0.00 B/s    3.58 K/s  0.00 %  0.61 % mysqld
15396 be/4 mysql       0.00 B/s    3.58 K/s  0.00 %  0.02 % mysqld
15401 be/4 mysql       0.00 B/s    7.17 K/s  0.00 %  0.02 % mysqld
13678 be/4 bib       0.00 B/s  630.70 K/s  0.00 %  0.00 % nginx: worker process
13679 be/4 bib       0.00 B/s    3.58 K/s  0.00 %  0.00 % nginx: worker process
13680 be/4 bib       0.00 B/s  207.84 K/s  0.00 %  0.00 % nginx: worker process
13681 be/4 bib      64.50 K/s  731.03 K/s  0.00 %  0.00 % nginx: worker process
13684 be/4 bib       0.00 B/s  111.09 K/s  0.00 %  0.00 % nginx: worker process
13685 be/4 bib       0.00 B/s  723.87 K/s  0.00 %  0.00 % nginx: worker process
11076 be/4 root        0.00 B/s    3.58 K/s  0.00 %  0.00 % python /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf


На сервере два HDD HGST HUS726020AL по 1.8TB, RAID1

Куда копать в первую очередь? Отчего так просто загрузить IO у сервера? Диск поменять не предлагать

UDP! Не redis, а rabbitMQ )) Перепутал

★★★★

Последнее исправление: gobot (всего исправлений: 3)

Да ты бредишь. redis - in-memory database

К диску он может обращаться только в момент бекапа (RDB и AOF), причём для RDB запускается отдельный форк со своей копией памяти. Если диск совсем дохлый, отключи AOF

router ★★★★★
()
Ответ на: комментарий от router

+1. или диск дохнет

Что значит дохнет?
с 2018 года работает уже 1500 uptime c этими же настройками. Просто раньше redis не стоял, поэтому проблема не актуальна так сильно была

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

Ну вот в этом и проблема. Или добавь память чтоб свап стал пустой, или переделай систему чтоб ей нужно было меньше памяти (но это вряд ли у тебя получится). Иначе всё так и будет лагать. Свап это не замена памяти, это аварийное хранилище чтобы сервер вместо того чтоб упасть просто начал лагать, дав тебе время исправить ситуацию с перерасходом.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)

dd надо просить отключить кэш дисков, хотя если у Вас рейд контроллер, то и кэш контроллера надо отключать. Посмотреть iops ы в системе iostat 1 /dev/nvme0n1 параметр tps
latency измерить утилитой fio
По идее нужено смотреть/сопоставлять два графика - число iops и iowait, чтобы увидеть корреляцию.

заббикс медленно рисовал картинки. База zabbix была на рейде, из двух дисков в стрйапе - диски по 10000 rpm.
поставил для базы zabbix PCI NVME. графики стали быстрее рисоваться ))

Vlad-76 ★★★★
()
Ответ на: комментарий от firkax

Хм, нашел процесс, который своп использовал (fail2ban 700MB жрал). Убил его, своп освободился. Но памяти свободной 6GB из 15GB.

Да, сейчас полегчало с IO

dd if=/dev/zero of=/tmp/output.img bs=16k count=70k
1174405120 bytes (1.2 GB, 1.1 GiB) copied, 8.28268 s, 142 MB/s


уже не валится, но все равно rabbitmq подлагивает, когда на диск записываешь через dd, например

TIME 2
TIME 1
TIME 2
TIME 1
TIME 44
TIME 3
TIME 2
TIME 1
TIME 2
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
ERROR Timeout to make rpc 
TIME 1940
TIME 1840
TIME 1741
TIME 1641
TIME 1541
TIME 1442
TIME 1342
TIME 1241
TIME 1141
TIME 1042
TIME 942
TIME 842
TIME 743
TIME 643
TIME 543
TIME 443
TIME 344
TIME 244
TIME 145
TIME 44
TIME 1
TIME 2
TIME 2
TIME 2
TIME 7
TIME 1
TIME 2
TIME 2
TIME 1
TIME 1


TIME это отклик в rabbitmq, можно заметить что когда запускаешь dd, то отклик аномально увеличивается до 1940, потом снова возвращается к нормальным показателям. Сейчас не валится, но на ГРАНИ, т.к. timeout стоит 2 сек. Раньше было хуже

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

забит на 100%

700MB

памяти 15GB

Свап-раздел 700MB при 15GB памяти? Очень странная схема, но если там было 6GB свободной то наверно дело было не в нём.

Я не использовал fail2ban никогда, но кажется он не должен никак влиять на работу системы, если никто не долбится с неправильными паролями в неё. Может там атака какая постоянно идёт?

А ещё, насчёт свапа. График его использования (и занятой памяти) есть? Может по крону какая-то задача запскается, сжирает всю память и выдавливает кого-то в свап, потом заканчивается, память освобождается, а свап остаётся.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от gobot

если диск и вправду дохнет, то тоже не предлагать его замену?
SMART смотреть, ошибки какие в контроллере диска возникают. какие задержки при чтении блоков диска.

Vlad-76 ★★★★
()
Ответ на: комментарий от Vlad-76

iostat 1 /dev/nvme0n1 параметр tps


iostat 1 /dev/md3

В среднем
read per sec (kB_read/s) - 4
write per sec(kB_wrtn/s) - 450
tps - 100 - 400 в среднем

С графиками zabbix данные сходятся. То есть запись в 100 раз больше идет, чем чтение

latency измерить утилитой fio

пока ещё не осилил, fio только установил

gobot ★★★★
() автор топика
Ответ на: комментарий от firkax

Своп 1 гиг, я освободил 700MB. ОЗУ всего 15, 6 свободно

А ещё, насчёт свапа. График его использования (и занятой памяти) есть

Графика свопа нет. Есть только график свободной памяти. Она в течении месяца была на уровне 4-6GB

gobot ★★★★
() автор топика
Последнее исправление: gobot (всего исправлений: 1)

Почему если

dd if=/dev/zero of=/tmp/output.img bs=8k count=100k && rm /tmp/output.img
838860800 bytes (839 MB, 800 MiB) copied, 0.513071 s, 1.6 GB
838860800 bytes (839 MB, 800 MiB) copied, 0.64741 s, 1.3 GB/s
838860800 bytes (839 MB, 800 MiB) copied, 0.707813 s, 1.2 GB/s
838860800 bytes (839 MB, 800 MiB) copied, 1.1688 s, 718 MB/s
838860800 bytes (839 MB, 800 MiB) copied, 0.562148 s, 1.5 GB/s

за 0.5 сек записывает при count=100, то, если увеличить count в 2 раза, то

dd if=/dev/zero of=/tmp/output.img bs=8k count=200k && rm /tmp/output.img
1677721600 bytes (1.7 GB, 1.6 GiB) copied, 10.1788 s, 165 MB/s
1677721600 bytes (1.7 GB, 1.6 GiB) copied, 17.0994 s, 98.1 MB/s


время записи возрастает не в 2 раза (как можно было бы предположить), а 20 раз!?

gobot ★★★★
() автор топика
Последнее исправление: gobot (всего исправлений: 3)
Ответ на: комментарий от gobot
  1. fail2ban ты отключил зря, и скоро об этом пожалеешь :D

  2. в этой mysql живёт zabbix? настрой партиционирование базы вместо диверсионного zabbix housekeeper

время записи возрастает не в 2 раза (как можно было бы предположить), а 20 раз!?

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

НО. боюсь что fio в твоих руках будет опасен (затрёт данные)

router ★★★★★
()
Ответ на: комментарий от gobot

Попробуйте со сбросом данных на диск скорость измерять
dd if=/dev/zero of=/tmp/output.img bs=8k count=100k iflag=sync

dd if=/dev/zero of=/tmp/output.img bs=8k count=200k iflag=sync

или
date;dd if=/dev/zero of=/tmp/output.img bs=8k count=100k ;sync;date

date;dd if=/dev/zero of=/tmp/output.img bs=8k count=200k ;sync;date

и по разнице времени и записанному объему посчитать скорость записи

хотя что это даст, если нужно понять почему iops ы жрет jbd2/md3-8 ...

Vlad-76 ★★★★
()
Последнее исправление: Vlad-76 (всего исправлений: 2)
Ответ на: комментарий от router

fail2ban ты отключил зря

перезагрузил

в этой mysql живёт zabbix? настрой партиционирование базы вместо диверсионного zabbix housekeeper

Я посмотрел mysql, там запросов почти нет, ну раз в 5 сек. пишет в insert into history ... Значит не в БД, а в самом zabbix что-то. Пока не понял что там

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

Хм, да не знаю. То есть когда записываешь 839 MB то часть записывается в кэш. А как узнать какой размер кэша у диска?

gobot ★★★★
() автор топика
Ответ на: комментарий от Vlad-76
dd if=/dev/zero of=/tmp/output.img bs=8k count=100k iflag=sync
838860800 bytes (839 MB, 800 MiB) copied, 0.805163 s, 1.0 GB/s
838860800 bytes (839 MB, 800 MiB) copied, 5.84178 s, 144 MB/s
838860800 bytes (839 MB, 800 MiB) copied, 9.44781 s, 88.8 MB/s
838860800 bytes (839 MB, 800 MiB) copied, 13.1449 s, 63.8 MB/s
838860800 bytes (839 MB, 800 MiB) copied, 4.94496 s, 170 MB/s



C 200K боюсь запускать, рухнет снова все. Ну да, понятно, что напрямую пишет намного медленнее

Скорость скачет ппц...и процесс jbd2/md3-8 под 99% IO

gobot ★★★★
() автор топика
Последнее исправление: gobot (всего исправлений: 1)

В общем что-то ненормальное с этим диском либо с настройками. Если тупо копировать файл гиговый в mc, iowait поднимается 20-50%, все виснет... (nginx не принимает запросы и т д). Хотя на другом сервере тоже с HDD таких проблем нет, но там raid0 стоит. Диск говно на выброс походу? Ничего не исправить?

gobot ★★★★
() автор топика
Ответ на: комментарий от gobot

сбойнул ли диск аппаратно, можно сказать после его диагностики
у Вас же два диска
iowait поднимается,возможно потому что с диском идет очень частый обмен мелкими блоками и он не успевает.

Vlad-76 ★★★★
()
Ответ на: комментарий от gobot

Можно писать на HDD большими блоками в один поток, а можно мелкими в несколько. Мелкие блоки от разных потоков (процессов) тяжелая нагрузка для диска - головки надо чаще в разные места позиционировать.
Поэтому параметр скорости линейного чтения/записи (утилита dd) это ни о чем.
Вот что пишут про iops ы
https://habr.com/ru/post/164325/

Vlad-76 ★★★★
()
Последнее исправление: Vlad-76 (всего исправлений: 2)
Ответ на: комментарий от gobot

swap я знаю что это, да он забит на 100%

Посмотри, какие процессы используют swap, например через smem. В свапе не должно быть никаких процессов, активно участвующих в работе сервера, иначе они будут адово тормозить

annulen ★★★★★
()
Ответ на: комментарий от firkax

Свап это не замена памяти, это аварийное хранилище чтобы сервер вместо того чтоб упасть просто начал лагать, дав тебе время исправить ситуацию с перерасходом.

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

annulen ★★★★★
()
Ответ на: комментарий от gobot

1. если диск сбоит аппаратно, то это может приводить к деградации производительности. имел ввиду тест аппаратный, все ли блоки читаются/пишутся,с какой скоростью, нет ли реаллокаций блоков и т.д.
можно утилитами c live образа windows strelec потестить

2. на мой взгляд число iops для железного диска в вашей системе превышено, ниже 100 (!!!) не опускается и достигает 400, то очевидно что надо искать процесс который через ядро и jbd2 «бомбит» iops ами диск.

Vlad-76 ★★★★
()

Я в своё время бился над чуть другой проблемой - мне нужно было обеспечить записиь трафика на диск без потерь.

Сброс кеша идет в две стадии. Одна, когда объём dirty_cache начал превышать vm.dirty_background_bytes, вторая стадия когда объём dirty_cache начал превышать vm.dirty_bytes

Первая стадия идет в фоне и не блокирует задачи, в во второй стадии начинаются блокировки приложений.

Смысл в том, что нужно начинать сбрасывать кеш не дожидаясь превышения dirty_bytes

Резкую запись на диск можно пережить (если оно влезает в кеш) задрав vm.dirty_bytes.

Значение FLOW 5000000 было выбрано эксперементально для потока в 50 мегабайт/с

FLOW=5000000
sysctl vm.dirty_background_bytes=$FLOW
sysctl vm.dirty_bytes=$[$FLOW*10]
sysctl vm.dirty_writeback_centisecs=300
sysctl vm.dirty_expire_centisecs=1200
sysctl vm.dirtytime_expire_seconds=3000
echo Result
sysctl vm 2>/dev/zero | grep dirty
echo 3 >/proc/sys/vm/drop_caches

Пока не заметил чтобы кто-то посоветовал посмотреть/поменять планировщик для диска. Для рейда из hdd это тоже может влиять.

Раз ты используешь виртуализацию, то тебе нужно настравить обе системы.

Учти, что виртуализация в виде kvm/qemu/virtbox - это источник непредсказуемых задержек.

Если архитектура хоста и гостя совпадает, то выброси виртуалку и воспользуйся lxc.

vel ★★★★★
()