BUG: 764964 (dead lock)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, 

I am using gluster in physical machine (CPU: 2 Xeon E5620, MEM: 24GB, 1Gpbs network link, Centos 6.0 linux 2.6.32-71.el6.x86_64).  When reading or writing small numbers of files, the system is fine. But when too many files are accessing concurrently, the problem will occure some times.  After disabling THP entirely: 
echo never> /sys/kernel/mm/redhat_transparent_hugepage/enabled
It seems that the problem is resolved. I will continue to test it and see the results.

Thank,
yaodong

> -----????-----
> ???: "Bryan Whitehead" <driver at megahappy.net>
> ????: 2012?5?11? ???
> ???: chyd <chyd at ihep.ac.cn>
> ??: gluster-users <gluster-users at gluster.org>
> ??: Re: BUG: 764964 (dead lock)
> 
> Can you explain where glusterfs is being used? Is this lockup
> happening on a VM running in on a file-disk-image on top of gluster?
> is gluster itself causing this timeout?
> 
> On Wed, May 9, 2012 at 6:59 PM, chyd <chyd at ihep.ac.cn> wrote:
> > Hi all,
> >
> > I'm encountering a lockup problem many times when reading/writing large
> > numbers of files. I cannot break out of the race in gdb, a ps will lock up
> > when it tries to read that process' data, df (of course) locks up. No kill
> > signals have any effect. Except 'pidstat -p ALL' can get the pid, I could't
> > do anything. The only way out of it is to umount -f.
> > I am using gluster 3.2.6 on CentOS 6.0 (2.6.32-71.el6.x86_64).
> >
> > The problem is the same as BUG 764964
> > (https://bugzilla.redhat.com/show_bug.cgi?id=764964). and it is difficult to
> > duplicate, I am find a way to produce it quickly. Any one else also
> > encountered this problem? How do you solve it?
> >
> > Attached dmesg log:
> > May 10 00:01:52 PPC-002 kernel: INFO: task glusterfs:27888 blocked for more
> > than 120 seconds.
> > May 10 00:01:52 PPC-002 kernel: "echo 0 >
> > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > May 10 00:01:52 PPC-002 kernel: glusterfs????????? D ffff88033fc24b00???? 0
> > 27888????? 1 0x00000080
> > May 10 00:01:52 PPC-002 kernel: ffff8806310fbe48 0000000000000086
> > 0000000000000000 ffff8806310fbc58
> > May 10 00:01:52 PPC-002 kernel: ffff8806310fbdc8 0000000000020010
> > ffff8806310fbee8 00000001021f184a
> > May 10 00:01:52 PPC-002 kernel: ffff8806311a0678 ffff8806310fbfd8
> > 0000000000010518 ffff8806311a0678
> > May 10 00:01:52 PPC-002 kernel: Call Trace:
> > May 10 00:01:52 PPC-002 kernel: [<ffffffff814ca6b5>]
> > rwsem_down_failed_common+0x95/0x1d0
> > May 10 00:01:52 PPC-002 kernel: [<ffffffff814ca813>]
> > rwsem_down_write_failed+0x23/0x30
> > May 10 00:01:52 PPC-002 kernel: [<ffffffff81264253>]
> > call_rwsem_down_write_failed+0x13/0x20
> > May 10 00:01:52 PPC-002 kernel: [<ffffffff814c9d12>] ? down_write+0x32/0x40
> > May 10 00:01:52 PPC-002 kernel: [<ffffffff8113b468>] sys_munmap+0x48/0x80
> > May 10 00:01:52 PPC-002 kernel: [<ffffffff81013172>]
> > system_call_fastpath+0x16/0x1b
> >
> > Thank you in advance.
> > Yaodong
> >
> > 2012-05-10
> > ________________________________
> >
> > _______________________________________________
> > Gluster-users mailing list
> > Gluster-users at gluster.org
> > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
> >



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux