Gibt es eine Lösung für das XFS-Lockup in Linux?

Anscheinend gibt es ein bekanntes Problem von XFS, das den Kern/die Prozesse sperrt und Volumes unter starkem Verkehr korrumpiert. Einige Webseiten sprechen darüber, aber ich konnte nicht herausfinden, welche Seiten neu sind und möglicherweise eine Lösung haben.Gibt es eine Lösung für das XFS-Lockup in Linux?

Die Bereitstellungen meines Unternehmens haben Debian mit Kernel 3.4.107, xfsprogs 3.1.4 und große Speicher-Arrays. Wir haben große Daten (PB) und hohen Durchsatz (GB/s) mit Async IO zu mehreren großen Volumes. Wir erleben ständig diese unvorhersehbaren Sperren auf mehreren Systemen. Kernel-Logs/dmesg zeigt in etwa wie folgt:

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

Abstürze lassen Sie das System in einem schlechten Zustand. Die Prozesse im D-Zustand, die hängen, können nicht einmal mit Signal 9 beendet werden. Die einzige Möglichkeit, den Betrieb wiederaufzunehmen, besteht darin, neu zu starten, XFS zu reparieren, und dann funktioniert das System eine weitere Weile. Aber manchmal nach der Sperrung können wir nicht einmal einige Volumes reparieren, da sie komplett beschädigt sind und wir sie mit mkfs neu aufbauen müssen.

Als letzten Ausweg führen wir xfs-repair regelmäßig aus, wodurch die Häufigkeit von Blockierungen und Datenverlusten in gewissem Umfang reduziert wurde. Aber die Vorfälle treten immer noch oft genug auf, also brauchen wir eine Lösung.

Ich frage mich, ob es eine Lösung dafür mit Kernel 3.4.107, z. ein Patch, den wir anwenden können. Aufgrund der großen Anzahl von Bereitstellungen und anderer Softwareprobleme können wir den Kernel in naher Zukunft nicht aktualisieren.

Wir arbeiten jedoch daran, unsere Anwendungen zu aktualisieren, damit wir in unseren nächsten Releases unter Kernel 3.16 laufen können. Weiß jemand, ob dieses XFS-Lockup-Problem in 3.16 behoben wurde?

Quelle

2016-04-08 tktuserA

Die Sache ist, dass mit ein oder zwei System im Labor wir nicht einmal das Problem reproduzieren können, aber dann mit Tausenden im Feld geschieht dies weiter. – tktuserA

Einige Leute haben dies erlebt, aber es war kein Problem mit XFS, weil der Kernel nicht in der Lage war, die verschmutzten Seiten innerhalb der 120er Zeit zu löschen. Sehen Sie hier nach, aber überprüfen Sie bitte die Nummern, die sie standardmäßig auf Ihrem eigenen System verwenden.

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

und hier

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

Sie sehen können, was Sie Dirty-Cache-Verhältnis sind, ist durch dieses

läuft

sysctl -a | grep dirty

oder

cat /proc/sys/vm/dirty_ratio

Die beste Bewertung zu diesem bis ich hier finden konnten, ist ...

https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

Im Wesentlichen müssen Sie Ihre Anwendung abzustimmen, um sicherzustellen, dass es die schmutzigen Puffer auf die Festplatte innerhalb des Zeitraums oder zu ändern schreiben die Zeitperiode usw.

können Sie auch einige interessante Paramater sehen wie

sysctl -a | grep hung

folgt Sie den Timeout permanent /etc/sysctl.conf mit erhöhen könnte als folgt ...

kernel.hung_task_timeout_secs = 300

Quelle

2016-04-12 07:05:10 Harry

Danke für die Antwort. Wir hatten tatsächlich in diese sah und hier sind die Parameter, die wir verwenden: 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. Das Problem tritt immer noch auf, und wir sehen es auch, wenn der Array-Durchsatz weit unter dem Maximum liegt. wir haben normalerweise. Hier ist ein weiterer Link, der über das Problem spricht: http://oss.sgi.com/archives/xfs/2014-08/msg00377.html Konnte nicht herausfinden, ob es eine Lösung gibt. Hättest du noch andere Vorschläge? – tktuserA

Es gibt ein paar Hinweise hier ... http://oss.sgi.com/archives/xfs/2014-08/msg00377.html Ich denke, Sie müssen Core Dumps bekommen und herausfinden, was xfs_repair sagt, dh es könnte darauf hinweisen, was falsch gelaufen ist. Es könnte auch eine gute Idee sein, auf die xfs Mailingliste zu gelangen. – Harry

Weiß jemand, ob dieses Problem XFS Überbrückungs in 3,16 festgelegt wurde?

Es wird gesagt, so in A Short Guide to Kernel Debugging:

Suche nach „xfs Spleiß Deadlock“ wird eine E-Mail-Thread ab 2011 bis die dieses Problem beschreibt. Die Zweiteilung des Kernel-Quell-Repository zeigt jedoch, dass der Fehler erst im April 2014 (8d02076) für die Veröffentlichung in Linux 3.16 behoben wurde.

Quelle

2018-02-06 10:14:03 Armali

Gibt es eine Lösung für das XFS-Lockup in Linux?

Antwort

Verwandte Themen