The last statement about how it happens only on one of the partitions is what intrigues me. How old are each of these partitions? What are the usage patterns / rates of each partition? (Relative to one another..as in does one get heavier use?) I'm wondering if you are seeing what I see here... http://www.mail-archive.com/ocfs2-users at oss.oracle.com/msg05306.html At 02:00 PM 4/8/2012, ocfs2-users-request at oracle.com wrote:>Date: Sun, 8 Apr 2012 10:54:52 -0700 >From: Jay V <jvasaoo at gmail.com> >Subject: Re: [Ocfs2-users] OCFS2 performance and debug help >To: Adelino Monteiro <adelino.monteiro at gmail.com> > >I have a similar blocking/hanging/stall issue. On Oracle 6.2/x64. We >are running OCFS2 on 3 partitions about 14-15TB each. One of the >partitions has been running extremely slowly too. They are running on >the same hardware-- LSI HW Raid Cards and Enterprise Drives. I am >running over drbd and nfsd. > >I am getting really slow performance in writes.?The process >[jbd2-drbd-18] seems to be stuck for a long length of time (about 2 >minutes) before it finally commits. This jbd2-drbd2 prevents any other >writes from happening which stalls the system. >This would be from "ps auxr" >USER?????? PID %CPU %MEM??? VSZ?? RSS TTY????? STAT START?? TIME COMMAND >root????? 6374? 0.0? 0.0????? 0???? 0 ???????? D??? Apr03?? 0:28 >[jbd2/drbd2-18] >root????? 6876? 0.0? 0.0????? 0? ???0 ???????? D??? Apr06?? 0:11 [nfsd] >root????? 6884? 0.0? 0.0????? 0???? 0 ???????? D??? Apr06?? 0:09 [nfsd] >root????? 6999? 0.0? 0.0????? 0???? 0 ???????? D??? Apr06?? 0:45 [nfsd] >root????? 7046? 0.0? 0.0????? 0???? 0 ???????? D??? Apr06?? 0:09 [nfsd] >root????? 7053? 0.0? 0.0????? 0???? 0 ???????? D??? Apr06?? 0:09 [nfsd] >root????? 7054? 0.0? 0.0????? 0???? 0 ???????? D??? Apr06?? 0:08 [nfsd] > >Running "scan_locks2" shows nothing. Nothing is held up locking wise. >It seems to happen more with files copying about 1MB or larger. It >only happens for me on my second partition, but not the other 2. It >seems to super slow in writes. Reads are fast. > >I hope to find a solution quickly too. I wonder it is because we have >very large partitions. > >Thanks, Jay