Re: [courier-users] Slow Copies with Courier-Imap
Gordon Messmer wrote: On 06/09/2009 01:51 PM, Alexander M Thompson wrote: The only problem is, it seems like Copy operations are very slow for the first 30-45 seconds of a given imap session, sometimes to the point where you only can do one operation before it gets better (i.e. copying a small mail to the sent folder takes 30 seconds). ... You do realize that copying a message to the sent folder will cause thunderbird to initiate a new connection, right? If the first copy operation has a long delay and subsequent copy operations do not, then you're probably seeing general connection delays. Check TCPDOPTS in imapd, and add -nodnslookup -noidentlookup if they're not present. I'd checked all that previously, the connection completes successfully and starts issuing imap commands before pausing. I've gone so far as to truss the imapd process on a test server while one of the people experiencing the problem used it. What I found is disheartening to say the least: PID TIMESTAMP SYSCALL = RETURN CODE 26243: 173.5222openat(-3041965, ./.Sent/cur, O_RDONLY|O_NDELAY|O_LARGEFILE) = 7 26243: 173.5223fcntl(7, F_SETFD, 0x0001) = 0 26243: 173.5223fstat64(7, 0x08042420) = 0 26243: 173.8125getdents64(7, 0xFEF64000, 8192) = 7824 26243: 173.9659getdents64(7, 0xFEF64000, 8192) = 7776 26243: 174.0832getdents64(7, 0xFEF64000, 8192) = 7776 (Lots and lots of getdents64 [get directory entries] calls, enumerating every file in ./.Sent/cur) 26243: 214.3709getdents64(7, 0xFEF64000, 8192) = 7792 26243: 214.3973getdents64(7, 0xFEF64000, 8192) = 480 26243: 214.3975getdents64(7, 0xFEF64000, 8192) = 0 For whatever reason, courier is enumerating every single file in .Sent/cur and doing *something*, an operation that takes about 41 seconds in this case. Again, this only happens once per connection or so, so it must be putting it all into a hash table for future use... or something. But it's doing this before telling the client it has completed the copy operation (which it has, I can tell from the truss output). I'm truly at a loss as to how I could fix this behavior. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Slow Copies with Courier-Imap
On 06/11/2009 10:44 AM, Alexander M Thompson wrote: I'd checked all that previously, the connection completes successfully and starts issuing imap commands before pausing. I've gone so far as to truss the imapd process on a test server while one of the people experiencing the problem used it. What I found is disheartening to say the least: ... For whatever reason, courier is enumerating every single file in .Sent/cur and doing *something*, an operation that takes about 41 seconds in this case. If you have enough messages in your Sent folder that it takes 41 seconds to read the directory entries, obviously you need to archive your mail. Courier's SQWebmail does a fairly reasonable job of that, creating subdirectories of Sent that represent time periods and moving messages to the appropriate directory. I do mostly the same thing myself (manually). Your users will need to do the same thing, too. Try to avoid more than 10k messages per folder. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] Slow Copies with Courier-Imap
On 06/09/2009 01:51 PM, Alexander M Thompson wrote: The only problem is, it seems like Copy operations are very slow for the first 30-45 seconds of a given imap session, sometimes to the point where you only can do one operation before it gets better (i.e. copying a small mail to the sent folder takes 30 seconds). ... You do realize that copying a message to the sent folder will cause thunderbird to initiate a new connection, right? If the first copy operation has a long delay and subsequent copy operations do not, then you're probably seeing general connection delays. Check TCPDOPTS in imapd, and add -nodnslookup -noidentlookup if they're not present. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Slow Copies with Courier-Imap
I have a new mail server running courier-imap 4.5.0 on Solaris 10u7, with home directories and maildirs (Maildir format) mounted using autofs. Clients connect via SSL(only) using a variety of mail clients (although I'm seeing the behavior on both sylpheed and thunderbird specifically). The primary back-end file server is a netapp running NFS, connected via gigE across a cisco switch. Neither the server nor the netapp are reporting any kinds of errors or stress, and traffic is way under what I've been able to get with direct copies. I've got MAXDAEMONS=250 and MAXPERIP=50 (probably excessive, but shouldn't cause a problem), neither of which is even being scratched (about 150 daemons during peak times). The only problem is, it seems like Copy operations are very slow for the first 30-45 seconds of a given imap session, sometimes to the point where you only can do one operation before it gets better (i.e. copying a small mail to the sent folder takes 30 seconds). It seems to happen every time a given user reconnects after about 30 minutes of inactivity (I'm guessing its after the old connection shuts down, because thats about the right time frame). It doesn't feel like mount or authentication overhead though, since most times the user is able to log in, browse their messages, and then initiate a copy operation(copy to sent folder, folder to folder copies, or move to trash all exhibit this) before it hangs waiting for the operation to finish. Also, I run squirrelmail on the same server, although it connects to localhost without SSL, and have had no reports of any slow downs what-so-ever on squirrelmail. I've read over pretty much everything I could find about things that could slow courier down, and nothing seems to be jumping out at me. I'm not using FAM/Gamin; no high resource utilization; no network overload; keywords are turned on, but none of the users have massive keyword :lists. As you might be able to tell, I'm at a total loss as to what could be causing this. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
