<br><br><div><span class="gmail_quote">On 9/26/06, <b class="gmail_sendername">Sunil Mushran</b> <<a href="mailto:Sunil.Mushran@oracle.com">Sunil.Mushran@oracle.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You may want to ping Novell to get the 1.2.3 drop of OCFS2. That's<br>because it is the latest and greatest.<br><br>Having said that we'll need more information. <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As in, what syscall did strace show as taking time.</blockquote><div><br> write() is extremely slow.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What is the memory usage like? cat /proc/meminfo, cat /proc/slabinfo<br>That is, under production load.</blockquote><div><br>unfortunately i have no information about the exact contents of the files you request, but I should say that memory and CPU usage was normal when the lockups happened.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="mailto:augustasg@gmail.com">augustasg@gmail.com</a> wrote:<br>> Hello,
<br>><br>> we are running SLES9 SP3 with OCFS2 for mailsystem. There are three<br>> nodes in the cluster with shared storage and OCFS2 filesystem on it.<br>> The filesystem is used for mailbox storage and is accessed by smtpd
<br>> ,pop3 and imap processes. The system works fine for a few hours but<br>> locks up so that the OCFS2 filesystem is accessed by mail system<br>> extremely slowly. It is possible to list the contents of the<br>
> filesystem or to change the directories, but mailsystem is working<br>> slowly. Tracing smtp processes with strace showed that mail is<br>> delivered to mailboxes but it is done in a speed of few kilobytes per<br>
> second.<br>> This lock up happens under heavier load when the cluster is in<br>> production use and when it happens only restart fixes the problem. The<br>> umounting of the OCFS2 filesystem is not possible even when all
<br>> process accessing it are killed. Currently mail system cluster is not<br>> used in production so we tried to do some tests, but we were not able<br>> to replicate the problem while sending several thousands of messages
<br>> to a single account.<br>> The only thing that comes in mind, that the filesystem locks in the<br>> case when a file (message) is access by smtp process and pop3 or imap<br>> process simultaniously when the processes are running on distinct
<br>> cluster nodes. This might happen because of lack of global knowledge<br>> of localy locked files among OCFS2 cluster nodes.<br>> Could this be true?<br>> And what other reasons might be there for the problem?
<br>> Any suggestions on solving the problem?<br>><br>> The system information follows:<br>> OS: Suse Linux Enterprise Server 9 Service Pack 3<br>> Mailbox format: Maildir<br>> SMTP daemon: Postfix (postfix-2.2.6-0.1
)<br>> OCFS2 version: 1.2.1<br>> Kernel Version: 2.6.5-7.276-smp<br>> Pop3 and imap daemon: Courier IMAP (courier-imap-4.1.0-1.suse910)<br>><br>> --<br>> Augustas Gutautas<br>> ------------------------------------------------------------------------
<br>><br>> _______________________________________________<br>> Ocfs2-users mailing list<br>> <a href="mailto:Ocfs2-users@oss.oracle.com">Ocfs2-users@oss.oracle.com</a><br>> <a href="http://oss.oracle.com/mailman/listinfo/ocfs2-users">
http://oss.oracle.com/mailman/listinfo/ocfs2-users</a><br>><br></blockquote></div><br><br clear="all"><br>-- <br>Augustas Gutautas