dovecot config for 1500 simultaneous connection
hello
could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously.
my server
server configuration hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 gb hdd for data (No raid)
thanks rajesh
my current config file
settings as such
2.2.7: /etc/dovecot/dovecot.conf
OS: Linux 2.6.32-431.29.2.el6.x86_64 x86_64 CentOS release 6.5 (Final)
NOTE: Send doveconf -n output instead when asking for help.
auth_anonymous_username = anonymous auth_cache_negative_ttl = 0 auth_cache_size = 0 auth_cache_ttl = 0 auth_debug = no auth_debug_passwords = yes auth_default_realm = auth_failure_delay = 2 secs auth_gssapi_hostname = auth_krb5_keytab = auth_master_user_separator = auth_mechanisms = plain login digest-md5 cram-md5 auth_proxy_self = auth_realms = auth_socket_path = auth-userdb auth_ssl_require_client_cert = no auth_ssl_username_from_cert = no auth_use_winbind = no auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@ auth_username_format = %Lu auth_username_translation = auth_verbose = no auth_verbose_passwords = no auth_winbind_helper_path = /usr/bin/ntlm_auth auth_worker_max_count = 30 base_dir = /var/run/dovecot config_cache_size = 1 M debug_log_path = default_client_limit = 1000 default_idle_kill = 1 mins default_internal_user = dovecot default_login_user = vpopmail default_process_limit = 100 default_vsz_limit = 256 M deliver_log_format = msgid=%m: %$ dict_db_config = director_doveadm_port = 0 director_mail_servers = director_servers = director_user_expire = 15 mins director_username_hash = %u disable_plaintext_auth = no dotlock_use_excl = yes doveadm_allowed_commands = doveadm_password = doveadm_port = 0 doveadm_socket_path = doveadm-server doveadm_worker_count = 0 dsync_alt_char = _ dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u -U first_valid_gid = 89 first_valid_uid = 89 hostname = imap_capability = imap_client_workarounds = imap_id_log = imap_id_send = name * imap_idle_notify_interval = 2 mins imap_logout_format = in=%i out=%o imap_max_line_length = 64 k imap_metadata = no imap_urlauth_host = imap_urlauth_logout_format = in=%i out=%o imap_urlauth_port = 143 imapc_features = imapc_host = imapc_list_prefix = imapc_master_user = imapc_max_idle_time = 29 mins imapc_password = imapc_port = 143 imapc_rawlog_dir = imapc_ssl = no imapc_ssl_verify = yes imapc_user = import_environment = TZ DEBUG_OUTOFMEM info_log_path = instance_name = dovecot last_valid_gid = 0 last_valid_uid = 0 lda_mailbox_autocreate = no lda_mailbox_autosubscribe = no lda_original_recipient_header = libexec_dir = /usr/libexec/dovecot listen = *, :: lmtp_address_translate = lmtp_proxy = no lmtp_rcpt_check_quota = no lmtp_save_to_detail_mailbox = no lock_method = fcntl log_path = /var/log/dovecot.log log_timestamp = "%b %d %H:%M:%S " login_access_sockets = login_greeting = ready. login_log_format = %$: %s login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c session=<%{session}> login_trusted_networks = mail_access_groups = mail_always_cache_fields = mail_attachment_dir = mail_attachment_fs = sis posix mail_attachment_hash = %{sha1} mail_attachment_min_size = 128 k mail_attribute_dict = mail_cache_fields = flags mail_cache_min_mail_count = 0 mail_chroot = mail_debug = no mail_fsync = optimized mail_full_filesystem_access = no mail_gid = mail_home = mail_location = mail_log_prefix = "%s(%u): " mail_max_keyword_length = 50 mail_max_lock_timeout = 0 mail_max_userip_connections = 10 mail_never_cache_fields = imap.envelope mail_nfs_index = no mail_nfs_storage = no mail_plugin_dir = /usr/lib64/dovecot mail_plugins = " quota" mail_prefetch_count = 0 mail_privileged_group = mail_save_crlf = no mail_shared_explicit_inbox = no mail_temp_dir = /tmp mail_temp_scan_interval = 1 weeks mail_uid = mailbox_idle_check_interval = 30 secs mailbox_list_index = no maildir_broken_filename_sizes = no maildir_copy_with_hardlinks = yes maildir_stat_dirs = no maildir_very_dirty_syncs = no managesieve_client_workarounds = managesieve_implementation_string = Dovecot Pigeonhole managesieve_logout_format = bytes=%i/%o managesieve_max_compile_errors = 5 managesieve_max_line_length = 65536 managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave master_user_separator = mbox_dirty_syncs = yes mbox_dotlock_change_timeout = 2 mins mbox_lazy_writes = yes mbox_lock_timeout = 5 mins mbox_md5 = apop3d mbox_min_index_size = 0 mbox_read_locks = fcntl mbox_very_dirty_syncs = no mbox_write_locks = dotlock fcntl mdbox_preallocate_space = no mdbox_rotate_interval = 0 mdbox_rotate_size = 2 M mmap_disable = no namespace { disabled = no hidden = no ignore_on_failure = no inbox = yes list = yes location = prefix = separator = . subscriptions = yes type = private } passdb { args = cache_key=%u webmail=127.0.0.1 default_fields = deny = no driver = vpopmail master = no override_fields = pass = no result_failure = continue result_internalfail = continue result_success = return-ok skip = never } plugin { quota = maildir:ignore=Trash quota_rule = ?:storage=0 } pop3_client_workarounds = pop3_deleted_flag = pop3_enable_last = no pop3_fast_size_lookups = no pop3_lock_session = no pop3_logout_format = top=%t/%p, retr=%r/%b, del=%d/%m, size=%s pop3_no_flag_updates = no pop3_reuse_xuidl = no pop3_save_uidl = no pop3_uidl_duplicates = allow pop3_uidl_format = %08Xu%08Xv pop3c_host = pop3c_master_user = pop3c_password = pop3c_port = 110 pop3c_rawlog_dir = pop3c_ssl = no pop3c_ssl_verify = yes pop3c_user = %u postmaster_address = protocols = imap pop3 quota_full_tempfail = no recipient_delimiter = + rejection_reason = Your message to <%t> was automatically rejected:%n%r rejection_subject = Rejected: %s replication_full_sync_interval = 1 days replication_max_conns = 10 replicator_host = replicator replicator_port = 0 sendmail_path = /usr/sbin/sendmail service aggregator { chroot = . client_limit = 0 drop_priv_before_exec = no executable = aggregator extra_groups = fifo_listener replication-notify-fifo { group = mode = 0600 user = } group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = service_count = 0 type = unix_listener replication-notify { group = mode = 0600 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service anvil { chroot = empty client_limit = 0 drop_priv_before_exec = no executable = anvil extra_groups = group = idle_kill = 4294967295 secs privileged_group = process_limit = 1 process_min_avail = 1 protocol = service_count = 0 type = anvil unix_listener anvil-auth-penalty { group = mode = 0600 user = } unix_listener anvil { group = mode = 0600 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service auth-worker { chroot = client_limit = 1 drop_priv_before_exec = no executable = auth -w extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = service_count = 1 type = unix_listener auth-worker { group = mode = 0600 user = $default_internal_user } user = vsz_limit = 18446744073709551615 B } service auth { chroot = client_limit = 0 drop_priv_before_exec = no executable = auth extra_groups = group = idle_kill = 0 privileged_group = process_limit = 1 process_min_avail = 0 protocol = service_count = 0 type = unix_listener auth-client { group = mode = 0600 user = $default_internal_user } unix_listener auth-login { group = mode = 0600 user = $default_internal_user } unix_listener auth-master { group = mode = 0600 user = } unix_listener auth-userdb { group = mode = 0666 user = $default_internal_user } unix_listener login/login { group = mode = 0666 user = } unix_listener token-login/tokenlogin { group = mode = 0666 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service config { chroot = client_limit = 0 drop_priv_before_exec = no executable = config extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = service_count = 0 type = config unix_listener config { group = mode = 0600 user = } user = vsz_limit = 18446744073709551615 B } service dict { chroot = client_limit = 1 drop_priv_before_exec = no executable = dict extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = service_count = 0 type = unix_listener dict { group = mode = 0600 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service director { chroot = . client_limit = 0 drop_priv_before_exec = no executable = director extra_groups = fifo_listener login/proxy-notify { group = mode = 00 user = } group = idle_kill = 4294967295 secs privileged_group = process_limit = 1 process_min_avail = 0 protocol = service_count = 0 type = unix_listener director-admin { group = mode = 0600 user = } unix_listener login/director { group = mode = 00 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service dns_client { chroot = client_limit = 1 drop_priv_before_exec = no executable = dns-client extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = service_count = 0 type = unix_listener dns-client { group = mode = 0666 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service doveadm { chroot = client_limit = 1 drop_priv_before_exec = no executable = doveadm-server extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = service_count = 1 type = unix_listener doveadm-server { group = mode = 0600 user = } user = vsz_limit = 18446744073709551615 B } service imap-login { chroot = login client_limit = 0 drop_priv_before_exec = no executable = imap-login extra_groups = group = idle_kill = 0 inet_listener imap { address = port = 143 reuse_port = no ssl = no } inet_listener imaps { address = port = 993 reuse_port = no ssl = yes } privileged_group = process_limit = 256 process_min_avail = 50 protocol = imap service_count = 1 type = login user = $default_login_user vsz_limit = 18446744073709551615 B } service imap-urlauth-login { chroot = token-login client_limit = 0 drop_priv_before_exec = no executable = imap-urlauth-login extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = imap service_count = 1 type = login unix_listener imap-urlauth { group = mode = 0666 user = } user = $default_login_user vsz_limit = 18446744073709551615 B } service imap-urlauth-worker { chroot = client_limit = 1 drop_priv_before_exec = no executable = imap-urlauth-worker extra_groups = group = idle_kill = 0 privileged_group = process_limit = 1024 process_min_avail = 0 protocol = imap service_count = 1 type = unix_listener imap-urlauth-worker { group = mode = 0600 user = $default_internal_user } user = vsz_limit = 18446744073709551615 B } service imap-urlauth { chroot = client_limit = 1 drop_priv_before_exec = no executable = imap-urlauth extra_groups = group = idle_kill = 0 privileged_group = process_limit = 1024 process_min_avail = 0 protocol = imap service_count = 1 type = unix_listener token-login/imap-urlauth { group = mode = 0666 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service imap { chroot = client_limit = 1 drop_priv_before_exec = no executable = imap extra_groups = group = idle_kill = 0 privileged_group = process_limit = 2048 process_min_avail = 50 protocol = imap service_count = 1 type = unix_listener login/imap { group = mode = 0666 user = } user = vsz_limit = 512 M } service indexer-worker { chroot = client_limit = 1 drop_priv_before_exec = no executable = indexer-worker extra_groups = group = idle_kill = 0 privileged_group = process_limit = 10 process_min_avail = 0 protocol = service_count = 0 type = unix_listener indexer-worker { group = mode = 0600 user = $default_internal_user } user = vsz_limit = 18446744073709551615 B } service indexer { chroot = client_limit = 0 drop_priv_before_exec = no executable = indexer extra_groups = group = idle_kill = 0 privileged_group = process_limit = 1 process_min_avail = 0 protocol = service_count = 0 type = unix_listener indexer { group = mode = 0666 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } service ipc { chroot = empty client_limit = 0 drop_priv_before_exec = no executable = ipc extra_groups = group = idle_kill = 0 privileged_group = process_limit = 1 process_min_avail = 0 protocol = service_count = 0 type = unix_listener ipc { group = mode = 0600 user = } unix_listener login/ipc-proxy { group = mode = 0600 user = $default_login_user } user = $default_internal_user vsz_limit = 18446744073709551615 B } service lmtp { chroot = client_limit = 1 drop_priv_before_exec = no executable = lmtp extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = lmtp service_count = 0 type = unix_listener lmtp { group = mode = 0666 user = } user = vsz_limit = 18446744073709551615 B } service log { chroot = client_limit = 0 drop_priv_before_exec = no executable = log extra_groups = group = idle_kill = 4294967295 secs privileged_group = process_limit = 1 process_min_avail = 0 protocol = service_count = 0 type = log unix_listener log-errors { group = mode = 0600 user = } user = vsz_limit = 18446744073709551615 B } service managesieve-login { chroot = login client_limit = 0 drop_priv_before_exec = no executable = managesieve-login extra_groups = group = idle_kill = 0 inet_listener sieve { address = port = 4190 reuse_port = no ssl = no } privileged_group = process_limit = 0 process_min_avail = 0 protocol = sieve service_count = 1 type = login user = $default_login_user vsz_limit = 18446744073709551615 B } service managesieve { chroot = client_limit = 1 drop_priv_before_exec = no executable = managesieve extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = sieve service_count = 1 type = unix_listener login/sieve { group = mode = 0666 user = } user = vsz_limit = 18446744073709551615 B } service pop3-login { chroot = login client_limit = 0 drop_priv_before_exec = no executable = pop3-login extra_groups = group = idle_kill = 0 inet_listener pop3 { address = port = 110 reuse_port = no ssl = no } inet_listener pop3s { address = port = 995 reuse_port = no ssl = yes } privileged_group = process_limit = 256 process_min_avail = 25 protocol = pop3 service_count = 1 type = login user = $default_login_user vsz_limit = 18446744073709551615 B } service pop3 { chroot = client_limit = 1 drop_priv_before_exec = no executable = pop3 extra_groups = group = idle_kill = 0 privileged_group = process_limit = 256 process_min_avail = 25 protocol = pop3 service_count = 1 type = unix_listener login/pop3 { group = mode = 0666 user = } user = vsz_limit = 18446744073709551615 B } service replicator { chroot = client_limit = 0 drop_priv_before_exec = no executable = replicator extra_groups = group = idle_kill = 4294967295 secs privileged_group = process_limit = 1 process_min_avail = 0 protocol = service_count = 0 type = unix_listener replicator-doveadm { group = mode = 00 user = $default_internal_user } unix_listener replicator { group = mode = 0600 user = $default_internal_user } user = vsz_limit = 18446744073709551615 B } service ssl-params { chroot = client_limit = 0 drop_priv_before_exec = no executable = ssl-params extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = service_count = 0 type = startup unix_listener login/ssl-params { group = mode = 0666 user = } unix_listener ssl-params { group = mode = 0666 user = } user = vsz_limit = 18446744073709551615 B } service stats { chroot = empty client_limit = 0 drop_priv_before_exec = no executable = stats extra_groups = fifo_listener stats-mail { group = mode = 0600 user = } group = idle_kill = 4294967295 secs privileged_group = process_limit = 1 process_min_avail = 0 protocol = service_count = 0 type = unix_listener stats { group = mode = 0600 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } shutdown_clients = yes ssl = yes ssl_ca = ssl_cert = </var/qmail/control/servercert.pem ssl_cert_username_field = commonName ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL ssl_client_ca_dir = ssl_client_ca_file = ssl_client_cert = ssl_client_key = ssl_crypto_device = ssl_dh_parameters_length = 2048 ssl_key = </var/qmail/control/servercert.pem ssl_key_password = ssl_parameters_regenerate = 0 ssl_prefer_server_ciphers = no ssl_protocols = !SSLv2 ssl_require_crl = yes ssl_verify_client_cert = no state_dir = /var/lib/dovecot stats_command_min_time = 1 mins stats_domain_min_time = 12 hours stats_ip_min_time = 12 hours stats_memory_limit = 16 M stats_session_min_time = 15 mins stats_user_min_time = 1 hours submission_host = syslog_facility = mail userdb { args = cache_key=%u quota_template=quota_rule=*:backend=%q default_fields = driver = vpopmail override_fields = } valid_chroot_dirs = verbose_proctitle = no verbose_ssl = no version_ignore = no protocol imap { imap_client_workarounds = delay-newmail mail_max_userip_connections = 200 mail_plugins = " quota imap_quota" } protocol pop3 { mail_max_userip_connections = 40 pop3_client_workarounds = outlook-no-nuls oe-ns-eoh pop3_fast_size_lookups = yes pop3_lock_session = no pop3_no_flag_updates = yes }
On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:
hello
could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously.
Be very precise here, you expect to see 1500 as the result of "doveadm who |grep pop3 |wc -l"?
Because that implies an ungodly number of POP3 connects per second, given the typically short duration of these.
1500 IMAP connections (note that frequently a client will have more than the INBOX open and thus have more than one session and thus process on the server) are a much easier proposition, provided they are of the typical long lasting type.
So can you put a number to your expected logins per second (both protocols)?
my server
server configuration hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 gb hdd for data (No raid)
No RAID and no other replication like DRBD? Why would you even bother?
How many users/mailboxes in total with what quota?
1500 IMAP sessions will eat up about 3GB alone. You will want more memory, simply to keep all relevant SLAB bits (inodes, dentries) in RAM.
If you really have several hundreds logins/s, you're facing several bottlenecks:
- Login processes themselves (easily fixed by high performance mode)
- Auth processes (that will depend on your backends, method mostly)
- Dovecot master process (spawning mail processes)
The later is a single-threaded process, so it will benefit from a faster CPU core. It can be dramatically improved by enabling process re-usage, see: http://wiki.dovecot.org/PerformanceTuning
However that also means more memory usage.
Christian
thanks rajesh
[snip]
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications
http://www.gol.com/
1500 IMAP sessions will eat up about 3GB alone.
Are you saying that Dovecot needs 2MB of physical memory per IMAP session?
If I want to support a max 100,000 IMAP sessions per server, I should configure the server to have at least 200GBs of SWAP?
On Feb 10, 2017, at 3:58 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:
hello
could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously.
Be very precise here, you expect to see 1500 as the result of "doveadm who |grep pop3 |wc -l"?
Because that implies an ungodly number of POP3 connects per second, given the typically short duration of these.
1500 IMAP connections (note that frequently a client will have more than the INBOX open and thus have more than one session and thus process on the server) are a much easier proposition, provided they are of the typical long lasting type.
So can you put a number to your expected logins per second (both protocols)?
my server
server configuration hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 gb hdd for data (No raid)
No RAID and no other replication like DRBD? Why would you even bother?
How many users/mailboxes in total with what quota?
1500 IMAP sessions will eat up about 3GB alone. You will want more memory, simply to keep all relevant SLAB bits (inodes, dentries) in RAM.
If you really have several hundreds logins/s, you're facing several bottlenecks:
- Login processes themselves (easily fixed by high performance mode)
- Auth processes (that will depend on your backends, method mostly)
- Dovecot master process (spawning mail processes)
The later is a single-threaded process, so it will benefit from a faster CPU core. It can be dramatically improved by enabling process re-usage, see: http://wiki.dovecot.org/PerformanceTuning
However that also means more memory usage.
Christian
thanks rajesh
[snip]
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications http://www.gol.com/
On Fri, 10 Feb 2017 07:59:52 -0500 KT Walrus wrote:
1500 IMAP sessions will eat up about 3GB alone.
Are you saying that Dovecot needs 2MB of physical memory per IMAP session?
That depends on the IMAP session, read the mailbox size and index size, etc. Some are significantly larger:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1033864 mail 20 0 97600 67m 54m S 0 0.1 0:01.15 imap
But yes, as somebody who has mailbox servers with 55k+ session the average is around 1.6MB.
If I want to support a max 100,000 IMAP sessions per server, I should configure the server to have at least 200GBs of SWAP?
You will want:
- 256GB of real RAM, swap is for chums.
- Understanding how to tune Dovecot and more importantly the overall system to such a task (see that PID up there?).
- Be willing to deal with stuff like top and ps taking ages to start/run and others like atop actually killing dovecot (performance wise, not literally) when doing their obviously flawed cleanup on exit. Some things clearly do NOT scale well.
My current goal is to have 100k capable servers that work well, 200k in a failover scenario, but that won't be particular enjoyable.
Christian
On Feb 10, 2017, at 3:58 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:
hello
could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously.
Be very precise here, you expect to see 1500 as the result of "doveadm who |grep pop3 |wc -l"?
Because that implies an ungodly number of POP3 connects per second, given the typically short duration of these.
1500 IMAP connections (note that frequently a client will have more than the INBOX open and thus have more than one session and thus process on the server) are a much easier proposition, provided they are of the typical long lasting type.
So can you put a number to your expected logins per second (both protocols)?
my server
server configuration hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 gb hdd for data (No raid)
No RAID and no other replication like DRBD? Why would you even bother?
How many users/mailboxes in total with what quota?
1500 IMAP sessions will eat up about 3GB alone. You will want more memory, simply to keep all relevant SLAB bits (inodes, dentries) in RAM.
If you really have several hundreds logins/s, you're facing several bottlenecks:
- Login processes themselves (easily fixed by high performance mode)
- Auth processes (that will depend on your backends, method mostly)
- Dovecot master process (spawning mail processes)
The later is a single-threaded process, so it will benefit from a faster CPU core. It can be dramatically improved by enabling process re-usage, see: http://wiki.dovecot.org/PerformanceTuning
However that also means more memory usage.
Christian
thanks rajesh
[snip]
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications http://www.gol.com/
--
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications
http://www.gol.com/
- 256GB of real RAM, swap is for chums.
Are you sure that 100,000 IMAP sessions wouldn’t work well with SWAP, especially with fast SSD storage (which is a lot cheaper than RAM)?
Seems that these IMAP processes are long lived processes (idling most of the time) that don’t need that much of the contents of real memory available for much of the life of the process. I use a database proxy in front of MySQL (for my web apps) so that there can be a large number of TCP connections to the proxy where the frontend requests are queued for execution using a small number of backend connections.
Could Dovecot IMAP be re-written to be more efficient so it works more like MySQL (or other scalable data servers) that could handle a million or more IMAP sessions on a server with 32GBs or less of RAM? Those IMAP sessions aren’t doing much most of the time and shouldn’t really average 2MB of active data per session that needs to be resident in main memory at all times.
My mail server isn’t that large yet as I haven’t fully deployed Dovecot outside my own small group yet, but it would be nice if scaling Dovecot IMAP to millions of users wasn’t limited to 50,000 IMAP sessions on a server...
On Feb 10, 2017, at 11:07 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 07:59:52 -0500 KT Walrus wrote:
1500 IMAP sessions will eat up about 3GB alone.
Are you saying that Dovecot needs 2MB of physical memory per IMAP session?
That depends on the IMAP session, read the mailbox size and index size, etc. Some are significantly larger:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1033864 mail 20 0 97600 67m 54m S 0 0.1 0:01.15 imapBut yes, as somebody who has mailbox servers with 55k+ session the average is around 1.6MB.
If I want to support a max 100,000 IMAP sessions per server, I should configure the server to have at least 200GBs of SWAP?
You will want:
- Understanding how to tune Dovecot and more importantly the overall system to such a task (see that PID up there?).
- Be willing to deal with stuff like top and ps taking ages to start/run and others like atop actually killing dovecot (performance wise, not literally) when doing their obviously flawed cleanup on exit. Some things clearly do NOT scale well.
My current goal is to have 100k capable servers that work well, 200k in a failover scenario, but that won't be particular enjoyable.
Christian
On Feb 10, 2017, at 3:58 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:
hello
could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously.
Be very precise here, you expect to see 1500 as the result of "doveadm who |grep pop3 |wc -l"?
Because that implies an ungodly number of POP3 connects per second, given the typically short duration of these.
1500 IMAP connections (note that frequently a client will have more than the INBOX open and thus have more than one session and thus process on the server) are a much easier proposition, provided they are of the typical long lasting type.
So can you put a number to your expected logins per second (both protocols)?
my server
server configuration hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 gb hdd for data (No raid)
No RAID and no other replication like DRBD? Why would you even bother?
How many users/mailboxes in total with what quota?
1500 IMAP sessions will eat up about 3GB alone. You will want more memory, simply to keep all relevant SLAB bits (inodes, dentries) in RAM.
If you really have several hundreds logins/s, you're facing several bottlenecks:
- Login processes themselves (easily fixed by high performance mode)
- Auth processes (that will depend on your backends, method mostly)
- Dovecot master process (spawning mail processes)
The later is a single-threaded process, so it will benefit from a faster CPU core. It can be dramatically improved by enabling process re-usage, see: http://wiki.dovecot.org/PerformanceTuning
However that also means more memory usage.
Christian
thanks rajesh
[snip]
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications http://www.gol.com/-- Christian Balzer Network/Systems Engineer
chibi@gol.com <mailto:chibi@gol.com> Global OnLine Japan/Rakuten Communications http://www.gol.com/ <http://www.gol.com/>
Hello,
On Fri, 10 Feb 2017 14:50:03 -0500 KT Walrus wrote:
- 256GB of real RAM, swap is for chums.
Are you sure that 100,000 IMAP sessions wouldn’t work well with SWAP, especially with fast SSD storage (which is a lot cheaper than RAM)?
I'm sure about tax and death, not much else.
But as a rule of thumb I'd avoid swapping out stuff on production servers, even if it were to SSDs. Incidentally the servers I'm talking about here have their OS and swap on Intel DC S3710s (200GB) and the actual storage on plenty of 1.6TB DC S3610s.
Relying on the kernel to make swap decisions is likely to result in much reduced performance even with fast SWAP when you're overcommitting things on that scale.
But read on.
Seems that these IMAP processes are long lived processes (idling most of the time) that don’t need that much of the contents of real memory available for much of the life of the process. I use a database proxy in front of MySQL (for my web apps) so that there can be a large number of TCP connections to the proxy where the frontend requests are queued for execution using a small number of backend connections.
Could Dovecot IMAP be re-written to be more efficient so it works more like MySQL (or other scalable data servers) that could handle a million or more IMAP sessions on a server with 32GBs or less of RAM? Those IMAP sessions aren’t doing much most of the time and shouldn’t really average 2MB of active data per session that needs to be resident in main memory at all times.
See IMAP hibernation: https://www.mail-archive.com/dovecot@dovecot.org/msg63429.html
I'm going to deploy/test this in production in about 2 months from now, but if you look at the link and the consequent changelog entries you'll see that it has certain shortcomings and bug fixes in pretty much each release after it was introduced.
But this is the correct way to tackle things, not SWAP.
Alas I'm not expecting miracles and if more than 20% of the IMAP sessions here will be hibernated at any given time I'd be pleasantly surprised.
Because between:
Finding a sensible imap_hibernate_timeout.
Having well behaved clients that keep idling instead of restarting the sequence (https://joshdata.wordpress.com/2014/08/09/how-bad-is-imap-idle/)
Having lots of mobile clients who either get disconnected (invisible to Dovecot) or have aggressive IDLE timers to overcome carrier NAT timeouts (a large mobile carrier here times out idle TCP sessions after 2 minutes, forcing people to use 1 minute IDLE renewals, making 1. up there a nightmare).
Having really broken clients (don't ask, I can't tell) which open IMAP sessions, don't put them into IDLE and thus having them expire after 30 minutes.
the pool of eligible IDLE sessions isn't as big as it could be, in my case at least.
My mail server isn’t that large yet as I haven’t fully deployed Dovecot outside my own small group yet, but it would be nice if scaling Dovecot IMAP to millions of users wasn’t limited to 50,000 IMAP sessions on a server...
Scaling up is nice and desirable from a cost (rack space, HW) perspective, but the scalability of things OTHER than Dovecot as I pointed out plus that little detail of failure domains (do you really want half of your eggs in one basket?) argue for scaling out after a certain density.
I'm feeling my way there at this time, but expect more than 100k sessions per server to be tricky.
Lastly, when I asked about 500k sessions per server here not so long ago, ( http://www.dovecot.org/list/dovecot/2016-November/106284.html ) Timo mentioned that he's not aware of anybody doing more than 50k per server, something I got licked already and definitely will go to 100k eventually.
Regards,
Christian
On Feb 10, 2017, at 11:07 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 07:59:52 -0500 KT Walrus wrote:
1500 IMAP sessions will eat up about 3GB alone.
Are you saying that Dovecot needs 2MB of physical memory per IMAP session?
That depends on the IMAP session, read the mailbox size and index size, etc. Some are significantly larger:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1033864 mail 20 0 97600 67m 54m S 0 0.1 0:01.15 imapBut yes, as somebody who has mailbox servers with 55k+ session the average is around 1.6MB.
If I want to support a max 100,000 IMAP sessions per server, I should configure the server to have at least 200GBs of SWAP?
You will want:
- Understanding how to tune Dovecot and more importantly the overall system to such a task (see that PID up there?).
- Be willing to deal with stuff like top and ps taking ages to start/run and others like atop actually killing dovecot (performance wise, not literally) when doing their obviously flawed cleanup on exit. Some things clearly do NOT scale well.
My current goal is to have 100k capable servers that work well, 200k in a failover scenario, but that won't be particular enjoyable.
Christian
On Feb 10, 2017, at 3:58 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:
hello
could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously.
Be very precise here, you expect to see 1500 as the result of "doveadm who |grep pop3 |wc -l"?
Because that implies an ungodly number of POP3 connects per second, given the typically short duration of these.
1500 IMAP connections (note that frequently a client will have more than the INBOX open and thus have more than one session and thus process on the server) are a much easier proposition, provided they are of the typical long lasting type.
So can you put a number to your expected logins per second (both protocols)?
my server
server configuration hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 gb hdd for data (No raid)
No RAID and no other replication like DRBD? Why would you even bother?
How many users/mailboxes in total with what quota?
1500 IMAP sessions will eat up about 3GB alone. You will want more memory, simply to keep all relevant SLAB bits (inodes, dentries) in RAM.
If you really have several hundreds logins/s, you're facing several bottlenecks:
- Login processes themselves (easily fixed by high performance mode)
- Auth processes (that will depend on your backends, method mostly)
- Dovecot master process (spawning mail processes)
The later is a single-threaded process, so it will benefit from a faster CPU core. It can be dramatically improved by enabling process re-usage, see: http://wiki.dovecot.org/PerformanceTuning
However that also means more memory usage.
Christian
thanks rajesh
[snip]
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications http://www.gol.com/-- Christian Balzer Network/Systems Engineer
chibi@gol.com <mailto:chibi@gol.com> Global OnLine Japan/Rakuten Communications http://www.gol.com/ <http://www.gol.com/>
--
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications
http://www.gol.com/
Thanks for the info. I do have one further question for you. On your servers that are currently handling 50k IMAP sessions, how many users does that correspond to? Since many users will have multiple IMAP sessions on multiple devices, I’d like to hear about some real-world numbers that could be used for budgeting a new project like mine.
Also, do you use Dovecot IMAP proxies in front of your backend servers? If so, how many IMAP sessions can one proxy server handle (assuming the proxy does authorization using MySQL running on a separate server)? And, could the proxy server be tuned to help in optimizing mostly IDLE backend sessions?
On Feb 12, 2017, at 1:58 AM, Christian Balzer <chibi@gol.com> wrote:
Hello,
On Fri, 10 Feb 2017 14:50:03 -0500 KT Walrus wrote:
- 256GB of real RAM, swap is for chums.
Are you sure that 100,000 IMAP sessions wouldn’t work well with SWAP, especially with fast SSD storage (which is a lot cheaper than RAM)?
I'm sure about tax and death, not much else.
But as a rule of thumb I'd avoid swapping out stuff on production servers, even if it were to SSDs. Incidentally the servers I'm talking about here have their OS and swap on Intel DC S3710s (200GB) and the actual storage on plenty of 1.6TB DC S3610s.
Relying on the kernel to make swap decisions is likely to result in much reduced performance even with fast SWAP when you're overcommitting things on that scale.
But read on.
Seems that these IMAP processes are long lived processes (idling most of the time) that don’t need that much of the contents of real memory available for much of the life of the process. I use a database proxy in front of MySQL (for my web apps) so that there can be a large number of TCP connections to the proxy where the frontend requests are queued for execution using a small number of backend connections.
Could Dovecot IMAP be re-written to be more efficient so it works more like MySQL (or other scalable data servers) that could handle a million or more IMAP sessions on a server with 32GBs or less of RAM? Those IMAP sessions aren’t doing much most of the time and shouldn’t really average 2MB of active data per session that needs to be resident in main memory at all times.
See IMAP hibernation: https://www.mail-archive.com/dovecot@dovecot.org/msg63429.html <https://www.mail-archive.com/dovecot@dovecot.org/msg63429.html>
I'm going to deploy/test this in production in about 2 months from now, but if you look at the link and the consequent changelog entries you'll see that it has certain shortcomings and bug fixes in pretty much each release after it was introduced.
But this is the correct way to tackle things, not SWAP.
Alas I'm not expecting miracles and if more than 20% of the IMAP sessions here will be hibernated at any given time I'd be pleasantly surprised.
Because between:
Finding a sensible imap_hibernate_timeout.
Having well behaved clients that keep idling instead of restarting the sequence (https://joshdata.wordpress.com/2014/08/09/how-bad-is-imap-idle/ <https://joshdata.wordpress.com/2014/08/09/how-bad-is-imap-idle/>)
Having lots of mobile clients who either get disconnected (invisible to Dovecot) or have aggressive IDLE timers to overcome carrier NAT timeouts (a large mobile carrier here times out idle TCP sessions after 2 minutes, forcing people to use 1 minute IDLE renewals, making 1. up there a nightmare).
Having really broken clients (don't ask, I can't tell) which open IMAP sessions, don't put them into IDLE and thus having them expire after 30 minutes.
the pool of eligible IDLE sessions isn't as big as it could be, in my case at least.
My mail server isn’t that large yet as I haven’t fully deployed Dovecot outside my own small group yet, but it would be nice if scaling Dovecot IMAP to millions of users wasn’t limited to 50,000 IMAP sessions on a server...
Scaling up is nice and desirable from a cost (rack space, HW) perspective, but the scalability of things OTHER than Dovecot as I pointed out plus that little detail of failure domains (do you really want half of your eggs in one basket?) argue for scaling out after a certain density.
I'm feeling my way there at this time, but expect more than 100k sessions per server to be tricky.
Lastly, when I asked about 500k sessions per server here not so long ago, ( http://www.dovecot.org/list/dovecot/2016-November/106284.html <http://www.dovecot.org/list/dovecot/2016-November/106284.html> ) Timo mentioned that he's not aware of anybody doing more than 50k per server, something I got licked already and definitely will go to 100k eventually.
Regards,
Christian
On Feb 10, 2017, at 11:07 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 07:59:52 -0500 KT Walrus wrote:
1500 IMAP sessions will eat up about 3GB alone.
Are you saying that Dovecot needs 2MB of physical memory per IMAP session?
That depends on the IMAP session, read the mailbox size and index size, etc. Some are significantly larger:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1033864 mail 20 0 97600 67m 54m S 0 0.1 0:01.15 imapBut yes, as somebody who has mailbox servers with 55k+ session the average is around 1.6MB.
If I want to support a max 100,000 IMAP sessions per server, I should configure the server to have at least 200GBs of SWAP?
You will want:
- Understanding how to tune Dovecot and more importantly the overall system to such a task (see that PID up there?).
- Be willing to deal with stuff like top and ps taking ages to start/run and others like atop actually killing dovecot (performance wise, not literally) when doing their obviously flawed cleanup on exit. Some things clearly do NOT scale well.
My current goal is to have 100k capable servers that work well, 200k in a failover scenario, but that won't be particular enjoyable.
Christian
On Feb 10, 2017, at 3:58 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:
hello
could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously.
Be very precise here, you expect to see 1500 as the result of "doveadm who |grep pop3 |wc -l"?
Because that implies an ungodly number of POP3 connects per second, given the typically short duration of these.
1500 IMAP connections (note that frequently a client will have more than the INBOX open and thus have more than one session and thus process on the server) are a much easier proposition, provided they are of the typical long lasting type.
So can you put a number to your expected logins per second (both protocols)?
my server
server configuration hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 gb hdd for data (No raid)
No RAID and no other replication like DRBD? Why would you even bother?
How many users/mailboxes in total with what quota?
1500 IMAP sessions will eat up about 3GB alone. You will want more memory, simply to keep all relevant SLAB bits (inodes, dentries) in RAM.
If you really have several hundreds logins/s, you're facing several bottlenecks:
- Login processes themselves (easily fixed by high performance mode)
- Auth processes (that will depend on your backends, method mostly)
- Dovecot master process (spawning mail processes)
The later is a single-threaded process, so it will benefit from a faster CPU core. It can be dramatically improved by enabling process re-usage, see: http://wiki.dovecot.org/PerformanceTuning
However that also means more memory usage.
Christian
thanks rajesh
[snip]
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications http://www.gol.com/-- Christian Balzer Network/Systems Engineer
chibi@gol.com <mailto:chibi@gol.com> <mailto:chibi@gol.com <mailto:chibi@gol.com>> Global OnLine Japan/Rakuten Communications http://www.gol.com/ <http://www.gol.com/> <http://www.gol.com/ <http://www.gol.com/>>-- Christian Balzer Network/Systems Engineer
chibi@gol.com <mailto:chibi@gol.com> Global OnLine Japan/Rakuten Communications http://www.gol.com/ <http://www.gol.com/>
Hello,
On Sun, 12 Feb 2017 08:27:21 -0500 KT Walrus wrote:
Thanks for the info. I do have one further question for you. On your servers that are currently handling 50k IMAP sessions, how many users does that correspond to? Since many users will have multiple IMAP sessions on multiple devices, I’d like to hear about some real-world numbers that could be used for budgeting a new project like mine.
Those servers would actually be the wrong ones to look at, as they are primarily accessed by the aforementioned broken client, so the numbers are somewhat skewed. However looking at other servers with a more "normal" user spread things aren't actually too different.
The average number of sessions per user tends to be 2. The clear majority (over 50%) only has one session open (people with well behaved and configured clients watching the INBOX mostly). Another 30% has 2 sessions open, again the typical state of this would be clients watching another mailbox besides INBOX, typically SENT. The rest has 3 and more sessions open.
The number of sessions could of course be drastically reduced if any client would support IMAP NOTIFY, alas none that I'm aware of do.
Lastly no more than 60% of the session seem to be in IDLE at any given time, so my comments about RAM and IMAP hibernation effectiveness stand.
Also, do you use Dovecot IMAP proxies in front of your backend servers? If so, how many IMAP sessions can one proxy server handle (assuming the proxy does authorization using MySQL running on a separate server)? And, could the proxy server be tuned to help in optimizing mostly IDLE backend sessions?
Yes to Dovecot Proxying, of course.
No idea about MySQL, with (Open)LDAP nothing is breaking a sweat at an average of 140 logins per second (IMAP and POP) on the 2 proxy servers. If you can fit your entire dataset into RAM it should be fine, my LDAP servers fall into that category and take about 10% of a slow (1.2GHz, 34%, power-save mode) core only to handle the that load (also 2 servers). And the rate of logins/s is what you need to worry about most and optimize for.
The proxies will of course have to do the shuffling of data and SSL en/de-coding, but again they're not particular busy with that.
The number of sessions comes into play when looking at the number of login processes on the proxies and their memory footprint. An IMAP login process on the proxies in performance mode with a client limit of 1000 will consume about 55MB at most. So assume at least 55KB RAM per session.
Read Timo's mail I linked to about IMAP hibernation, AFAIK nothing has happened to make proxies more supportive for this though.
Christian
On Feb 12, 2017, at 1:58 AM, Christian Balzer <chibi@gol.com> wrote:
Hello,
On Fri, 10 Feb 2017 14:50:03 -0500 KT Walrus wrote:
- 256GB of real RAM, swap is for chums.
Are you sure that 100,000 IMAP sessions wouldn’t work well with SWAP, especially with fast SSD storage (which is a lot cheaper than RAM)?
I'm sure about tax and death, not much else.
But as a rule of thumb I'd avoid swapping out stuff on production servers, even if it were to SSDs. Incidentally the servers I'm talking about here have their OS and swap on Intel DC S3710s (200GB) and the actual storage on plenty of 1.6TB DC S3610s.
Relying on the kernel to make swap decisions is likely to result in much reduced performance even with fast SWAP when you're overcommitting things on that scale.
But read on.
Seems that these IMAP processes are long lived processes (idling most of the time) that don’t need that much of the contents of real memory available for much of the life of the process. I use a database proxy in front of MySQL (for my web apps) so that there can be a large number of TCP connections to the proxy where the frontend requests are queued for execution using a small number of backend connections.
Could Dovecot IMAP be re-written to be more efficient so it works more like MySQL (or other scalable data servers) that could handle a million or more IMAP sessions on a server with 32GBs or less of RAM? Those IMAP sessions aren’t doing much most of the time and shouldn’t really average 2MB of active data per session that needs to be resident in main memory at all times.
See IMAP hibernation: https://www.mail-archive.com/dovecot@dovecot.org/msg63429.html <https://www.mail-archive.com/dovecot@dovecot.org/msg63429.html>
I'm going to deploy/test this in production in about 2 months from now, but if you look at the link and the consequent changelog entries you'll see that it has certain shortcomings and bug fixes in pretty much each release after it was introduced.
But this is the correct way to tackle things, not SWAP.
Alas I'm not expecting miracles and if more than 20% of the IMAP sessions here will be hibernated at any given time I'd be pleasantly surprised.
Because between:
Finding a sensible imap_hibernate_timeout.
Having well behaved clients that keep idling instead of restarting the sequence (https://joshdata.wordpress.com/2014/08/09/how-bad-is-imap-idle/ <https://joshdata.wordpress.com/2014/08/09/how-bad-is-imap-idle/>)
Having lots of mobile clients who either get disconnected (invisible to Dovecot) or have aggressive IDLE timers to overcome carrier NAT timeouts (a large mobile carrier here times out idle TCP sessions after 2 minutes, forcing people to use 1 minute IDLE renewals, making 1. up there a nightmare).
Having really broken clients (don't ask, I can't tell) which open IMAP sessions, don't put them into IDLE and thus having them expire after 30 minutes.
the pool of eligible IDLE sessions isn't as big as it could be, in my case at least.
My mail server isn’t that large yet as I haven’t fully deployed Dovecot outside my own small group yet, but it would be nice if scaling Dovecot IMAP to millions of users wasn’t limited to 50,000 IMAP sessions on a server...
Scaling up is nice and desirable from a cost (rack space, HW) perspective, but the scalability of things OTHER than Dovecot as I pointed out plus that little detail of failure domains (do you really want half of your eggs in one basket?) argue for scaling out after a certain density.
I'm feeling my way there at this time, but expect more than 100k sessions per server to be tricky.
Lastly, when I asked about 500k sessions per server here not so long ago, ( http://www.dovecot.org/list/dovecot/2016-November/106284.html <http://www.dovecot.org/list/dovecot/2016-November/106284.html> ) Timo mentioned that he's not aware of anybody doing more than 50k per server, something I got licked already and definitely will go to 100k eventually.
Regards,
Christian
On Feb 10, 2017, at 11:07 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 07:59:52 -0500 KT Walrus wrote:
1500 IMAP sessions will eat up about 3GB alone.
Are you saying that Dovecot needs 2MB of physical memory per IMAP session?
That depends on the IMAP session, read the mailbox size and index size, etc. Some are significantly larger:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1033864 mail 20 0 97600 67m 54m S 0 0.1 0:01.15 imapBut yes, as somebody who has mailbox servers with 55k+ session the average is around 1.6MB.
If I want to support a max 100,000 IMAP sessions per server, I should configure the server to have at least 200GBs of SWAP?
You will want:
- Understanding how to tune Dovecot and more importantly the overall system to such a task (see that PID up there?).
- Be willing to deal with stuff like top and ps taking ages to start/run and others like atop actually killing dovecot (performance wise, not literally) when doing their obviously flawed cleanup on exit. Some things clearly do NOT scale well.
My current goal is to have 100k capable servers that work well, 200k in a failover scenario, but that won't be particular enjoyable.
Christian
On Feb 10, 2017, at 3:58 AM, Christian Balzer <chibi@gol.com> wrote:
On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:
> hello > > could somebody with experience let me know the dovecot config file settings to handle around 1500 simultaneous connections over pop3 and 1500 connection over imap simultaneously. >
Be very precise here, you expect to see 1500 as the result of "doveadm who |grep pop3 |wc -l"?
Because that implies an ungodly number of POP3 connects per second, given the typically short duration of these.
1500 IMAP connections (note that frequently a client will have more than the INBOX open and thus have more than one session and thus process on the server) are a much easier proposition, provided they are of the typical long lasting type.
So can you put a number to your expected logins per second (both protocols)?
> my server > > server configuration > hex core processor, 16 gb ram 1 X 600 gb 15 k rpm for main drive and 2 X 2000 > gb hdd for data (No raid) >
No RAID and no other replication like DRBD? Why would you even bother?How many users/mailboxes in total with what quota?
1500 IMAP sessions will eat up about 3GB alone. You will want more memory, simply to keep all relevant SLAB bits (inodes, dentries) in RAM.
If you really have several hundreds logins/s, you're facing several bottlenecks:
- Login processes themselves (easily fixed by high performance mode)
- Auth processes (that will depend on your backends, method mostly)
- Dovecot master process (spawning mail processes)
The later is a single-threaded process, so it will benefit from a faster CPU core. It can be dramatically improved by enabling process re-usage, see: http://wiki.dovecot.org/PerformanceTuning
However that also means more memory usage.
Christian
> > thanks > rajesh >
[snip]
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications http://www.gol.com/-- Christian Balzer Network/Systems Engineer
chibi@gol.com <mailto:chibi@gol.com> <mailto:chibi@gol.com <mailto:chibi@gol.com>> Global OnLine Japan/Rakuten Communications http://www.gol.com/ <http://www.gol.com/> <http://www.gol.com/ <http://www.gol.com/>>-- Christian Balzer Network/Systems Engineer
chibi@gol.com <mailto:chibi@gol.com> Global OnLine Japan/Rakuten Communications http://www.gol.com/ <http://www.gol.com/>
--
Christian Balzer Network/Systems Engineer
chibi@gol.com Global OnLine Japan/Rakuten Communications
http://www.gol.com/
participants (3)
-
Christian Balzer
-
KT Walrus
-
Rajesh M