Назад | Перейти на главную страницу

Значительное снижение производительности при постоянной последовательной записи

Я занимаюсь переносом данных в разделы LUKS. Теперь, когда диск с операционной системой работает с LUKS, я попытался начать перенос дисков с данными. Затем сервер перестал отвечать.

Это устройство LUKS было открыто:

cryptsetup luksOpen /dev/sdc data1

И любая из этих команд задушила сервер:

pv /dev/zero > /dev/mapper/data1
pv /dev/zero > /dev/sdc

Не сразу, а через несколько секунд сервер стал необычайно медленным. Все заблокировано на вводе / выводе:

root@node51 [~]# ps aux | awk '{if($8~"D"||$8=="STAT"){print $0}}' 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1197  0.0  0.0      0     0 ?        D    06:39   0:00 [jbd2/dm-1-8]
root      1687  0.1  0.0      0     0 ?        D    11:15   0:12 [kworker/u96:5]
root     13057  2.0  0.0      0     0 ?        D    13:10   0:01 [dmcrypt_write]
root     13644 10.9  0.0   7452   784 pts/1    D+   13:10   0:08 pv /dev/zero
root     14159  0.0  0.0  98256  6836 ?        DNs  13:10   0:00 sshd: root [priv]
root     14772  0.0  0.0  29008    92 ?        D    13:11   0:00 /usr/sbin/CRON -f
root     14773  0.0  0.0  98256  6748 ?        DNs  13:11   0:00 sshd: root [priv]
root     15411  0.0  0.0  98256  6876 ?        DNs  13:11   0:00 sshd: root [priv]
root     16009  0.1  0.0  98256  6840 ?        DNs  13:11   0:00 sshd: root [priv]
root     16632  0.5  0.0  98256  6892 ?        DNs  13:11   0:00 sshd: root [priv]
root     16900  0.0  0.0   5448   356 pts/3    D+   13:11   0:00 awk {if($8~"D"||$8=="STAT"){print $0}}
root     28553  0.6  0.0      0     0 ?        D    12:12   0:21 [txg_sync]

Следует отметить, что около двух секунд pv сообщил, что копирует данные более чем на 2GiB/s. Это и кеш обратной записи, и заполнение грязных страниц (обнаружено при мониторинге /proc/meminfo).

Впоследствии pv записал нормальный 200MiB/s скорость записи, но она все еще опережала 2GiB и 3GiB в кэше обратной записи.

Средняя нагрузка на сервер подскочила выше 10,00 из-за всей блокировки ввода-вывода.

Чтобы отменить pv тест записи, потому что кеш обратной записи необходимо очистить, но сразу после прерывания теста производительность сервера вернулась в норму.

Интересно, что эти команды не вызывают отставания сервера:

# Reads from dm-crypt block device
pv /dev/mapper/data1 > /dev/zero
# Reads from the raw block device
pv /dev/sdc > /dev/zero

# Writes to a control disk of a different model
pv /dev/zero > /dev/sdi
# Reads from a control disk
pv /dev/sdi > /dev/zero

# Writes to a file on a dm-crypt ext4 filesystem on a solid-state drive
pv /dev/zero > /tmp/empty
# Reads from that same solid-state drive
pv /dev/sda > /dev/zero

У меня такие вопросы:

  1. Почему продолжительная последовательная запись на этот диск с данными так сильно замедляет работу сервера?
  2. Как я могу избежать зависания других дисков при записи на один или несколько?
  3. Почему этот тип жесткого диска вызывает проблемы с производительностью, а другие - нет?

У меня шесть дисков одной модели (/dev/sdc, /dev/sdd, /dev/sde, /dev/sdf, /dev/sdg, и /dev/sdh) для шифрования, и в будущем у них будут рабочие нагрузки последовательной записи, поэтому я не хочу, чтобы сервер завис из-за этой проблемы.

Дополнительная информация

Краткие факты

Сервер: Dell PowerEdge T320

Ядро: Linux node51 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Операционная система: Ubuntu Server 16.04 LTS Xenial Xerus 64-разрядная.

Проблемный жесткий диск: Toshiba PH3500U-1I72

У меня есть шесть таких дисков, все заведомо исправные, я протестировал два из них и испытал падение производительности ввода-вывода на обоих серверах. Они читают и пишут в 200MiB/s около начала.

Контрольный (исправный) жесткий диск: Samsung SP1614C

