我之前发布过类似的问题,我以为它解决了我的问题,但不幸的是事实并非如此。
我有一个基准测试应用程序,它使用 IMAP(纯文本身份验证,无 SSL)将大约 500 个用户连接到 Dovecot 2.2.5 邮件服务器。在 dovecot 处理大约 300 个用户后,旧连接开始失败,并且我在客户端和服务器端都收到错误。
以下是服务器端的一些示例:
Sep 23 19:05:52 imap-login: Info: Login: user=<test1>, method=PLAIN, rip=10.0.0.6, lip=10.0.0.2, mpid=1492, secured, session=<GqSHtRHnpQAKAAAG>
Sep 23 19:05:53 imap-login: Info: Login: user=<test2>, method=PLAIN, rip=10.0.0.6, lip=10.0.0.2, mpid=1494, secured, session=<K1OMtRHnpgAKAAAG>
Sep 23 19:05:53 imap-login: Info: Login: user=<test3>, method=PLAIN, rip=10.0.0.6, lip=10.0.0.2, mpid=1495, secured, session=<S/6QtRHnpwAKAAAG>
Sep 23 19:05:53 imap-login: Info: Login: user=<test4>, method=PLAIN, rip=10.0.0.6, lip=10.0.0.2, mpid=1496, secured, session=<37CVtRHnqAAKAAAG>
...
(Gets to around user=<test330>, then this:)
Sep 23 19:08:03 master: Error: service(imap): Initial status notification not received in 30 seconds, killing the process
Sep 23 19:08:04 imap: Fatal: master: service(imap): child 1840 killed with signal 9
Sep 23 19:08:04 imap(test211): Info: Connection closed: Connection reset by peer in=105 out=917
然后我看到用户数少于 300 以及用户数高达 500 的重复登录。
在我的客户端,我收到了以下大量消息:
2013-09-23 19:07:57:997 Warning: .doMyLongCommand received an SocketTimeoutException exception java.net.SocketTimeoutException: Read timed out
2013-09-23 19:07:57:997 ERROR: : Read timed out
2013-09-23 19:07:57:997 test211:Reconnecting user due to error condition during SELECT_INBOX
dovecot -a
以下是一些与同时为大量客户端提供服务相关的配置选项(使用):
default_client_limit = 2003
default_idle_kill = 1 hours
default_process_limit = 1000
default_vsz_limit = 1024 M
mbox_dotlock_change_timeout = 5 mins
mbox_lock_timeout = 8 mins
service_count = 0 (in service imap-login {} )
mail_max_userip_connections = 1000
noproc
并且nofile
设置得非常高(102400),所以那里不应该有任何问题。
我脑子一片空白。据我所知,我认为问题的根源可能是以下之一:
- 与内存有关,尽管 1GB 应该足够了。
- 与配置有关,但我没有看到任何其他似乎影响的设置
- 与网络有关。但是,它是否应该能够连接并穿过最初的 300 个客户端?
任何帮助将不胜感激。
答案1
服务器上的 CPU 使用率如何?磁盘 I/O 怎么样?我怀疑某些系统资源超载了。服务进程启动太慢,dovecot master 认为它们没有响应。
这是您遇到的超时时间: http://hg.dovecot.org/dovecot-2.2/file/b9498573f0d0/src/master/service.h#l7
编辑这也可能是 ulimit() 中非常严格的用户进程数量限制或某些 SELinux 功能(例如 CentOS)起作用。
@user991710 也许您可以更详细地解释一下您的测试客户端向服务器发出了哪些命令以及它是什么类型的客户端。