![]() |
Version 5.2 |
||||||||||||||||||||||||||||||||
|
|
ドメインのアカウント数が多い(10,000 以上) 場合、アカウントは、単一のドメインディレクトリで はなく、複数のサブディレクトリ( ドメインサブディレクトリ) に格納するようにします。
ドメインサブディレクトリは、別のディスクに移動させることができます。その場合、移動後のサブ ディレクトリにシンボリックリンクを作成します。
同様にDomains ディレクトリのドメインディレクトリを別の場所に移動することもできます。その場 合も同じく、移動後のドメインディレクトリにシンボリックリンクを作成します。
通常、CommuniGate Pro のローカルのアカウントに対して配信されるメッセージの数が、平均で秒あ たり1 メッセージを超えるようなケースでは、クラスタモジュール(Local Delivery モジュール) の 「プロセッサ」の数を増やすことが必要です。この操作は、とくにインバウンドSMTP トラフィックが 大きい環境(例えば、パフォーマンステストと同様の環境) で必要になります。Local Delivery モジュー ルのプロセッサ(スレッド) の数が不足している場合、キューのデータ量が過剰になり、その結果、 メッセージの配信に大きな遅延(待ち時間) が生じます。こういったケースでは、Local Delivery モ ジュールのキューをチェックし、必要に応じてLocal Delivery モジュールのプロセッサ(スレッド) の 数を増やさなければなりません。ただし、プロセッサの数は、適当なレベルに維持することが重要で す。例えば、Local Delivery モジュールのプロセッサの数が10 で、Local Delivery モジュールのキュー に格納されるメッセージの数が200 の場合、10 というプロセッサの数は適当です。このキューサイズ であれば、配信待ち時間は1 ~ 2 秒で済みます。これ以上、キューサイズが大きくなるときに限って、 プロセッサの数を増やすようにします。
ハイエンドメールサーバー( メッセージ数が非常に多いサーバー) の場合、[Use Conservative Info Updates]オプションは無効にします(WebAdmin の[Obscure Settings]ページの[Local Account Options] にあります)。
ISP や企業の大規模システムの場合、ユーザーからの要求(セッション) を同時にどれだけ処理でき るかが重要な問題になります。
同時に処理できるセッションの数(同時セッション数) は、次のようにして予測できます。予測の方 法は、クライアントソフトウェアで使用されるサービスの種類によって異なります。以下、順に説明 します。
この35 という同時セッション数は、それほど高い数値ではありません。ただし、POP3 セッショ ンでは、ローカルのディスクI/O とネットワークI/O サブシステムに大きな負荷がかかります。 これは、POP3 では、認証後にユーザーが行う処理は、基本的に「ファイルダウンロード」形式 の処理であるためです。
IMAP プロトコルは、基本的に「メールアクセス」プロトコルであり、「メールダウンロード」プ ロトコルではありません。そのため、ユーザーがサーバーに接続している時間は、POP に比べ て相当長くなります。例えば、企業のシステムの場合、ユーザーは、数日とは言わないまでも 数時間、IMAP セッションをオープンにしたままにすることもあります。こういった非アクティ ブのセッションは、ローカルのディスクやネットワークI/O サブシステム、CPU に負荷は与え ないものの、サーバー上で、各セッションについてオープンネットワーク接続と処理スレッド が必要です。また、IMAP プロトコルの場合、ユーザーは、サーバーのメールに対して検索処理 を実行することもできます。検索処理が頻繁に行われる場合、CPU リソースの消費も大きくな ります。
If supporting many IMAP or POP connections, it is important to configure more IMAP and POP channels, to allow for large numbers of users to connect concurrently. Some modern IMAP clients and the MAPI connector may even open multiple connections for a single account, and each is counted in the IMAP channel total. Fortunately, IMAP and POP channels are created only when used, so no resources are consumed if the IMAP and POP channels are set to 10000 if only 2000 are being used - however, be careful to set this value below the threshold where your system will be unable to withstand further connections, and could become unresponsive for users already connected. The IMAP and POP channels setting provides a limit for protecting your system or cluster resources from being overwhelmed, in the case of a peak load or denial of service (DoS) attack.
この仕様により、サーバー上では100 のHTTP 接続で3,000 以上のオープンセッションの処理 が可能です。
CommuniGate Pro also supports the HTTP 1.1 "Keep-Alive" option, located on the WebUser Interface Settings page as "Support Keep-Alive". HTTP Keep-Alive sessions for WebUsers will cause each WebUser session to maintain one or more open connections from the user client to the server for the entire session duration. This method is not recommended on a busy, high-volume server as it will consume significant CPU and operating system resources, but can be used to optimize WebUser response time for end users if the system can handle the additional overhead. Keep-Alive connections will only be offered on Frontend servers in a Cluster.
In order to optimize SIP and RTP performance, your CommuniGate Pro
Server should run on modern systems with adequate CPU and memory headroom.
If most of the traffic through CommuniGate Pro is just SIP signaling
traffic, then even a single-CPU server should be capable of upwards of
100 calls per second. However, when performing significant amounts of
SIP and RTP proxying, NAT traversal, PBX functions and media termination,
the demands on memory, network, and especially CPU will be significant.
Increasing the number of SIP Server
and SIP Client
processors, as well as Signal processors, is required.
These threads are all "static", meaning that the threads are created regardless of whether or
not they are in use, and they will consume some memory resources for their stacks.
以上のようにして、サポートするクライアントの種類(POP、IMAP など) とユーザー数をもとに、 サーバーの動作に必要なリソースを予想できます。
When optimizing a system for performance, there are often certain system kernel and TCP/UDP stack tuning options available which allow the system to open more concurrent network connections and allow the CommuniGate Pro process to open many file descriptors. While most operating systems allow for tuning these options, the method of doing so will differ greatly across platforms, and you may need to contact your operating system vendor or research the proper way to modify your system accordingly.
The number of available file descriptors should be set to approximately 2x the number of concurrent IMAP, POP, SMTP, SIP/RTP, and other types of connections required. You should also be certain that the operating system is capable of efficiently opening this many TCP/UDP sockets simultaneously - some OSs have a "hash table" for managing sockets, and this table should be set greater than the number of sockets required. Often times, allowing at least 8192 sockets and 16384 open file descriptors per process should be plenty for most systems, even under significant load. Increasing these values much too high can in most cases consume some memory resources, and should be avoided. Setting the limit on the number of open file descriptors to "unlimited" in the shell can also cause problems on some operating systems, as this could set the available file descriptors to the 32-bit or 64-bit limits, which can in some cases waste memory and CPU resources.
TCP/IP 接続の数が多い場合、サーバーOS の待機時間、つまり論理的にクローズされているTCP/IP ソケットが解放されるまで時間(TIME_WAIT 時間) の設定が重要になります。この待機時間が長すぎ ると、こういった「眠っている」ソケットによってOS のTCP/IP リソースがすべて消費されてしま うことがあります。また、新規の接続がすべてOS レベルで拒否されるといったことも起こります。 こういった状態になると、CommuniGate Pro サーバーから警告メッセージが出力されなくなります。
上の問題は、アカウント数が数百という小規模のサイトでも発生することがあります。つまり、ユー ザーがサーバーのメールをチェックする頻度が非常に高い場合、この問題が発生します。例えば、ユー ザーが1 分間に一度サーバーに接続し、OS のTIME_WAIT 時間が2 分間に設定されている場合、「眠っ ている」ソケットの数は次第に増え、最後にはOS のTCP/IP リソースが残らず消費されてしまいま す。
TCP/IP 接続の数が多いと予想されるときには、TIME_WAIT 時間を20 ~ 30 秒に設定します。この設 定で通常、上のような問題は解決できます。
TIME_WAIT の問題は、Windows NT システムではよく発生します。したがって、TIME_WAIT 時間の調 整が必要です。ただし、Unix システムとは違い、Windows NT ではTIME_WAIT 時間の設定オプション はありません。この時間を変更する場合、次のようにしてWindows NT のレジストリにエントリを作 成しなければなりません(下記に掲載した情報は、http://www.microsoft.com サイトから入手したもの です)。
説明: 上のパラメータ(レジストリ) の値は、クローズされている接続がTIME_WAIT 状態になって いる時間の長さです。接続がTIME_WAIT 状態にある場合、ソケットペアは利用できません。この状 態は、「2MSL (2 × MSL)」と呼ばれることもあります。2MSL と呼ばれるのは、RFC (IETF が発行す る文書) に、この値は最大セグメント寿命(MSL) の2 倍にするのが妥当と記載されているためです。
Most operating systems (including Linux, FreeBSD, Solaris, Windows) do not fully support x86 HyperThreading.
Unlike multi-core and/or multi-CPU technologies, HyperThreading provides very
small (if any) performance gain, but it causes many problems: threads library crashing,
poor NFS performance under load, etc.
Use your server BIOS settings to disable HyperThreading.
SMTP デリバリでの同時要求の数は、[Obscure Settings] ページの[Domain Name Resolver] パネルの [Concurrent Requests] オプションで設定できます。このオプションを値を変更して、DNS サーバーの 処理をチェックできます。例えば、使用しているDNS サーバーによっては、同時要求の値が10 また は20 以上のときには性能が低下することがあります。その場合、低めの値に変更します。
また、SMTP を介して送信されるメッセージの平均サイズが20K を超える場合、SMTP 送信チャンネ ル(スレッド) の数は慎重に選択しなければなりません。これは、平均サイズが20K を超えると同時 データ転送の数が増え、その数が過剰になって有効なネットワーク帯域幅を超えたときには、性能の 低下を招くことがあるためです。例えば、チャンネル数を500 に設定している場合、512K ビット/ 秒 という比較的低速の接続を介して、平均サイズが大きいデータをリモートサイトに送信すると、ロー カルのサイトからの送信トラフィックは250M ビット/ 秒と大きくなります。一方、メッセージの平 均サイズが小さいときには、ローカルのサイトからの送信トラフィックは、これほど大きくはなりま せん。送信チャンネルでは、主にパラメータのネゴシエートとエンベロープデータの交換が行われる ためです。これに対して、メッセージの平均サイズが大きくなるほど、チャンネルを介して実際のメッ セージデータが送信される時間が増加し、その結果、各チャンネルのTCP トラフィックが大きくなり ます。
If using SMTP External Message Filters (Plugins) - such as anti-virus, anti-spam, or other content-filtering helpers - then the SMTP load can be optimized by putting any temporary file directories used by these plugins onto a memory or tmpfs filesystem, if your system has the available memory. Since all messages should be queued in the real CommuniGate Pro Queue directories, there should be no risk in putting the plugin temporary file directories, as long as those directories never contain the only copy of any message. Even in the event of an error, power failure, or server crash, any undelivered message should always be queued to "stable storage" in the normal CommuniGate Pro Queue directory.
ネットワーク接続にはそれぞれネットワークソケットディスクリプタ( ソケット/ ファイルディスク リプタ) が1 つ必要で、各ディスクリプタはサーバープロセスに置かれます。Unix システムの場合、 単一のサーバープロセス上でオープン可能なソケット/ ファイルの合計数には制限があります。
CommuniGate Pro サーバーの起動時には、プロセス上でオープン可能なソケット/ ファイルの数の最 大数として、可能な限り高い値に設定されます。ただし、その値がシステムの制限(上限) に近い場 合、多少低い値に変更されます(サーバーOS 上で利用可能な「ディスクリプタ」をCommuniGate Pro がすべて消費した場合、ほぼ確実にOS クラッシュが発生するためです)。変更後の値は、CommuniGate Pro のログに記録されます。
上記の変更後の値、つまりCommuniGate Pro サーバープロセス上でオープン可能なファイル/ ソケッ トディスクリプタの最大数は、場合によっては低すぎることもあり、必要であれば次のように計算し て引き上げます。
ネットワーク接続はそれぞれ、単一のサーバースレッド(CommuniGate Pro のスレッド) によって処 理されます。スレッドにはいずれも、そのスレッドのスタックがあり、スタックの大きさは大半のプ ラットフォームで100K バイトです。スタックメモリは、通常はほとんどは使用されず、そのため実 メモリは必要としません。ただし、スレッドの数が増えると、かなりの仮想メモリが必要になること があります。一方、ほとんどのOS では、仮想メモリには上限が設けられています。この上限は通常、 OS のスワップスペースと実メモリサイズを合計した値です。例えば、システムのスワップスペース が127M バイトで実メモリが96M バイトの場合、利用可能な最大仮想メモリサイズは220M バイトと いうことになります。ただし、スワップスペースは、サーバーOS 上で動作している各プロセスによっ て共有されるため、CommuniGate Pro サーバープロセスで利用可能な実効仮想メモリサイズは100 ~ 150MB 程度です。このサイズの場合、CommuniGate Pro サーバーで作成される処理スレッドの数は500 ~ 1000 です。このようにして得られた数値を目安に、必要に応じてファイル/ ソケットディスクリプ タの最大数を調整します(設定方法は後述してあります)。
32 ビットコンピュータでは、4GB が仮想メモリの理論上の最大サイズです。つまり、ページスワッピ ングに4GB 以上のディスクスペースを割り当てても効果はありません。そのため、ファイル/ ソケッ トディスクリプタの最大数を考慮する場合、スワップスペースの上限を4GB と考えなければなりませ ん。
POP3 またはIMAP4 では、そのアクセスセッション中、アカウントのメールボックスのうちいずれか 1 つがオープンの状態になります。そのメールボックスがテキストファイル(BSD タイプ) のメール ボックスの場合、メールボックスファイルがオープンの状態になります。また、受信SMTP セッショ ン中、メッセージが受信されるとメッセージの暫定ファイルが作成され、その暫定ファイルはメッセージの受信中、オープンの状態が継続されます。このため、Unix システムの場合、POP、IMAP、SMTP のオープンの接続の合計数は、プロセスあたりのソケット/ ファイルディスクリプタの最大数の2 分 の1 を超えることはありません(残りの2 分の1 のディスクリプタは、ソケット用です)。ファイル/ ソケットディスクリプタの最大数を調整する場合、この事実も考慮に入れなければなりません。
WebUser セッションでは、ネットワーク接続(したがって、そのソケット/ スレッド) は不要で、そ のためソケット/ ファイルディスクリプタの最大数を考慮する必要はありません。ネットワーク接続 がなくても、複数のメールボックスがオープンされます。
Unix システムの場合、CommuniGate Pro サーバーにより、オープンしているソケット/ ファイルディ スクリプタの数が上限に近づいていることが検出されると、受信接続の拒否が開始されます。また、 ログを介して、この処理に関する情報が報告されます。
ここでは、各オペレーティングシステムで使われている制限値のチェック、また、値の調整について 説明します。ここで説明する制限値は、主に次の2 種類です。
Please always confirm these changes with your operating system vendor, and always test changes on a test system before using on a production server. Variations in operating system versions, patches, hardware, and load requirements can vary the best settings for these values. Examples are provided as a guide but may not always be optimal for every situation.
SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10" ulimit -n 16384
Following are a few settings appropriate for most Solaris systems, where significant load capacity is required. A good estimate is to set these values between 1-2 times the expected peak capacity.
* system file descriptor limit (setting the max setting to 32768 may * be better in some instances) set rlim_fd_cur=4096 set rlim_fd_max=16384 * tcp connection hash size set tcp:tcp_conn_hash_size=16384Note: /etc/system changes require a system reboot to take effect.
# solaris 9/10 uses a default of 49152 ndd -set /dev/tcp tcp_recv_hiwat 49152 # or 65536 ndd -set /dev/tcp tcp_xmit_hiwat 49152 # or 65536 # increase the connection queue ndd -set /dev/tcp tcp_conn_req_max_q 512 ndd -set /dev/tcp tcp_conn_req_max_q0 5120 # decrease timers ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 135000 ndd -set /dev/tcp tcp_time_wait_interval 60000 ndd -set /dev/tcp tcp_keepalive_interval 30000 ## naglim should likely only be disabled on Backends ## 1=disabled, default is 53 (difficult to confirm) # ndd -set /dev/tcp tcp_naglim_def 1
For more details, check the Microsoft Support Article Q196271.
On Linux, the Startup.sh file is referenced by default at /var/CommuniGate/Startup.sh. You may need to create it. This file is read by the init startup script /etc/init.d/CommuniGate to be executed at boot time. The following is a Startup.sh file for CommuniGate Pro version 4.3 or later for Linux 2.4 or later. In some cases, you may find that more file descriptors are required, so the "ulimit -n" value can be increased up to 32768 safely, if necessary.
SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10" ulimit -n 16384
カーネルバージョンが2-2.x より前のLinux の場合、プロセスでオープンできるファイルディスクリ プタは256 に限定されています。TCP/IP 接続数が100 を超えるときには、カーネルバージョンが2.2.x 以降のLinux を使用します。この方法で、「ファイルディスクリプタ不足」問題を解決できます。
Linux スレッドライブラリは、1 対1 モデルです。つまり、CommuniGate Pro のスレッドはそれぞれ、 単一のカーネルスレッド(実質的にプロセス) の形で実行されます。ただし、大規模なシステムでは 数百のスレッドが動作するため、この仕様は必ずしもベストではありません。
Linux のスレッドはカーネルの中で処理されますが、その一方、Linux スレッドライブラリには、ス レッドライブラリ用のスケジューラがあります。このスケジューラの場合、デフォルトでは、エント リ数が1024 のスタティックテーブルが使われます。その結果、作成可能なスレッドは1024 に限定さ れます。このデフォルト値は、POP ユーザーとWebMail ユーザーだけのシステムであれば、かなり大 きなシステムでも問題はありません。ただし、ユーザーがIMAP ユーザーであり、同時セッション数 が数百というサイトの場合は問題が生じます。そういったときには、値を引き上げなければなりませ ん。値は、PTHREAD_THREADS_MAX パラメータで変更できます。変更後、Linux スレッドライブラリ を再コンパイルします。
Linux スレッドライブラリでは、スレッドに割り当てられるスタックのステップ(サイズの単位) は 2MB です。このサイズの場合、32 ビットマシンでは、起動されるスレッド数は1000 以下に限定され ます。また、CommuniGate Pro のスレッドは、このような大きなスタックを必要としません。したがっ て、STACK_SIZE parameter パラメータで、このサイズを128K に落とします。変更後、Linux スレッ ドライブラリを再コンパイルします。
LD_ASSUME_KERNEL=2.4.1 export LD_ASSUME_KERNEL
There are additional tuning options for Linux kernel 2.4. For most Linux distributions, these shell commands should be placed into a boot script to be run at system startup. RedHat and a few other distributions may also provide a facility to configure "sysctl" data in the file /etc/sysctl.conf:
#!/bin/sh # Linux 2.4 tuning script # max open files echo 131072 > /proc/sys/fs/file-max # kernel threads echo 131072 > /proc/sys/kernel/threads-max # socket buffers echo 65536 > /proc/sys/net/core/wmem_default echo 1048576 > /proc/sys/net/core/wmem_max echo 65536 > /proc/sys/net/core/rmem_default echo 1048576 > /proc/sys/net/core/rmem_max # netdev backlog echo 4096 > /proc/sys/net/core/netdev_max_backlog # socket buckets echo 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets # port range echo '16384 65535' > /proc/sys/net/ipv4/ip_local_port_rangeNote: when using Linux kernels 2.4 and 2.6, there is a noticeable networking performance improvement if you re-compile the kernel without NETFILTER (iptables) if you are not using iptables on your CommuniGate Pro server.
# LD_ASSUME_KERNEL=2.4.1 # export LD_ASSUME_KERNEL
Commenting these lines should allow for the POSIX thread shared libraries (located in /lib/tls/) to be linked in by default.
Following are some additional tuning options for Linux 2.6. For most Linux distributions, these shell commands should be placed into a boot script to be run at system startup. RedHat and a few other distributions may also provide a facility to configure "sysctl" data in the file /etc/sysctl.conf:#!/bin/sh # Linux 2.6 tuning script # max open files echo 131072 > /proc/sys/fs/file-max # kernel threads echo 131072 > /proc/sys/kernel/threads-max # socket buffers echo 65536 > /proc/sys/net/core/wmem_default echo 1048576 > /proc/sys/net/core/wmem_max echo 65536 > /proc/sys/net/core/rmem_default echo 1048576 > /proc/sys/net/core/rmem_max # netdev backlog echo 4096 > /proc/sys/net/core/netdev_max_backlog # socket buckets echo 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets # port range echo '16384 65535' > /proc/sys/net/ipv4/ip_local_port_range
Following are some tuning optimizations applicable to both FreeBSD 4 and FreeBSD 5.x/6.x.
SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10" ulimit -n 16384
A /boot/loader.conf.local file can be used to set boot-time kernel parameters:
# increase the TCP connection hash to a value just greater than peak needs # (this can be set higher if necessary) net.inet.tcp.tcbhashsize="16384"
The Loader configuration file /boot/loader.conf should be modified:
kern.maxdsiz="1G" # max data size kern.dfldsiz="1G" # initial data size limit kern.maxssiz="128M" # max stack size kern.ipc.nmbclusters="65536" # set the number of mbuf clusters net.inet.tcp.tcbhashsize="16384" # size of the TCP control-block hashtable
# cache dir locations, on by default vfs.vmiodirenable=1 # increase socket buffers kern.ipc.maxsockbuf=1048576 kern.ipc.somaxconn=4096 # increase default buffer size net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=65536 # decrease time wait net.inet.tcp.keepidle=300000 net.inet.tcp.keepintvl=30000 # increase vnodes kern.maxvnodes=131072 # increase maxfiles/maxfiles per process kern.maxfiles=131072 kern.maxfilesperproc=65536 # increase port range net.inet.ip.portrange.last=65535 # default: net.inet.ip.rtexpire: 3600 net.inet.ip.rtexpire=300 # decrease MSL from 30000 net.inet.tcp.msl=10000
HP-UX kernel parameters for HP-UX are set through a few different mechanisms, depending on the HP-UX version used. The following kernel parameters are important to increase higher than peak capacity needs:
maxfiles Soft file limit per process maxfiles_lim Hard file limit per processes maxdsiz Maximum size of the data segment nfile Maximum number of open files ninode Maximum number of open inodes # suggested parameter settings maxfiles 4096 maxfiles_lim 32768 maxdsiz (2048*1024*1024) nfile 32768 ninode 32768Decreasing the TCP TIME_WAIT parameter is also recommended:
ndd -set /dev/tcp tcp_time_wait_interval 60000
The Mac OS X sets a 6MB limit on "additional" virtual memory an application can allocate. This is not enough for sites with more than 2,000 users, and you should increase that limit by specifying the following in the CommuniGate Pro Startup.sh file:
ulimit -d 1048576 ulimit -n 16384