Этот диск имеет устойчивую скорость записи 50MiB/s. Может быть, проблемный диск слишком быстрый?

Контроллер диска: Dell PERC H310

К этому контроллеру подключены два твердотельных диска и шесть проблемных жестких дисков, и все они передаются напрямую как AHCI. Управляющий диск подключается к порту SATA, встроенному в материнскую плату.

Планировщики ввода / вывода

root@node51 [/tmp]# tail -n +1 /sys/block/sd*/queue/scheduler 
==> /sys/block/sda/queue/scheduler <==
noop [deadline] cfq 

==> /sys/block/sdb/queue/scheduler <==
noop [deadline] cfq 

==> /sys/block/sdc/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdd/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sde/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdf/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdg/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdh/queue/scheduler <==
[noop] deadline cfq 

==> /sys/block/sdi/queue/scheduler <==
noop [deadline] cfq

Изменение планировщика /dev/sdc из noop к deadline не делает заметной разницы. Изменение планировщика на cfq Казалось, что задержка несколько уменьшилась, но операции ввода-вывода на других дисках по-прежнему страдали.

vm.dirty* параметры ядра

root@node51 [~]# sysctl -a | grep 'vm.dirty'
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200

Примеры обнаруженной медленности и регистрации в ней /var/log/syslog

Синхронизация группы транзакций ZFS:

