CommuniGate Pro
Version 5.2
システム
 
 
 
拡張性

拡張性

このセクションでは、大規模なサイト(アカウント数10,000 ~ 100,000) でCommuniGate Pro を使用 する場合のCommuniGate Pro の設定について、また、サーバーOS の設定について説明します。

キャリア(通信事業) レベルのサイト(アカウント数100,000 ~数百万まで) の場合、マルチサーバークラスタ環境を構築します。


大規模ドメイン

ドメインのアカウント数が多い(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 や企業の大規模システムの場合、ユーザーからの要求(セッション) を同時にどれだけ処理でき るかが重要な問題になります。

同時に処理できるセッションの数(同時セッション数) は、次のようにして予測できます。予測の方 法は、クライアントソフトウェアで使用されるサービスの種類によって異なります。以下、順に説明 します。

POP3 クライアント
POP3 メーラーでは、処理は新規メッセージのダウンロードに限られ、その他の処理は行われま せん。したがって、同時セッション数を予測したい場合、まず、平均接続速度や予想メールト ラフィック、ユーザーがメーラーを使用する頻度や時間帯などを基に、平均セッション時間(新 規メッセージのダウンロード時間) を計算します。その後、POP3 の同時セッション数を求めま す。例えば、ISP で、ユーザーが「メールチェック」を完了するまでの平均時間が15 秒で、ほとんどのユーザーが昼間の時間帯(12 時間) にメールボックスをチェックし、また、ユーザー 数が100,000 人だったとします。この場合、100,000 * 15 秒/ (12*60*60 秒) = 35 同時POP3 セッ ション、つまり同時セッションの数は35 となります。

この35 という同時セッション数は、それほど高い数値ではありません。ただし、POP3 セッショ ンでは、ローカルのディスクI/O とネットワークI/O サブシステムに大きな負荷がかかります。 これは、POP3 では、認証後にユーザーが行う処理は、基本的に「ファイルダウンロード」形式 の処理であるためです。

IMAP4 クライアント
IMAP プロトコルでは、POP3 に比べてはるかに「洗練された」処理が可能です。つまり、IMAP の場合、ユーザーは、メールをサーバーに置いたままでチェックでき、また、ダウンロードす る必要のないメッセージは削除するという処理を行えます。

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.

WebUser クライアント
CommuniGate Pro のWebUser インターフェイスには、IMAP メーラークライアントと同じ機能が 搭載されています。ただし、各セッションについてオープンネットワーク接続(それに処理ス レッド) は必要ありません。WebUser インターフェイスの場合、メーラークライアント(また はブラウザ) から要求が出力されると、ネットワーク接続が確立されます。その後、要求がサー バースレッドで処理され、接続が閉じます。したがって、IMAP と異なり、オープンネットワー ク接続は不要です。

この仕様により、サーバー上では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.

SIP/RTP Clients
As compared to messaging, which tends to be very disk I/O-limited, SIP and RTP data has real-time requirements and only a few actions (such as a SIP REGISTER) cause any disk I/O. Real-time traffic is highly susceptible to any network or system latency, and as such is more closely tied to CPU performance than E-mail transfer. However, these real-time requirements can be satisfied through today's ever increasing CPU and bus speeds.

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 など) とユーザー数をもとに、 サーバーの動作に必要なリソースを予想できます。


System Tuning

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 TIME_WAIT 時間の設定

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 倍にするのが妥当と記載されているためです。

HyperThreading

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 デリバリの処理

SMTP デリバリ負荷が大きい(50 メッセージ/ 秒を超える) 場合、DNS サーバー(単一もしくは複数) の能力をチェックし、CommuniGate Pro によって生成される負荷がDNS サーバーで十分に処理される かどうかを確認します。また、CommuniGate Pro とDNS サーバーの間で交換されるUDP パケットに 過剰なパケットロスが発生しないようにしておくことも必要です。さらに、ルータを再設定し、TCP トラフィック上でのUDP トラフィックの優先度を上げることが必要な場合もあります。

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 サーバーにより、オープンしているソケット/ ファイルディ スクリプタの数が上限に近づいていることが検出されると、受信接続の拒否が開始されます。また、 ログを介して、この処理に関する情報が報告されます。


