symptoms:
1. Coming back to the idle client, and clicking on a newly arrived
message, often a long delay (seems like minutes, sometimes) will
occur before the message loads from the server.
2. Sending messages, as often as not, the client will stall,
sometimes indefinitely, on "copying message to sent folder".
Does this happen when using a client which is on the same LAN as
the server? This kind of behavior looks like a network issue.
You called it. We access the server over the Internet. How did I forget to
provide that small detail? However, that's not the slowness I speak of.
Perhaps a better term is long delay, like waiting on some timeout, before
message loadding (in symptom 1., above).
So are there parameters to tune, that will make dovecot behave nicer? I do not
believe this to be connectivity outages between our clients and the server.
For one, we never experienced these symptoms with UW-IMAP.
I just duplicated the stall on copying to Sent folder. This is probably the
more prevalent, and annoying of the two problems.
facts:
* There was only one active client.
* The client was T'bird, v1.5.0.10, running on XP.
* This particular test had a 3Mb attachment.
* The mail was delivered immediately to the single, remote recipient (after a
~20 seconds of 3Mb upload).
* The "Copying to Sent Folder" dialog stayed up for (no exaggeration)
15-minutes, and then completed; the message is in the Sent folder now.
suspicion, from months of experiencing the behavior:
* Attachments are usually involved.
How does the config look? Are the mbox lock settings appropriate? I was
somewhat shooting in the dark there.
* Sendmail 8.13.6/8.13.6
* $sudo sendmail -bt -d0.10 < /dev/null | grep HASFLOCK
OS Defines: BSD4_4_SOCKADDR HASFCHOWN HASFCHMOD HASFLOCK
mbox_read_locks = flock
mbox_write_locks = flock
What else can I provide? netstats? tcpdumps? Are there logs/debugging
appropriate to enable?
Thanks for any ideas, Danno