May 11 19:28:44 node51 kernel: [ 4080.179688] INFO: task txg_sync:3179 blocked for more than 120 seconds.
May 11 19:28:44 node51 kernel: [ 4080.179905]       Tainted: P           O    4.4.0-22-generic #39-Ubuntu
May 11 19:28:44 node51 kernel: [ 4080.180110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 19:28:44 node51 kernel: [ 4080.180357] txg_sync        D ffff88060b68baa8     0  3179      2 0x00000000
May 11 19:28:44 node51 kernel: [ 4080.180362]  ffff88060b68baa8 ffff880616a96d00 ffff8806133ea940 ffff880603dc2940
May 11 19:28:44 node51 kernel: [ 4080.180366]  ffff88060b68c000 ffff880616ad6d00 7fffffffffffffff ffff88056cb8c508
May 11 19:28:44 node51 kernel: [ 4080.180368]  0000000000000001 ffff88060b68bac0 ffffffff818211f5 0000000000000000
May 11 19:28:44 node51 kernel: [ 4080.180372] Call Trace:
May 11 19:28:44 node51 kernel: [ 4080.180381]  [<ffffffff818211f5>] schedule+0x35/0x80
May 11 19:28:44 node51 kernel: [ 4080.180385]  [<ffffffff81824315>] schedule_timeout+0x1b5/0x270
May 11 19:28:44 node51 kernel: [ 4080.180390]  [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180395]  [<ffffffff810c33b2>] ? __wake_up_common+0x52/0x90
May 11 19:28:44 node51 kernel: [ 4080.180398]  [<ffffffff81820744>] io_schedule_timeout+0xa4/0x110
May 11 19:28:44 node51 kernel: [ 4080.180412]  [<ffffffffc05afbec>] cv_wait_common+0xbc/0x140 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180416]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 19:28:44 node51 kernel: [ 4080.180423]  [<ffffffffc05afcc8>] __cv_wait_io+0x18/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180487]  [<ffffffffc071320e>] zio_wait+0x10e/0x1f0 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180528]  [<ffffffffc069ce66>] dsl_pool_sync+0x2c6/0x430 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180573]  [<ffffffffc06b85b6>] spa_sync+0x366/0xb30 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180576]  [<ffffffff810abe52>] ? default_wake_function+0x12/0x20
May 11 19:28:44 node51 kernel: [ 4080.180623]  [<ffffffffc06c9a4a>] txg_sync_thread+0x3ba/0x630 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180669]  [<ffffffffc06c9690>] ? txg_delay+0x180/0x180 [zfs]
May 11 19:28:44 node51 kernel: [ 4080.180676]  [<ffffffffc05aae31>] thread_generic_wrapper+0x71/0x80 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180682]  [<ffffffffc05aadc0>] ? __thread_exit+0x20/0x20 [spl]
May 11 19:28:44 node51 kernel: [ 4080.180686]  [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 19:28:44 node51 kernel: [ 4080.180688]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 19:28:44 node51 kernel: [ 4080.180692]  [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 19:28:44 node51 kernel: [ 4080.180694]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0

журнал ext4:

May 11 20:46:46 node51 kernel: [ 6000.186474] INFO: task jbd2/dm-2-8:1148 blocked for more than 120 seconds.
May 11 20:46:46 node51 kernel: [ 6000.193164]       Tainted: P           O    4.4.0-22-generic #39-Ubuntu
May 11 20:46:46 node51 kernel: [ 6000.199950] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 11 20:46:46 node51 kernel: [ 6000.208323] jbd2/dm-2-8     D ffff88060a6e7c98     0  1148      2 0x00000000
May 11 20:46:46 node51 kernel: [ 6000.208330]  ffff88060a6e7c98 0000000000000246 ffff8806133eb700 ffff88060b561b80
May 11 20:46:46 node51 kernel: [ 6000.208333]  ffff88060a6e8000 ffff88060aeb68b8 ffff88060a6e7d88 ffff88060a6e7d70
May 11 20:46:46 node51 kernel: [ 6000.208336]  ffff88060b561b80 ffff88060a6e7cb0 ffffffff818211f5 ffff8805fd6af900
May 11 20:46:46 node51 kernel: [ 6000.208339] Call Trace:
May 11 20:46:46 node51 kernel: [ 6000.208355]  [<ffffffff818211f5>] schedule+0x35/0x80
May 11 20:46:46 node51 kernel: [ 6000.208361]  [<ffffffff812ea0e0>] jbd2_journal_commit_transaction+0x240/0x1870
May 11 20:46:46 node51 kernel: [ 6000.208365]  [<ffffffff810b6be1>] ? dequeue_entity+0x431/0xa80
May 11 20:46:46 node51 kernel: [ 6000.208368]  [<ffffffff810b774a>] ? dequeue_task_fair+0x51a/0x8a0
May 11 20:46:46 node51 kernel: [ 6000.208372]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208378]  [<ffffffff810ec5fe>] ? try_to_del_timer_sync+0x5e/0x90
May 11 20:46:46 node51 kernel: [ 6000.208381]  [<ffffffff812ef32a>] kjournald2+0xca/0x250
May 11 20:46:46 node51 kernel: [ 6000.208384]  [<ffffffff810c3a70>] ? wake_atomic_t_function+0x60/0x60
May 11 20:46:46 node51 kernel: [ 6000.208387]  [<ffffffff812ef260>] ? commit_timeout+0x10/0x10
May 11 20:46:46 node51 kernel: [ 6000.208391]  [<ffffffff810a0588>] kthread+0xd8/0xf0
May 11 20:46:46 node51 kernel: [ 6000.208394]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6000.208397]  [<ffffffff8182568f>] ret_from_fork+0x3f/0x70
May 11 20:46:46 node51 kernel: [ 6000.208399]  [<ffffffff810a04b0>] ? kthread_create_on_node+0x1e0/0x1e0
May 11 20:46:46 node51 kernel: [ 6292.776357] perf interrupt took too long (2539 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

Управляющий диск подключается к порту SATA, встроенному в материнскую плату.

Как уже говорилось, диски, на которых возникают проблемы с тайм-аутом очистки журнала, подключены к PERC, тому же контроллеру, к которому подключены «проблемные» Toshiba.

PERC 310 - это только базовая аппаратная рейд-карта. Его процессор, вероятно, легко перегружен, либо это, либо есть ошибка прошивки. Direct AHCI - не очень распространенное использование.

Я бы предположил, что IO блокируется на PERC, а не на ОС.

Я думаю, что ваш кеш записи слишком велик по сравнению со скоростью вашего блочного устройства. Я бы посоветовал следующее:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 20

Никогда не устанавливайте оба *_bytes и *_ratio потому что победит последний установленный. Кроме того, в некоторых версиях ядра Linux может быть ошибка, при которой установка *_ratio не работает по назначению. Я бы предложил использовать *_bytes каждый раз.

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

Это очень много для переваривания.

Вы используете ZFS, поэтому есть большая вероятность, что это проблема с дисками 5 ТБ в вашем пуле и, возможно, с настройкой вашего пула.

Это могут быть диски с размером сектора 4k, поэтому в настройках ZFS следует внести некоторые изменения, чтобы учесть это.

Можете ли вы предоставить свой df -h, fdisk -l, zpool list, zpool status -v и zfs list вывод?