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
