[Dovecot] What is normal CPU usage of dovecot imap?
I got Dual Core Intel Xeon CPU 3.00GHz, over 1000 mailbox and almost 1 dovecot login / second (peak time). Server stats says that load is continually over 2 and cpu usage is 60%. top says that imap is making this load. virtual users are in mysql database and mysqld is running on another server (this server is ok).
Do I need better CPU or is there something going on that I do not understand?
dovecot -n
1.1.11: /etc/dovecot/dovecot.conf
OS: Linux 2.6.32-4-pve i686 Ubuntu 9.10 nfs
log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s listen: *, [::] ssl_ca_file: /etc/ssl/**********.crt ssl_cert_file: /etc/ssl/**********.crt ssl_key_file: /etc/ssl/**********.key ssl_key_password: ********** disable_plaintext_auth: no verbose_ssl: yes shutdown_clients: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(pop3): no login_process_size: 128 login_processes_count: 10 login_max_processes_count: 2048 mail_max_userip_connections(default): 10 mail_max_userip_connections(imap): 10 mail_max_userip_connections(pop3): 3 first_valid_uid: 99 last_valid_uid: 100 mail_privileged_group: mail mail_location: maildir:/var/vmail/%d/%n:INDEX=/var/indexes/%d/%n fsync_disable: yes mail_nfs_storage: yes mbox_write_locks: fcntl mbox_min_index_size: 4 mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_process_size: 2048 mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): outlook-idle imap_client_workarounds(imap): outlook-idle imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls auth default: mechanisms: plain login cram-md5 cache_size: 1024 passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: static args: uid=99 gid=99 home=/var/vmail/%d/%n allow_all_users=yes socket: type: listen client: path: /var/spool/postfix/private/auth-client mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail
On 3.1.2012, at 16.54, Mikko Lampikoski wrote:
I got Dual Core Intel Xeon CPU 3.00GHz, over 1000 mailbox and almost 1 dovecot login / second (peak time). Server stats says that load is continually over 2 and cpu usage is 60%. top says that imap is making this load.
You mean an actual "imap" process? Or more than one imap processes? Or something else, e.g. "imap-login" process? If there's one long running IMAP process eating CPU, it might have simply gone to an infinite loop, and upgrading could help.
virtual users are in mysql database and mysqld is running on another server (this server is ok).
Do I need better CPU or is there something going on that I do not understand?
Your CPU usage should probably be closer to 0%.
login_process_size: 128 login_processes_count: 10 login_max_processes_count: 2048
Switching to http://wiki2.dovecot.org/LoginProcess#High-performance_mode may be helpful.
mail_nfs_storage: yes
Do you have more than one Dovecot server? This setting doesn't anyway work reliably. If you've only one server accessing mails, you can set this to "no".
On 3.1.2012, at 17.12, Timo Sirainen wrote:
On 3.1.2012, at 16.54, Mikko Lampikoski wrote:
I got Dual Core Intel Xeon CPU 3.00GHz, over 1000 mailbox and almost 1 dovecot login / second (peak time). Server stats says that load is continually over 2 and cpu usage is 60%. top says that imap is making this load.
You mean an actual "imap" process? Or more than one imap processes? Or something else, e.g. "imap-login" process? If there's one long running IMAP process eating CPU, it might have simply gone to an infinite loop, and upgrading could help.
It is "imap" process and process takes cpu like 10-30 seconds and then PID changes to another imap process (process also takes 10% of memory = 150MB). Restarting dovecot does not help.
virtual users are in mysql database and mysqld is running on another server (this server is ok). Do I need better CPU or is there something going on that I do not understand?
Your CPU usage should probably be closer to 0%.
I think so too, but I ran out of good ideas. If someone have lots of mails in mailbox can it make effect like this?
login_process_size: 128 login_processes_count: 10 login_max_processes_count: 2048
Switching to http://wiki2.dovecot.org/LoginProcess#High-performance_mode may be helpful.
This loses much of the security benefits, no thanks.
mail_nfs_storage: yes
Do you have more than one Dovecot server? This setting doesn't anyway work reliably. If you've only one server accessing mails, you can set this to "no".
Trying this too, but I think its not going to help..
On 3.1.2012, at 17.38, Mikko Lampikoski wrote:
On 3.1.2012, at 17.12, Timo Sirainen wrote:
On 3.1.2012, at 16.54, Mikko Lampikoski wrote:
I got Dual Core Intel Xeon CPU 3.00GHz, over 1000 mailbox and almost 1 dovecot login / second (peak time). Server stats says that load is continually over 2 and cpu usage is 60%. top says that imap is making this load.
You mean an actual "imap" process? Or more than one imap processes? Or something else, e.g. "imap-login" process? If there's one long running IMAP process eating CPU, it might have simply gone to an infinite loop, and upgrading could help.
It is "imap" process and process takes cpu like 10-30 seconds and then PID changes to another imap process (process also takes 10% of memory = 150MB). Restarting dovecot does not help.
Is the IMAP process always for the same user (or the same few users)? verbose_proctitle=yes shows the username in ps output.
If someone have lots of mails in mailbox can it make effect like this?
Possibly. maildir_very_dirty_syncs=yes is helpful with huge maildirs (I don't remember if it exists in v1.1 yet).
participants (2)
-
Mikko Lampikoski
-
Timo Sirainen