全新的服务器,用于其潜力,cpu和磁盘方面的5%.
意味着它可能不会因为过载而崩溃.
每隔几天它就会在控制台日志中冻结数百条这样的消息:
: [284847.828428] INFO: task apache2:12473 blocked for more than 120 seconds.: [284847.868468] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.: [284847.912759] apache2 D ffff8101bc6b7ab0 0 12473 14358: [284847.912763] ffff810160d5bc50 0000000000000082 ffff8101c0002e40 0000000000000000: [284847.912766] ffff8101a7c42950 ffff810327d92810 ffff8101a7c42bd8 0000000400000044: [284847.912770] ffff8101c0002e40 00000000000612d0 0000000000000000 00000040000612d0: [284847.912773] Call Trace:: [284847.912786] [<ffffffff80429b0d>] __mutex_lock_slowpath+0x64/0x9b: [284847.912790] [<ffffffff80429972>] mutex_lock+0xa/0xb: [284847.912794] [<ffffffff802a20b9>] do_lookup+0x82/0x1c1: [284847.912800] [<ffffffff802a4271>] __link_path_walk+0x87a/0xd19: [284847.912805] [<ffffffff80295844>] kmem_getpages+0x96/0x15f: [284847.912808] [<ffffffff80295fb7>] ____cache_alloc_node+0x6d/0x106: [284847.912814] [<ffffffff802a4756>] path_walk+0x46/0x8b: [284847.912819] [<ffffffff802a4a82>] do_path_lookup+0x158/0x1cf: [284847.912822] [<ffffffff802a3879>] getname+0x140/0x1a7: [284847.912827] [<ffffffff802a53f1>] __user_walk_fd+0x37/0x4c: [284847.912831] [<ffffffff8029e381>] vfs_lstat_fd+0x18/0x47: [284847.912840] [<ffffffff8029e3c9>] sys_newlstat+0x19/0x31: [284847.912848] [<ffffffff8020beda>] system_call_after_swapgs+0x8a/0x8f
几乎所有跟踪都将__mutex_lock_slowpath作为顶级.
只有一些有不同的痕迹:
: [284847.737386] INFO: task apache2:12472 blocked for more than 120 seconds.: [284847.777551] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.: [284847.824881] apache2 D ffff8101bc6b7ab0 0 12472 14358: [284847.824886] ffff8101b9cc1c50 0000000000000086 ffffffffa0131e0a 0000000000000002: [284847.824889] ffff8102e7454300 ffff810324c6cad0 ffff8102e7454588 0000000000000000: [284847.824893] 0000000000000001 0000000000000296 0000000000000003 ffff8101b9cc1c58: [284847.824896] Call Trace:: [284847.828403] [<ffffffffa0131e0a>] :ext3:__ext3_journal_dirty_Metadata+0x1e/0x46: [284847.828412] [<ffffffff80429b0d>] __mutex_lock_slowpath+0x64/0x9b: [284847.828418] [<ffffffff80429972>] mutex_lock+0xa/0xb: [284847.828421] [<ffffffff802a20b9>] do_lookup+0x82/0x1c1: [284847.828427] [<ffffffff802a4271>] __link_path_walk+0x87a/0xd19: [284847.828428] [<ffffffff80271296>] find_lock_page+0x1f/0x8a: [284847.828428] [<ffffffff80273182>] filemap_fault+0x1c2/0x33c: [284847.828428] [<ffffffff802a4756>] path_walk+0x46/0x8b: [284847.828428] [<ffffffff802a4a82>] do_path_lookup+0x158/0x1cf: [284847.828428] [<ffffffff802a3879>] getname+0x140/0x1a7: [284847.828428] [<ffffffff802a53f1>] __user_walk_fd+0x37/0x4c: [284847.828428] [<ffffffff8029e381>] vfs_lstat_fd+0x18/0x47: [284847.828428] [<ffffffff8029e3c9>] sys_newlstat+0x19/0x31: [284847.828428] [<ffffffff8020beda>] system_call_after_swapgs+0x8a/0x8f kernel: [1912668.466347] INFO: task apache2:17984 blocked for more than 120 seconds. [1912668.507035] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.: [1912668.555165] apache2 D ffff8101c5637ba0 0 17984 17282: [1912668.596752] ffff810166a7dd30 0000000000000086 0000000000000000 ffff810166a7dcd8: [1912668.643341] ffff8101c563c880 ffff81024505f000 0000000000000002 ffff810166a7dd68: [1912668.699566] 0000000000000086 00000000000cb1a0 0000000000000000 ffff81017f344d60: [1912668.744773] Call Trace:: [1912668.761754] [<ffffffff8022a3ed>] pick_next_task_fair+0x6e/0x7a: [1912668.829311] [<ffffffff802be0e2>] bio_alloc_bioset+0x89/0xd9: [1912668.861930] [<ffffffff8024ac3a>] getnstimeofday+0x39/0x98: [1912668.897005] [<ffffffff802710f6>] sync_page+0x0/0x41: [1912668.927868] [<ffffffff80429487>] io_schedule+0x5c/0x9e: [1912668.960286] [<ffffffff80271132>] sync_page+0x3c/0x41: [1912668.991756] [<ffffffff804295fa>] __wait_on_bit_lock+0x36/0x66: [1912669.031757] [<ffffffff802710e3>] __lock_page+0x5e/0x64: [1912669.064191] [<ffffffff802461d3>] wake_bit_function+0x0/0x23: [1912669.100100] [<ffffffff80281bc5>] handle_mm_fault+0x5e4/0x8de: [1912669.134531] [<ffffffff802461a5>] autoremove_wake_function+0x0/0x2e: [1912669.174623] [<ffffffff802aa108>] fcntl_setlk+0x1cf/0x291: [1912669.210623] [<ffffffff802461a5>] autoremove_wake_function+0x0/0x2e: [1912669.246923] [<ffffffff802a677f>] sys_fcntl+0x280/0x2f7
在谷歌搜索“mutex_lock_slowpath”之后,我只能找到在某些提交中引入此问题的内核邮件列表讨论.不要参考verison.
讨论最近于2011年1月25日.
我使用的内核是Debian Lenny,一年前.
我该怎么办?这个BUG甚至在内核中修复了吗?如果它是如此明显的错误,为什么它很少发生?
>我应该从kernel.org下载最新的内核并进行升级吗?
>我应该使用Debian backports来安装新的“Approved”内核吗?
我错过了什么吗?该怎么办?
解决方法 您是否有机会使用SSD驱动器?我在Ubuntu 10.10系统上看到过这些错误.会发生什么事情会导致SATA故障完全搞乱磁盘子系统.对磁盘I / O的后续尝试将导致类似于您的120秒超时(堆栈跟踪变化.)
我在这里记录了原始问题:https://bugs.launchpad.net/ubuntu/+source/linux/+bug/707583
我询问有关超时的(有些蹩脚)问题是:Mystery stack traces in /var/log/messages
我使用的是基于P55的主板和Crucial SSD驱动器.但是,我已经看到这与其他芯片组,其他品牌的SSD驱动器和其他linux内核一起报道.
据我所知,唯一的共同点是使用SSD驱动器.
总结以上是内存溢出为你收集整理的Linux内核崩溃mutex_lock_slowpath“阻塞超过120秒”.该怎么办?全部内容,希望文章能够帮你解决Linux内核崩溃mutex_lock_slowpath“阻塞超过120秒”.该怎么办?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)