Re: Could not connect to socket /var/imap/socket/lmtp: Connection refused by localhost
Merlin Hartley via Info-cyrus <[email protected]>
| Newsgroups | gmane.mail.imap.cyrus |
|---|---|
| Message-ID | <[email protected]> |
Sounds like you could consider partitioning (if you aren’t already) - then you can scale-out the disk iops without needing fancy hardware/software: https://www.cyrusimap.org/docs/cyrus-imapd/2.4.7/overview.php#partitions <https://www.cyrusimap.org/docs/cyrus-imapd/2.4.7/overview.php#partitions> Hope this is useful! M -- Merlin Hartley IT Systems Engineer MRC Mitochondrial Biology Unit Cambridge, CB2 0XY United Kingdom > On 17 Jan 2017, at 16:43, Eugene M. Zheganin via Info-cyrus <[email protected]> wrote: > > Hi. > > On 17.01.2017 19:09, Andy Dorman via Info-cyrus wrote: >> >> I am not an expert by any means and I hope someone corrects me if I make a bad suggestion...but I have two questions: >> >> 1. It sounds like you have a heavily used server, so why do you have Cyrus listening on both "localhost:lmtp" AND a unix socket "/var/imap/socket/lmtp"? >> >> From the log entry it looks like your MTA uses a unix socket. Unless you have something else (mail clients or other MTAs running on your Cyrus server?) that need to communicate via the localhost:lmtp port, you could comment out the unneeded lmtp service line and save those resources. > Well, on one hand you are right, seems like noone uses network lmtp connections, but on the other hand how can the idle processes save resources ? They only can save the memory, which doesn't seem to be the problem. However, I will try you advice. >> >> 2. You say "increasing this value can make the situation even worse". Which value? There are 5 values on those two lines that you could increase. And by "even worse" do you mean even more refused connections? > The maxchild number. >> >> While I am not a Cyrus guru, I have seen my share of overloaded mail servers and if you are running into a disk IO limit, adding more processes fighting over a limited resource is very likely to make things worse. So you should also confirm a hardware limitation is not at play here. > Yup, this is exaclty what happens when increasing the maxchild number: more messages start to bounce. And yes, the disks iops seems to be the limiting factor. So, are there any other approaches besides scaling out the disks iops ? > > Thanks. > Eugene. > > > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus