Есть ли какое-либо решение для блокировки XFS в Linux?

По-видимому, существует известная проблема XFS, которая блокирует ядро / процессы и разлагает тома в условиях интенсивного трафика. Некоторые веб-страницы говорят об этом, но мне не удалось выяснить, какие страницы являются новыми и могут иметь решение.Есть ли какое-либо решение для блокировки XFS в Linux?

У развертывания моей компании есть Debian с ядром 3.4.107, xfsprogs 3.1.4 и большими массивами хранения. У нас есть большие данные (PB) и высокая пропускная способность (ГБ/с) с использованием async IO для нескольких больших томов. Мы постоянно испытываем эти непредсказуемые блокировки на нескольких системах. ядра журналы/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?

источник

2016-04-08 tktuserA

Дело в том, что с одной или двумя системами в лаборатории мы не можем даже воспроизвести проблему, но затем с тысячами в поле это продолжает происходить. – tktuserA

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

http://blog.ronnyegner-consulting.de/2011/10/13/info-task-blocked-for-more-than-120-seconds/

и здесь

http://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/

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

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

источник

2016-04-12 07:05:10 Harry

Благодарим вас за ответ. Мы на самом деле смотрел на это, и вот параметры, которые мы используем: vm.dirty_background_bytes = 0, vm.dirty_background_ratio = 5, vm.dirty_bytes = 0, vm.dirty_expire_centisecs = 3000, vm.dirty_ratio = 20, Vm. dirty_writeback_centisecs = 500. Проблема все еще встречается, и мы также видим ее, когда пропускная способность массива намного меньше максимальной. мы обычно имеем. Вот еще одна ссылка, которая говорит о проблеме: http://oss.sgi.com/archives/xfs/2014-08/msg00377.html Не удалось выяснить, есть ли решение. Есть ли у вас другие предложения? – tktuserA

Здесь есть несколько советов ... http://oss.sgi.com/archives/xfs/2014-08/msg00377.html Я думаю, вам нужно будет получить основные дампы и узнать, что говорит xfs_repair, т.е. он может намекнуть на то, что пошло не так. Также может быть хорошей идеей попасть в список рассылки xfs. – Harry

Кто-нибудь знает, если эта блокировка XFS была зафиксирована в 3.16?

Говорят, так что в A Short Guide to Kernel Debugging:

Поиск «XFS сращивания тупик» поворачивает вверх электронный поток из 2011, который описывает эту проблему. Тем не менее, деактивация исходного репозитория ядра показывает, что ошибка не была решена до апреля 2014 года (8d02076) для выпуска в Linux 3.16.

источник

2018-02-06 10:14:03 Armali

Есть ли какое-либо решение для блокировки XFS в Linux?

ответ

Смежные вопросы