Re: [webmin-l] High I/O usage issues which may be related to Usermin...

[Jesse C. S. <jsm...@ga...>]

Currently I'm using Sendmail with the mbox format.  What you say does 
make sense though.  Towards the end of the year I did notice our email 
traffic increasing so it would be only reasonable that the old way of 
doing things could cause us issues with incoming mail on the rise.

Doing a quick search on google I noticed that doing Maildir shouldn't be 
a huge problem with some minor mods to promailrc.  However what I don't 
understand is does that mean new mail goes into 
/var/spool/mail/username/<messages here> or would it be 
~username/mail/inbox/<messages here>?

Lastly, as far as the conversion is usermin cabable of reading two 
different formats at a time?  I ask because I wonder can I just convert 
say all the inboxs first, wait to see what it does, and then convert all 
of their personal folders.  Or do I need to do both sides of the puzzle 
at the same time?

We currently are using Dovecot for the Pop3 / Imap side of things and it 
appears to be really easy to convert to the different setting.

Thanks Jaime, bTw.
-Jesse


Jamie Cameron wrote:
> On 6/Oct/2006 12:06 Jesse C. Smillie wrote ..
>   
>> Hello once again everyone.  Since the new school year started we have 
>> been noticing increasingly high I/O usage on our servers.  When I run 
>> the top command quite often you will see the WA status swing from really
>> low up into the 70-80 even 90% range for up to a min and then drop 
>> again.  I spend a little time trying to track down the problem and have
>> noticed the following:
>>
>> When I/O is really high I always see the following line in "ps aux | 
>> grep D":
>> 1229     14619  0.8  0.2  37272 16520 ?        D    14:43   0:00 
>> /usr/local/usermin-1.230/mailbox/delete_mail.cgi
>>
>> (Note: User ID is normally not the same one when polled)
>>
>> Sometimes I also see the index.cgi file too, but no where near as much
>> as the above.
>>
>> A coworker in our department had made mention that maybe whats happening
>> has something do with the process that usermin uses to remove mail from
>> a mailbox when its deleted.  Something about compacting the box during
>> the delete instead of doing it like Thunderbird and waiting to compact
>> until space can be saved.   I guess case being all the reading and 
>> rewriting required to removed the dead message from the box.
>>
>> I don't recall having this problem that bad last year.  On occassion 
>> when almost everyone was logged in things would get a little screwy, but
>> not like this.
>>
>> General information about our config:
>> Server:
>> Processors: Dual Opteron 242's
>> Ram: 6Gig ECC DDR
>> HDs: 1.2 TB 3ware Raid Array
>> OS: Slamd 64 10.2b (Slackware more or less)
>> Kernel: 2.6.18
>> Usermin Version: 1.230 (This was happening in the last version too 
>> however.  I just upgraded two days ago to see if the problem went away)
>>
>> Unfortunately dealing with I/O problems isn't my speciality so I could
>> be barking up the wrong tree here.  Any suggestions would be greatly 
>> appriciated as always...
>>     
>
> What format are your mailboxes in? If they are in mbox format (one file per
> user), when Usermin deletes email it will re-write out the entire mail
> file with the removed emails taken out. As you might expect, this could cause
> substantial disk IO on large mail files..
>
> The solution I used was to switch to Maildir format, in which each email is stored
> in a separate file. Deleting from this format is much quicker..
>
>  - Jamie
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> -
> Forwarded by the Webmin mailing list at web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>
> -------------------------------------------------------------
> This mail was scanned by a trial version of BitDefender
> For more informations please visit http://www.bitdefender.com
>
>
> -------------------------------------------------------------
>