[Dovecot] Slow DNS warnings (proxy/auth)
Hello, I've just finished transiting our proxies from perdition to dovecot (2.1.7-7 Debian). Yesterday 12 messages (all within the same second) like this caught my attention: --- Apr 25 17:19:09 pp11 dovecot: auth: Warning: proxy(redac...@gol.com,xx.xx.xx.xx,26hUEivbfQBlMrMS): DNS lookup for mb04.dentaku.gol.com took 5.002 s --- Now this machine at that time was handling a load of about 2 logins per second, about 20% of what it previously handled with perdition w/o a hiccup. It also runs a local caching nameserver and the A record for the mailbox server in question was most definitely cached at the time (verified via TTL). The machine in question was very bored and certainly capable of handling hundreds if not thousands of DNS queries per second at that moment. In short, I can't see any reason how the lookup could have taken so long, so my guess is there are some issues with the dns-helper (locking, stepping on each others feet, not being spawned fast enough) causing this. Some general remarks, dovecot as proxy feels heavier than perdition. In the CPU area that's probably a more subjective impression, because all the little helper processes make it clear what's going on where. Though the config process being rather active is something that perdition definitely doesn't do, it reads the config once at start time and that's it. All the IPC and central processes of course also make dovecot rather file handle hungry. Memory wise it's about 35% bigger than perdition and that's not subjective at all. ^o^ About one MB per proxy process/connection for dovecot in my case. Caveat emptor. ^o^ Regards, Christian -- Christian BalzerNetwork/Systems Engineer ch...@gol.com Global OnLine Japan/Fusion Communications http://www.gol.com/
Re: [Dovecot] ios clients and namespace trouble
On 4/24/2013 12:05 PM, Kelsey Cummings wrote:
before or if they had tried and failed. Perhaps a hidden namespace with
folders linked to the real special folders or might that have unintended
consequences?
This seems to kinda work with the only oddity being that the ios client,
if not manually configured with the correct prefix, ends up creating new
folders in the hidden one and initially displaying them at the same
level as the inbox. Once the app is restarted it sees them in the
correct namespace as a folder under the inbox. However, looks like
some other clients might get confused, but maybe Windows Live Mail is
going to get confused anyway. ;)
namespace {
type=private
separator = .
prefix = INBOX.
inbox = yes
mailbox Trash {
auto = create
special_use = \Trash
}
...
}
namespace FAKE {
type=private
separator = .
hidden = yes
list = no
mailbox Trash {
special_use = \Trash
}
...
}
--
Kelsey Cummings - k...@corp.sonic.net sonic.net, inc.
System Architect 2260 Apollo Way
707.522.1000 Santa Rosa, CA 95407
Re: [Dovecot] Replication fails with Remote dsync doesn't use compatible protocol
richatwork dovecot: doveadm: Error: dsync-remote(richatwork): Error: dsync(local): Remote dsync doesn't use compatible protocol I was finally able to get replication working by abandoning the wrapper script approach and, instead, putting a mail_replica value on each line of the userdb file -- like this: richatwork:hashed password here:5003:5003::/home/mail/richatwork::userdb_mail_replica=remote:richatw...@pigeon.richw.org The root dsync public key in each individual account's .ssh/authorized_keys file has a command= parameter invoking /usr/bin/doveadm dsync-server with the appropriate -u option. As I noted in an earlier e-mail, if you put a command= parameter on a public key in the authorized_keys file, you don't need to specify the command in the ssh command line -- in fact, there is no point to doing that (any command in the ssh command line is ignored if the public key on the target has a command= parameter). Now that I have replication working, I have another question: Is it sufficient to configure just one server for replication in order to have changes propagated in both directions? Or do I need to configure replication on both servers (with each one replicating to the other)? Rich Wales ri...@richw.org
