then It's vey probable that you filesystem is damaged. umount this drive and
pass a fsck ;)
----- Original Message -----
From: "a.h.s. boy (lists)" <spudli...@nothingness.org>
To: <courier-imap@lists.sourceforge.net>
Sent: Friday, January 01, 2010 8:51 PM
Subject: Re: [Courier-imap] imapd process CPU usage pegged at 100%
Thanks everyone for the insight -- I may well see if I can nudge this
particular user to archive older mail for the sake of efficiency, but I now
suspect that my server load issues may exist independent of this IMAP
problem. The IMAP debug logs (which leave something to be desired in the way
of timestamps) don't seem to indicate any radically unusual behavior, and
I'm having WORSE server load issues today than ever before, and it doesn't
even appear that this user has been checking his mail today.
My system clock, however, has been drifting at the rate of about 5
minutes/hour(!), so I'm beginning to suspect a hardware issue that no amount
of log comparisons would have indicated...
The saga continues, happy new year!
Cheers,
spud.
On Jan 1, 2010, at 10:38 AM, Steve Chupack wrote:
> In my personal experience, courier-imap begins to bog down as you start
> pushing 10K messages in the main inbox. And although you're seeing high
> CPU load, my guess is that disk IO is the true culprit. That has always
> been the limiting factor on my courier-imap servers. FYI, I'm using a
> Poweredge 2950 with 8 cores and 5, 10K rpm disks configured as RAID 10.
>
> I have some users with upwards of 50K messages in their inbox, and just
> one of those users can literally bring the server to a point of being
> unusable. And yes, I realize keeping that much mail in your main inbox is
> ludicrous. But it's hard to control user behavior. I find if I run a shell
> script that moves all mail older than X days out of Maildir/cur into an
> "archive" folder it dramatically increases performance. In fact, I'm
> thinking about automating this process for all my users.
>
> Maybe Sam can shed some light on this, but I also believe having multiple
> clients (especially a mix of IMAP and POP) simultaneously checking the
> same mailbox can also be taxing on the server. In fact, I have always
> believed that mixing IMAP and POP was a really bad idea, but that may just
> be superstition on my part.
>
>
>
> On Fri, 1 Jan 2010 00:19:40 +0100
> "Cosas Minovela" <co...@minovela.com> wrote:
>
>> Hi,
>>
>> This activity seems to be normal, and 7000 emails is not an enough
>> quantity
>> to increase so much the server load.
>>
>> Were these logs taken when this high server load?
>>
>> When some client does login, the first thing IMAP (or any pop3 client)
>> does
>> is to do an STATUS task, where it count how many emails there are to
>> download and then it moves all emails files from the "new" folder to the
>> "cur" folder. This is an intensive disk task. It's possible that your
>> disk
>> I/O activity and disk bandwith is already overloaded and the STATUS
>> command
>> on IMAP finally fill the whole disk bandwidth and consecuently, the
>> server
>> load.
>>
>> You could try to setup the mail server in a sepparate hard disk.
>>
>> Anyway let's wait for more answers ;)
>>
>> Iván López.
>> Logosur de Telecomunicación S.L.L.
>>
>> ----- Original Message -----
>> From: "a.h.s. boy (lists)" <spudli...@nothingness.org>
>> To: <courier-imap@lists.sourceforge.net>
>> Sent: Thursday, December 31, 2009 7:29 PM
>> Subject: [Courier-imap] imapd process CPU usage pegged at 100%
>>
>>
>>> Pardon the lengthy intro, but I'm trying to diagnose a problem where my
>>> Ubuntu (8.04) LAMP server suddenly started running amok, with both CPUs
>>> hitting 100% and the server load (which always hovered around .5)
>>> jumping
>>> up to 30...40...60. For the record, it has 3GB of RAM and is running in
>>> a
>>> virtual machine on pretty beefy hardware, with a fast connection.
>>>
>>> Two weeks ago, the load average had been climbing to 4 or 5 on occasion,
>>> and for the sake of keeping up on maintenance, I did an "apt-get
>>> dist-upgrade". This took the kernel to 2.6.24-26 (from 2.6.24-24),
>>> upgraded php5, apache, and some libraries. As far as I can tell, nothing
>>> specifically related to Courier/IMAP was upgraded, so in all fairness,
>>> Courier may not be responsible here at all, but...
>>>
>>> Almost immediately after the upgrade, my problems got worse, with load
>>> averages hitting as high as 110, and crippling the server to the point
>>> of
>>> requiring a cold reboot by my ISP. I removed a recently-added Drupal
>>> site
>>> (man those things make ridiculously inefficient use of MySQL!) in case
>>> it
>>> was the problem. Nope. I started logging slow MySQL queries (and
>>> no-index
>>> queries). A few, but nothing recurring or fitting the pattern of my
>>> woes.
>>>
>>> The one inexplicable anomaly that I've noticed concerns ONE of my mail
>>> users ("ent") under Postfix/Amavis/Courier-IMAP/Courier-POP3. He has a
>>> Blackberry, a home computer, and an office computer. Two of the devices
>>> connect via IMAP, and one via POP3. (Don't ask me why...I didn't set it
>>> up, I've just noticed it while debugging, but it may be relevant).
>>>
>>> While watching the output of htop, I noticed that a single process:
>>>
>>> /usr/bin/imapd [example.com]/ent
>>>
>>> would use 100% of the CPU for a rather extended period of time (several
>>> MINUTES). There seemed to be a possible correlation between this
>>> activity
>>> and my server getting stuck in the virtual mud.
>>>
>>> While this process was sitting there, I did
>>>
>>> strace -p[process_id]
>>>
>>> and saw an apparently-never-ending series of
>>>
>>> stat("./cur/1255433937.V801I1b84e5M930423.client1:2,S",
>>> {st_mode=S_IFREG|0600, st_size=2491, ...}) = 0
>>> readlink("./cur/1255433937.V801I1b84e5M930423.client1:2,S", 0x7c5d00,
>>> 256)
>>> = -1 EINVAL (Invalid argument)
>>> open("./cur/1255433937.V801I1b84e5M930423.client1:2,S",
>>> O_RDONLY|O_NONBLOCK) = 6
>>>
>>> for each piece of mail in his account (about 500MB).
>>>
>>> I finally added IMAPDEBUGFILE=imap_debug.log
>>>
>>> to the imapd configuration file, and got some output there as well. For
>>> his account, I would see:
>>>
>>> READ: ATOM: bhic
>>> READ: ATOM: UID
>>> READ: ATOM: FETCH
>>> READ: ATOM: 1:20012
>>> READ: LPAREN
>>> READ: ATOM: UID
>>> READ: ATOM: FLAGS
>>> READ: RPAREN
>>> READ: EOL
>>> WRITE: * 1 FETCH (UID 11915 FLAGS (\Seen))
>>> * 2 FETCH (UID 11916 FLAGS (\Seen))
>>> * 3 FETCH (UID 11917 FLAGS (\Seen))
>>> * 4 FETCH (UID 11918 FLAGS (\Seen))
>>> ...
>>> ... (Yes, almost 7000 of these!)
>>> ...
>>> * 6913 FETCH (UID 20010 FLAGS (\Seen))
>>> * 6914 FETCH (UID 20011 FLAGS (\Seen))
>>> * 6915 FETCH (UID 20012 FLAGS (\Seen))
>>> bhic OK FETCH completed.
>>> READ: ATOM: l
>>> READ: ATOM: LIST
>>> READ: QUOTED_STRING:
>>> READ: QUOTED_STRING: %.%
>>> READ: EOL
>>> READ: ATOM: 54ia
>>> READ: ATOM: NOOP
>>> READ: EOL
>>> WRITE: * LIST (\HasNoChildren) "." "INBOX.Sent - from Storm"
>>> * LIST (\HasNoChildren) "." "INBOX.Sent"
>>> * LIST (\HasNoChildren) "." "INBOX.Trash"
>>> * LIST (\HasNoChildren) "." "INBOX.Drafts"
>>> l OK LIST completed
>>>
>>> Unfortunately, I have no idea what "normal" output would look like, so
>>> I'm
>>> not sure how to interpret this output.
>>>
>>> Can anyone offer any insight as to whether or not this is normal
>>> behavior,
>>> a known problem, a misconfigured server, a misconfigured client, or
>>> what?
>>>
>>> Cheers, (and happy new year, grumble grumble)
>>> spud.
>>>
>>>
>>> -------------------------------------------------------------------
>>> a.h.s. boy
>>> spud(at)nothingness.org "as yes is to if,love is to yes"
>>> http://www.nothingness.org/
>>> -------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and
>>> easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Courier-imap mailing list
>>> Courier-imap@lists.sourceforge.net
>>> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Courier-imap mailing list
>> Courier-imap@lists.sourceforge.net
>> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Courier-imap mailing list
> Courier-imap@lists.sourceforge.net
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
-------------------------------------------------------------------
a.h.s. boy
spud(at)nothingness.org "as yes is to if,love is to yes"
http://www.nothingness.org/
-------------------------------------------------------------------
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Courier-imap mailing list
Courier-imap@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Courier-imap mailing list
Courier-imap@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
