dovecot - Dec 2008 - freebsd 7, panics - kqueue?

Hi,

We have a issue with a server pretty much just running dovecot, there's
about 250gb of maildirs which has about 200 simultaneous connections to
it running on freebsd 7. The machine has stayed up for about 8 days before
it panics but sometimes panics after about 24 hours.

We are running a PAE kernel (with ULE scheduler) as the machine has 2 (4
core processors) and 8gb of ram, dovecot is compiled with kqueue support
which i suspect is causing the panics.  We are currently trying with a
GENERIC kernel to see if this addresses the issue but looking back through
the dovecot lists there seems to be some issue with kqueue, freebsd and
dovecot, i am tempted to simply disable kqueue in dovecot but am not sure
on the performance penalties.

Please see the freebsd pr for the kgdb dumps - for both dumps the current
process was imap, and the second one seemed to hint towards a problem with
kqueue but im not a c or kernel hacker:

http://www.freebsd.org/cgi/query-pr.cgi?pr=129550

--- snip of what i think is relevent from the dump ---

(kgdb) list *0xc04c4c4d
0xc04c4c4d is in knlist_remove_kq (/usr/src/sys/kern/kern_event.c:1615).
1610 if (!kqislocked)
1611 KASSERT((kn->kn_status & (KN_INFLUX|KN_DETACHED)) == KN_INFLUX,
1612 ("knlist_remove called w/o knote being KN_INFLUX or already
removed"));
1613 if (!knlislocked)
1614 knl->kl_lock(knl->kl_lockarg);
1615 SLIST_REMOVE(&knl->kl_list, kn, knote, kn_selnext);
1616 kn->kn_knlist = NULL;
1617 if (!knlislocked)
1618 knl->kl_unlock(knl->kl_lockarg);
1619 if (!kqislocked)
(kgdb)


mail# dovecot -n
# 1.1.7: /usr/local/etc/dovecot.conf
# OS: FreeBSD 7.0-RELEASE-p6 i386
ssl_cert_file: /etc/ssl/dovecot.pem
ssl_key_file: /etc/ssl/dovecot.pem
login_dir: /var/run/dovecot/login
login_executable: /usr/local/libexec/dovecot/imap-login
login_process_per_connection: no
login_processes_count: 20
login_max_processes_count: 256
login_max_connections: 512
max_mail_processes: 1024
verbose_proctitle: yes
first_valid_uid: 89
last_valid_uid: 89
first_valid_gid: 89
last_valid_gid: 89
mail_privileged_group: mail
imap_client_workarounds: delay-newmail outlook-idle netscape-eoh
tb-extra-mailbox-sep
auth default:
   passdb:
     driver: vpopmail
   userdb:
     driver: vpopmail

On Dec 12, 2008, at 4:01 PM, <mike-maillist at nux.co.uk>
<mike-maillist at nux.co.uk
 > wrote:
> i am tempted to simply disable kqueue in dovecot but am not sure
> on the performance penalties.
kqueue is used for two things:

1) As regular ioloop, replacing select/poll. Not using kqueue here  
shouldn't make pretty much any performance difference.

2) As file notifier. When IMAP client starts IDLE command, kqueue  
notifies Dovecot immediately when new files are added to maildir.  
Disabling kqueue here doesn't make the performance worse, but it  
causes delays when notifying client about new mails (0 sec -> max. 30  
sec by default - configurable).
> 0xc04c4c4d is in knlist_remove_kq (/usr/src/sys/kern/kern_event.c: 
> 1615).
I don't know much about FreeBSD kernel either, but yes that does look  
like kqueue code.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20081212/468974c6/attachment-0002.bin>

>> i am tempted to simply disable kqueue in dovecot but am not sure
>> on the performance penalties.
>
>kqueue is used for two things:
>1) As regular ioloop, replacing select/poll. Not using kqueue here  
>shouldn't make pretty much any performance difference.
>
>2) As file notifier. When IMAP client starts IDLE command, kqueue  
>notifies Dovecot immediately when new files are added to maildir.  
>Disabling kqueue here doesn't make the performance worse, but it  
>causes delays when notifying client about new mails (0 sec -> max. 30  
>sec by default - configurable).
>
>> 0xc04c4c4d is in knlist_remove_kq (/usr/src/sys/kern/kern_event.c: 
>> 1615).
>
>I don't know much about FreeBSD kernel either, but yes that does look  
>like kqueue code.
Thanks so much for such a quick reply, will recompile now without kqueue
as i dont think the 30sec delay in incomming mail is an issue at all,

Mike.