Re: Could not connect to socket /var/imap/socket/lmtp: Connection refused by localhost

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sounds like you could consider partitioning (if you aren’t already) - then you can scale-out the disk iops without needing fancy hardware/software:


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 <info-cyrus@xxxxxxxxxxxxxxxxxxxx> 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

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux