Есть ли решение для блокировки XFS в Linux?
Очевидно, существует известная проблема блокировки XFS ядра / процессов и повреждения томов в условиях интенсивного трафика. Об этом говорят некоторые веб-страницы, но я не смог выяснить, какие страницы являются новыми и могут иметь решение.
У моей компании есть Debian с ядром 3.4.107, xfsprogs 3.1.4 и большими массивами хранения. У нас есть большие данные (PB) и высокая пропускная способность (ГБ / с) с использованием асинхронного ввода-вывода для нескольких больших томов. Мы постоянно испытываем эти непредсказуемые блокировки в нескольких системах. Журналы ядра /dmesg показывают что-то вроде следующего:
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986515] INFO: task Sr2dReceiver-5:46829 blocked for more than 120 seconds.
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986518] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986520] Sr2dReceiver-5 D ffffffff8105b39e 0 46829 7284 0x00000000
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986524] ffff881e71f57b38 0000000000000082 000000000000000b ffff884066763180
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986529] 0000000000000000 ffff884066763180 0000000000011180 0000000000011180
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986532] ffff881e71f57fd8 ffff881e71f56000 0000000000011180 ffff881e71f56000
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986536] Call Trace:
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986545] [<ffffffff814ffe9f>] schedule+0x64/0x66
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986548] [<ffffffff815005f3>] rwsem_down_failed_common+0xdb/0x10d
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986551] [<ffffffff81500638>] rwsem_down_write_failed+0x13/0x15
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986555] [<ffffffff8126b583>] call_rwsem_down_write_failed+0x13/0x20
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986558] [<ffffffff814ff320>] ? down_write+0x25/0x27
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986572] [<ffffffffa01f29e0>] xfs_ilock+0xbc/0x12e [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986580] [<ffffffffa01eec71>] xfs_rw_ilock+0x2c/0x33 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986586] [<ffffffffa01eec71>] ? xfs_rw_ilock+0x2c/0x33 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986593] [<ffffffffa01ef234>] xfs_file_aio_write_checks+0x41/0xfe [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986600] [<ffffffffa01ef358>] xfs_file_buffered_aio_write+0x67/0x179 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986603] [<ffffffff8150099a>] ? _raw_spin_unlock_irqrestore+0x30/0x3d
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986611] [<ffffffffa01ef81d>] xfs_file_aio_write+0x163/0x1b5 [xfs]
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986614] [<ffffffff8106f1af>] ? futex_wait+0x22c/0x244
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986619] [<ffffffff8110038e>] do_sync_write+0xd9/0x116
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986622] [<ffffffff8150095f>] ? _raw_spin_unlock+0x26/0x31
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986634] [<ffffffff8106f2f1>] ? futex_wake+0xe8/0xfa
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986637] [<ffffffff81100d1d>] vfs_write+0xae/0x10a
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986639] [<ffffffff811015b3>] ? fget_light+0xb0/0xbf
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986642] [<ffffffff81100dd3>] sys_pwrite64+0x5a/0x79
2016 Mar 24 04:42:34 hmtmzhbgb01-ssu-1 kernel: [2358750.986645] [<ffffffff81506912>] system_call_fastpath+0x16/0x1b
Блокировки оставляют систему в плохом состоянии. Процессы в состоянии D, которые зависают, даже не могут быть прерваны сигналом 9. Единственный способ возобновить операции - это перезагрузить компьютер, восстановить XFS, а затем система будет работать еще некоторое время. Но иногда после блокировки мы не можем даже восстановить некоторые тома, так как они полностью повреждены, и нам нужно восстановить их с помощью mkfs.
В качестве последнего средства мы теперь периодически запускаем xfs-repair, и это в некоторой степени снижает частоту блокировок и потери данных. Но инциденты все еще происходят достаточно часто, поэтому нам нужно какое-то решение.
Мне было интересно, есть ли решение для этого с ядром 3.4.107, например, какой-нибудь патч, который мы можем применить. Из-за большого количества развертываний и других проблем с программным обеспечением мы не сможем обновить ядро в ближайшем будущем.
Однако мы работаем над обновлением наших приложений, чтобы мы могли работать на ядре 3.16 в наших следующих выпусках. Кто-нибудь знает, была ли эта проблема блокировки XFS была исправлена в 3.16?
2 ответа
Кто-нибудь знает, была ли эта проблема блокировки XFS была исправлена в 3.16?
Об этом говорится в Кратком руководстве по отладке ядра:
Поиск "xfs splice deadlock" приводит к появлению в 2011 году цепочки писем, в которой описана эта проблема. Однако разделение репозитория исходного кода ядра показывает, что ошибка не была устранена до апреля 2014 г. (8d02076) для выпуска в Linux 3.16.
Некоторые люди сталкивались с этим, но это не было проблемой с XFS, потому что ядро не могло сбрасывать грязные страницы в течение периода 120 с. Посмотрите здесь, но, пожалуйста, проверьте номера, которые они используют по умолчанию в вашей собственной системе.
http://blog.ronnyegner-consulting.de/2011/10/13/info-task-blocked-for-more-than-120-seconds/
и здесь
Вы можете увидеть, что вы грязный коэффициент кэша, запустив этот
sysctl -a | grep dirty
или же
cat /proc/sys/vm/dirty_ratio
Лучшее, что я могу найти, можно найти здесь...
https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/
По сути, вам необходимо настроить приложение так, чтобы оно могло записывать грязные буферы на диск в течение определенного периода времени или изменять период таймера и т. Д.
Вы также можете увидеть некоторые интересные параметры следующим образом
sysctl -a | grep hung
Вы можете увеличить время ожидания постоянно, используя /etc/sysctl.conf следующее...
kernel.hung_task_timeout_secs = 300