Increase LMTP Threads

[kollross]

Is there a way in zimbra to increase the number of LMTP threads on a server in order to accept a larger amount of email from another zimbra server that is doing external spam filtering? We are currently seeing timeouts on the LMTP port on the MailStore server.

[graffiti]

Originally Posted by kollross

Is there a way in zimbra to increase the number of LMTP threads on a server in order to accept a larger amount of email from another zimbra server that is doing external spam filtering? We are currently seeing timeouts on the LMTP port on the MailStore server.

Yes. The defaul value is 10 and it's stored in com.zimbra.cs.util.Config.D_LMTP_THREADS. You can override this default value by defining a new key in /opt/zimbra/conf/localconfig.xml named zimbraLmtpNumThreads, for example if you want to increase it to 50, just execute below commands under the zimbra user:

zimbra$ zmlocalconfig -e zimbraLmtpNumThreads=50
zimbra$ tomcat stop
zimbra$ tomcat start

The first command creates the new key zimbraLmtpNumThreads and sets its value to 50. Two other command restart tomcat to restart the lmtp server.

HTH,

-g

[kollross]

Is there a way to increase the LMTP between two servers. Basically here is the problem, We a spam filter on server1, and the MailStore on server2. I have increased the threads on Server2 with the command posted above. However the Queue sizes have been growing, however it is delivering mail but at a very slow pace. Is there a way to increase the amount of Messages sent out of Server1. Right now i believe there are 6 LMTP connections between the servers yet i've set the threads on Server2 to be 50.

[KevinH]

Any idea why it's slow? Are you pinned on CPU/Mem/Disk on either machine? So server1 is running Zimbra's SA+ClamAv+Postfix? Or is it something else?

[tron]

We should not be pinned on the CPU Mem or Disk. They 2 to 4 GB of RAM, 500 GB on the mailstore machine. Both are Xeon processors.

Server1 is runnning Zimbra's SA+ClamAv+Postfix.

We are running into a problem that even after we upped the lmtpthreads to 100 using zmlocalconfig -e but it still refuses to handle more than 13 incoming lmtp connections from server1. So the queue on the spam filter machine (server1) is growing steadily. Please help.

Originally Posted by KevinH

Any idea why it's slow? Are you pinned on CPU/Mem/Disk on either machine? So server1 is running Zimbra's SA+ClamAv+Postfix? Or is it something else?

[anand]

Number of LMTP threads should be changed in LDAP - not local config.

$ zmprov mcf zimbraLmtpNumThreads 50
$ tomcat stop
$ tomcat start

The number of concurrent LMTP deliveries that postfix will do is dictated by postconf lmtp_destination_concurrency_limit, which defaults to 20. The zimbra server side default is 8, so there is definitely a bug here - which I have fixed post 3.0.0_M2.

Message delivery does take a lot of CPU, and 4 concurrent deliveries should give the system enough work to do - if they don't that's a different bug - something else is wrong. There is should also be no delay between deliveries unless messages in the queue have been deferred and are waiting for retry at a later time.

[anand]

if you are seeing timeouts on the postfix side to LMTP, it would be good to check what state tomcat is in at that time. kill -3 on the tomcat java process id should do a Java thread dump into catalina.out. If we can see that thread dump when you see these timeouts that would be great. First try the LMTP thread count increase though.

[tron]

Thanks for the command help. I have tried up the lmtp threads. However, we are still looking at a rather slow delivery. With a little under 2000 users on our system, zimbra does not seem to be able to keep up with the volume of incoming messages.

Originally Posted by anand

Number of LMTP threads should be changed in LDAP - not local config.

$ zmprov mcf zimbraLmtpNumThreads 50
$ tomcat stop
$ tomcat start

The number of concurrent LMTP deliveries that postfix will do is dictated by postconf lmtp_destination_concurrency_limit, which defaults to 20. The zimbra server side default is 8, so there is definitely a bug here - which I have fixed post 3.0.0_M2.

Message delivery does take a lot of CPU, and 4 concurrent deliveries should give the system enough work to do - if they don't that's a different bug - something else is wrong. There is should also be no delay between deliveries unless messages in the queue have been deferred and are waiting for retry at a later time.

[anand]

Originally Posted by tron

Thanks for the command help. I have tried up the lmtp threads. However, we are still looking at a rather slow delivery. With a little under 2000 users on our system, zimbra does not seem to be able to keep up with the volume of incoming messages.

Can you please tell us what the iostat -x output looks like on both systems and what top is reporting on the machine running tomcat server? ie, are the machines saturated with work and is not enough work being scheduled to drain the queue?