[Dovecot] Dovecot login slow
Can't figure out why the login is slow. I telnet to port 143 on localhost. I type:
0 login user password
Takes about 10 seconds and it lets me in. I'm using MYSQL and it's a small indexed database on a fast server so it's not the mysql query that's slowing it down. At least I don't think it is. But - kind of stumped. Just wondering if there's something obvious I'm overlooking.
On 11/13/2013 12:41 PM, Marc Perkel wrote:
Can't figure out why the login is slow. I telnet to port 143 on localhost. I type:
0 login user password
Takes about 10 seconds and it lets me in. I'm using MYSQL and it's a small indexed database on a fast server so it's not the mysql query that's slowing it down. At least I don't think it is. But - kind of stumped. Just wondering if there's something obvious I'm overlooking.
Here's my dovecot -n listing. Not using PAM
# 2.2.7: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-042stab083.2 x86_64 CentOS release 6.4 (Final) ext4 auth_master_user_separator = * auth_mechanisms = login plain disable_plaintext_auth = no first_valid_uid = 12 info_log_path = /var/log/dovecot.log log_path = /var/log/dovecot.log login_greeting = Computer Tyme Dovecot ready. mail_fsync = never mail_gid = mail mail_location = maildir:/vhome/%d/home/%n:INDEX=/email/imap-cache/%d-%n mail_uid = mail passdb { args = /etc/dovecot/sql.conf driver = sql } passdb { args = /etc/dovecot/master-combined-sql.conf driver = sql master = yes pass = yes } protocols = imap pop3 service anvil { client_limit = 20000 } service auth { client_limit = 20000 unix_listener auth-client { mode = 0666 } unix_listener auth-master { mode = 0666 } } service imap-login { process_limit = 4000 process_min_avail = 30 service_count = 0 } service imap { process_limit = 4000 } service pop3-login { process_limit = 2000 process_min_avail = 20 service_count = 0 } service pop3 { process_limit = 2000 } ssl_ca = </usr/share/ssl/certs/rapidssl.crt ssl_cert = </usr/share/ssl/certs/imapd.pem ssl_key = </usr/share/ssl/certs/imapd.pem verbose_proctitle = yes protocol imap { mail_max_userip_connections = 50 } protocol pop3 { pop3_uidl_format = %v.%u }
ssl_ca = </usr/share/ssl/certs/rapidssl.crt ssl_cert = </usr/share/ssl/certs/imapd.pem ssl_key = </usr/share/ssl/certs/imapd.pem
These lines look weird to me. Why do they have a < ?
On 14 November 2013 00:57, Marc Perkel <marc@perkel.com> wrote:
On 11/13/2013 12:41 PM, Marc Perkel wrote:
Can't figure out why the login is slow. I telnet to port 143 on localhost. I type:
0 login user password
Takes about 10 seconds and it lets me in. I'm using MYSQL and it's a small indexed database on a fast server so it's not the mysql query that's slowing it down. At least I don't think it is. But - kind of stumped. Just wondering if there's something obvious I'm overlooking.
Here's my dovecot -n listing. Not using PAM
# 2.2.7: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-042stab083.2 x86_64 CentOS release 6.4 (Final) ext4 auth_master_user_separator = * auth_mechanisms = login plain disable_plaintext_auth = no first_valid_uid = 12 info_log_path = /var/log/dovecot.log log_path = /var/log/dovecot.log login_greeting = Computer Tyme Dovecot ready. mail_fsync = never mail_gid = mail mail_location = maildir:/vhome/%d/home/%n:INDEX=/email/imap-cache/%d-%n mail_uid = mail passdb { args = /etc/dovecot/sql.conf driver = sql } passdb { args = /etc/dovecot/master-combined-sql.conf driver = sql master = yes pass = yes } protocols = imap pop3 service anvil { client_limit = 20000 } service auth { client_limit = 20000 unix_listener auth-client { mode = 0666 } unix_listener auth-master { mode = 0666 } } service imap-login { process_limit = 4000 process_min_avail = 30 service_count = 0 } service imap { process_limit = 4000 } service pop3-login { process_limit = 2000 process_min_avail = 20 service_count = 0 } service pop3 { process_limit = 2000 } ssl_ca = </usr/share/ssl/certs/rapidssl.crt ssl_cert = </usr/share/ssl/certs/imapd.pem ssl_key = </usr/share/ssl/certs/imapd.pem verbose_proctitle = yes protocol imap { mail_max_userip_connections = 50 } protocol pop3 { pop3_uidl_format = %v.%u }
On 11/13/2013 11:01 PM Muzaffer Tolga Ozses wrote:
ssl_ca = </usr/share/ssl/certs/rapidssl.crt ssl_cert = </usr/share/ssl/certs/imapd.pem ssl_key = </usr/share/ssl/certs/imapd.pem
These lines look weird to me. Why do they have a < ?
Because Marc uses Dovecot >= v2.0.0
Regards, Pascal
The trapper recommends today: c01dcofe.1331800@localdomain.org
More information ....
When i telnet to localhost on 143 it takes 10-15 seconds to log in.
but ....
When I telnet to the host name of the server it logs in instantly.
Why would it be slow on localhost by fast on the server's IP address?
On 11/13/2013 11:17 PM Marc Perkel wrote:
More information ....
When i telnet to localhost on 143 it takes 10-15 seconds to log in.
but ....
When I telnet to the host name of the server it logs in instantly.
Why would it be slow on localhost by fast on the server's IP address?
Sounds like a DNS lookup problem. Did you list all related ip addresses in /etc/hosts?
Regards, Pascal
The trapper recommends today: c01dcofe.1331800@localdomain.org
On 11/13/2013 3:28 PM, Pascal Volk wrote:
On 11/13/2013 11:17 PM Marc Perkel wrote:
More information ....
When i telnet to localhost on 143 it takes 10-15 seconds to log in.
but ....
When I telnet to the host name of the server it logs in instantly.
Why would it be slow on localhost by fast on the server's IP address?
Sounds like a DNS lookup problem. Did you list all related ip addresses in /etc/hosts?
Regards, Pascal
I does act like a DNS problem but why is DNS involved? It doesn't have a delay in connecting. It's the login that's slow.
Marc Perkel skrev den 2013-11-14 01:13:
I does act like a DNS problem but why is DNS involved? It doesn't have a delay in connecting. It's the login that's slow.
you use a auth that depends on fast dns ?
lost now how your dovecot -n was
are we sure its dns at all ?, i see the INDEX on another path then MAILDIR was, is it 2 diff harddisk drives ?
is it running on shared resources ?
On 11/13/2013 4:34 PM, Benny Pedersen wrote:
Marc Perkel skrev den 2013-11-14 01:13:
I does act like a DNS problem but why is DNS involved? It doesn't have a delay in connecting. It's the login that's slow.
you use a auth that depends on fast dns ?
lost now how your dovecot -n was
are we sure its dns at all ?, i see the INDEX on another path then MAILDIR was, is it 2 diff harddisk drives ?
is it running on shared resources ?
My AUTH depends only on MYSQL. There's no DNS involved. At least not that I can see there should be. So why would localhost take 10-15 seconds to do the login part and coming into the servers IP address is instant. And in both cases the connection itself is instant. It's when I type in the LOGIN command that the delay occurs.
# 2.2.7: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-042stab083.2 x86_64 CentOS release 6.4 (Final) ext4 auth_master_user_separator = * auth_mechanisms = login plain disable_plaintext_auth = no first_valid_uid = 12 info_log_path = /var/log/dovecot.log log_path = /var/log/dovecot.log login_greeting = Computer Tyme Dovecot ready. mail_fsync = never mail_gid = mail mail_location = maildir:/vhome/%d/home/%n:INDEX=/email/imap-cache/%d-%n mail_uid = mail passdb { args = /etc/dovecot/sql.conf driver = sql } passdb { args = /etc/dovecot/master-combined-sql.conf driver = sql master = yes pass = yes } protocols = imap pop3 service anvil { client_limit = 20000 } service auth { client_limit = 20000 unix_listener auth-client { mode = 0666 } unix_listener auth-master { mode = 0666 } } service imap-login { process_limit = 4000 process_min_avail = 30 service_count = 0 } service imap { process_limit = 4000 } service pop3-login { process_limit = 2000 process_min_avail = 20 service_count = 0 } service pop3 { process_limit = 2000 } ssl_ca = </usr/share/ssl/certs/rapidssl.crt ssl_cert = </usr/share/ssl/certs/imapd.pem ssl_key = </usr/share/ssl/certs/imapd.pem verbose_proctitle = yes protocol imap { mail_max_userip_connections = 50 } protocol pop3 { pop3_uidl_format = %v.%u }
Marc Perkel skrev den 2013-11-14 05:25:
My AUTH depends only on MYSQL. There's no DNS involved. At least not that I can see there should be. So why would localhost take 10-15 seconds to do the login part and coming into the servers IP address is instant. And in both cases the connection itself is instant. It's when I type in the LOGIN command that the delay occurs.
i cant see what in sql.conf here, never mind, but localhost is a hostname so it needs dns to find the ip, change the hostname in sql.conf to 127.0.0.1 or use socket file instaed of dns
if that its, give me a hand ?
On 11/14/2013 11:32 AM, Benny Pedersen wrote:
Marc Perkel skrev den 2013-11-14 05:25:
My AUTH depends only on MYSQL. There's no DNS involved. At least not that I can see there should be. So why would localhost take 10-15 seconds to do the login part and coming into the servers IP address is instant. And in both cases the connection itself is instant. It's when I type in the LOGIN command that the delay occurs.
i cant see what in sql.conf here, never mind, but localhost is a hostname so it needs dns to find the ip, change the hostname in sql.conf to 127.0.0.1 or use socket file instaed of dns
if that its, give me a hand ?
That would be understandable if the delay were connecting, but it's not. The connection is instand. And localhost resolves instantly. The delay is after I type in the login command. That's what I don't understand.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 14 Nov 2013, Marc Perkel wrote:
That would be understandable if the delay were connecting, but it's not. The connection is instand. And localhost resolves instantly. The delay is after I type in the login command. That's what I don't understand.
Did you checked the logs in parallel to connecting as I suggested in the other post?
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUoXIrV3r2wJMiz2NAQKsnAgAq9FjeKDyxjchMT5Za96F0bvhCrNrRWWl kYTJT4xRZWGpV1wGQgh2tfMPbX+3CKBsxk6P7APDVSLu++eYTlnPchrh3wMWpkMY 6XSVFcXMNsRY+hVopowiMfTp/RDfAAVS0P51mQAe53sReil9R/hcnh2TQctPA7GZ gly2nVhPMMfy9ngPx4sTo3eMfyjOtH12S+93dFPEbz9KaSpTLxQaIGYcTzarO6bb HeGuSgTyNC7GbmOyzAJGxtN117qui+NdctMhof7Ewe0VrdopIP3mOW0G5sVXyrJU TyByAtNZ500JIWrYxwEzbLffcVES8+YlIqXccK0TXDd65dxFjp43eg== =H+/E -----END PGP SIGNATURE-----
Is it perhaps a *server* dns lookup delay?
I've typically seen 60s delays when a reverse lookup fails, so 20s seems odd - but when you first mentioned it, that's the little flag that waved in my head.
'course I could be totally stupid, high, or huffing glue or something
- but thought I'd throw that out there.
-Greg
MP> On 11/14/2013 11:32 AM, Benny Pedersen wrote:
Marc Perkel skrev den 2013-11-14 05:25:
My AUTH depends only on MYSQL. There's no DNS involved. At least not that I can see there should be. So why would localhost take 10-15 seconds to do the login part and coming into the servers IP address is instant. And in both cases the connection itself is instant. It's when I type in the LOGIN command that the delay occurs.
i cant see what in sql.conf here, never mind, but localhost is a hostname so it needs dns to find the ip, change the hostname in sql.conf to 127.0.0.1 or use socket file instaed of dns
if that its, give me a hand ?
MP> That would be understandable if the delay were connecting, but it's not. MP> The connection is instand. And localhost resolves instantly. The delay MP> is after I type in the login command. That's what I don't understand.
Marc Perkel skrev den 2013-11-14 00:17:
More information ....
When i telnet to localhost on 143 it takes 10-15 seconds to log in.
but ....
When I telnet to the host name of the server it logs in instantly.
Why would it be slow on localhost by fast on the server's IP address?
make localdomain dns works
check /etc/hosts
# incorrect example 127.0.0.1 localhost localhost.localdomain
# correct example 127.0.0.1 localhost.localdomain localhost
note there is also local tld depending on how centos payed attention :(
and add ip / hostnames for dns entries that is not known on boot when named is not yet ready to serve, but still is static under control of you
80.162.68.54 duggi.junc.org duggi ...... more lines if you need one more :)
imho this is the problem is you have dns issues that timeout, nothing beats localhost on dns, so if its not on localhost you know why it takes time
remember the same for ipv6 btw
and drop port 143 and change to port 993 if you are pro :=)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 13 Nov 2013, Marc Perkel wrote:
On 11/13/2013 12:41 PM, Marc Perkel wrote:
Can't figure out why the login is slow. I telnet to port 143 on localhost. I type:
0 login user password
I would:
- add to conf:
auth_debug = yes auth_verbose = yes mail_debug = yes
tail -F /var/log/dovecot.log
telnet & login
and monitor the debug lines to get to know, if the delay comes before auth. If you see userdb log entries before the delay, it is most likely not the DNS.
Do you have the MTA on the same server? If so, a local caching DNS server is good as well.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUoR6+F3r2wJMiz2NAQLC7Qf9GDbL3+FH+zuVbsFmwJCCpVfB0RRsIuWI izaipGz8kynkwIlNqzw8zruTRk09LAZYU/V9DGrIC5nsum4fiW/1bpErfS2vE7F6 F9kLZzcOXoZsQyzqugFa6N4z8s/FPCFeC62yAGRzm1RpsUvf165UIdQuPNRxZjwi Kd5yTqL4gjnNC6uQsAtNHRo9FKkTn32QsmygUZkwv+jL9ZWsPoye6ypLxa7lvuY5 Oyohcz/bLMH6z8G6mxXW9o5B5bVVgf86JdDp34iM8iedejuMMWP6PcqSmNcYc1Ab XZavggfX5nBKqVshUU2quQI/ufqPUCZqecFmEd8vAgha3182T56xeg== =ZQZR -----END PGP SIGNATURE-----
participants (6)
-
Benny Pedersen
-
Gregory Sloop
-
Marc Perkel
-
Muzaffer Tolga Ozses
-
Pascal Volk
-
Steffen Kaiser