OS の制限とチューニング

ここでは、各オペレーティングシステムで使われている制限値のチェック、また、値の調整について 説明します。ここで説明する制限値は、主に次の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.

Solaris

Generally applicable to Solaris 8, 9, and 10

CommuniGate Pro "Startup.sh" file

Startup.sh is by default referenced at /var/CommuniGate/Startup.sh. You may need to create it. This file is read by the init startup script /etc/init.d/STLKCGPro.init to be executed at boot time. The following is a Startup.sh file for CommuniGate Pro version 4.3 or later for most Solaris implementations. 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

ncsize

Solaris では、システムが大規模の場合、カーネルパラメータncsize の値を低く設定する必要がありま す。とくに、ダイナミッククラスタバックエンドを使用している場合、この操作が必要です。ncsize はキャッシュパラメータですが、そのサイズを大きくしても、ファイルパスが効率よく格納されるこ とはありません。逆に、キャッシュテーブルのチェックが頻繁に実行され、CPU サイクルがかなり浪 費されます(具体的には、CPU 利用率が50%超となり、またCPU 時間のほとんどがカーネルに使わ れます)。このため、ncsize カーネルパラメータの値は1000 ~ 2000 に下げておくことが必要です。

Additions to /etc/system

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=16384
Note: /etc/system changes require a system reboot to take effect.

Other kernel driver options:

# 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

Windows 9x/NT/200x/XP

Windows システムでは、送信接続の最大ポート数はデフォルトでは5000 に設定されています。この値 は、CommuniGate Pro サーバーを使う場合には小さすぎるため、20,000 以上に上げます。変更する場 合、次のキーにDWORD のエントリとしてMaxUserPort を追加します。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters key.

For more details, check the Microsoft Support Article Q196271.

Linux

CommuniGate Pro "Startup.sh" file

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

Linux kernel 2.2 and eariler:

カーネルバージョンが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 スレッ ドライブラリを再コンパイルします。

Linux kernel 2.4:

Linux kernel 2.4 allows for most important tuning options to be easily configured. In some 2.4 distributions, however, PTHREAD_THREADS_MAX may still be compiled at 1024 or another similarly low number - if this is the case, the Linux threads library must be recompiled with the PTHREAD_THREADS_MAX parameter increased. Most Linux 2.4 distributions are based on the "LinuxThreads" threading library. There are some Linux 2.4 distributions which have attempted to back-port the newer POSIX threading library to the 2.4 kernel - in some instances, running POSIX threads with 2.4 kernel has proven to cause stability problems for many applications, including CommuniGate Pro. It is recommended to use the LinuxThreads library with CommuniGate Pro when running the 2.4 kernel. This is provided for (by default) in the /etc/init.d/CommuniGate startup script:
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_range
Note: 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.

Linux kernel 2.6 and later:

Linux kernel 2.6 introduced "POSIX threads", replacing the previous default thread library "LinuxThreads". Kernel 2.6 implementations are the first Linux release for which using POSIX threading is recommended. If using Linux kernel 2.6 and POSIX threading (and preferably using a distribution for which kernel 2.6 was the default kernel), then the /etc/init.d/CommuniGate init script should be modified to comment out the following lines:
# 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

FreeBSD

Following are some tuning optimizations applicable to both FreeBSD 4 and FreeBSD 5.x/6.x.

CommuniGate Pro "Startup.sh" file

Startup.sh is by default referenced at /var/CommuniGate/Startup.sh. You may need to create it. This file is read by the init startup script /usr/local/etc/rc.d/CommuniGate.sh to be executed at boot time. The following is a Startup.sh file for CommuniGate Pro version 4.3 or later for most FreeBSD implementations. 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

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

FreeBSD 5 and above

Sysctl settings 5 can be set automatically in the /etc/sysctl.conf file:
# 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

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        32768

Decreasing the TCP TIME_WAIT parameter is also recommended:

ndd -set /dev/tcp tcp_time_wait_interval 60000

Mac OS X

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

CommuniGate® Pro Guide. Copyright © 1998-2007, Stalker Software, Inc.