CommuniGate Pro
Version 5.1
システム
 
 
 
拡張性

拡張性

CommuniGate Pro は柔軟です。このセクションでは、CommuniGate Pro とサーバーOS を最適化し、 サーバーあたりの容量と性能を最大限まで引き出す方法について説明します。

水平スケーリング(横方向の拡張) とマルチサーバーリダンダンシーについては、クラスタのセク ションにも説明があります。


大規模ドメイン

ドメインのアカウント数が多い場合(例えば、2000 以上)、通常のフラットドメインディレクトリで はなく、アカウントサブディレクトリにアカウントを格納するようにします。このことは、ファイル システムのディレクトリインデックスに格納されるエントリリスト、また、ファイルシステムの種類 によってエントリの最大数が大きく異なることに関係しています。

例えば、ハッシュディレクトリインデックスを使用するファイルシステムは、通常のフラットディレ クトリインデックスを使用するファイルシステムに比べて、ディレクトリインデックスに対して効率 よくアクセスできます。実際、ファイルシステムによっては、エントリ数が50,000 を超えるインデッ クスにも容易にアクセスできますが、別のファイルシステムではわずか1,000 エントリで動作が遅く なることもあります。

上と同じ理由で、サーバーまたはクラスタ上のドメインの数が2,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] にあります)。


同時セッションのサポート

大規模環境の場合、同時に通信を行うユーザーが多く、この問題が重要になります。同時に処理でき るセッションの数(同時セッション数) は、次のようにして予測できます。予測の方法は、クライア ントソフトウェアで使用されるサービスの種類によって異なります。以下、順に説明します。

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

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

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

IMAP は、「メールアクセス」プロトコルであり「メールダウンロード」プロトコルではありま せん。そのため、IMAP ユーザーがサーバーに接続している時間はPOP3 ユーザーよりかなり長 いのが普通です。企業環境では、数日とは言わないまでも数時間、IMAP セッションをオープン のままにしておくこともあります。この状態は、いわゆる非アクティブセッションで、ディス クやネットワークI/O サブシステム、CPU には負荷はかかりませんが、それでもオープンネッ トワーク接続や処理スレッドという面ではサーバーに負荷があります。また、IMAP プロトコル の場合、ユーザーはサーバーに対する検索処理が可能であり、この機能を頻繁に使用するとCPU リソースの消費が大きくなります。

IMAP 接続またはPOP 接続の数が多いときには、IMAP やPOP のチャンネル数を多めに設定し ます。これで、同時に接続するユーザーの数が多くても対応が可能です。なお、最近のIMAP ク ライアントやMAPI コネクタでは単一のアカウントについて複数の接続がオープンされることも あり、その場合、複数の接続がそれぞれ一つのIMAP チャンネルとしてカウントされます。幸 い、IMAP チャンネルやPOP チャンネルは実際に使用されるときに生成されるため、チャンネ ル数を10000 も設定しておいても、実際の使用チャンネル数が2000 であれば、その分しかリ ソースは消費されません。 ただし、チャンネル数をあまり大きくすると、今以上の接続をシステムが処理できなくなった り、接続済みのユーザーに対して応答が実行されなくなったりするため、適当な閾値に設定しておくことが必要です。つまり、IMAP やPOP のチャンネル数は、負荷がピークになったとき やDoS 攻撃があったときでもシステムやクラスタのリソースが枯渇しない範囲で設定すること が重要です。

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

この仕様により、サーバー上では100 のHTTP 接続で3,000 以上のオープンセッションの処理 が可能です。

CommuniGate Pro はまた、HTTP 1.1 のキープアライブ機能をサポートしています。この機能は、 WebUser インターフェイスの[Settings] ページの[Support Keep-Alive] オプションをオンにす ることで有効にできます。このオプションを有効にしておくと、Web ユーザーが単一もしくは 複数のオープン接続を使ってクライアントとサーバーとの間でWebUser セッションを行ってい る場合、そのセッションの間、接続が維持されます。ただし、この機能は、通信が混み合う大容量サーバーではあまり推奨できません。CPU とオペ レーティングシステムのリソースが相当消費されるためです。一方、システムである程度オー バーヘッドが処理できるときには、WebUser 応答時間を最適化できるため有用です。キープア ライブ機能は、クラスタの場合、フロントエンドサーバーでのみ有効です。

SIP/RTP クライアント
メッセージングの場合、ディスクI/O はそれほど多くなくはありません。これとは異なり、SIP/ RTP データはリアルタイム処理が多く、小さな処理(SIP REGISTER など) でもディスクI/O が 発生します。リアルタイムトラフィックは、 ネットワークやシステムのレイテンシが非常に発 生しやすく、その結果、電子メールのトラフィックに比べて処理速度はCPU 性能に大きく依存 します。といっても、最近のCPU は処理速度、バス速度とも向上しており、リアルタイム処理 でも問題はなくなってきています。

SIP/RTP 性能の点から考慮して、CommuniGate Pro サーバーはできるだけ、CPU とメモリに余 裕のある最新のシステムで動作させるようにします。具体的には、CommuniGate Pro が扱うトラ フィックがほとんどSIP シグナリングトラフィックであれば、シングルCPU サーバーでも秒あ たり100 以上のコールを処理できます。一方、SIP/RTP プロキシング、NAT トラバーサル、PBX機能、メディアターミネーションなどの処理がかなり多いときには、メモリやネットワークの ほか、とくにCPU に対する負荷は極めて大きくなります。
このような環境の場合、SIP サーバーSIP クライアント のプロセッサ(スレッド) 数、またSignalプロセッサのプロセッサ数を増やすことが必要です。
なお、上記のスレッドはいずれも「スタティック(静的)」スレッドです。つまり、実際に使用 されるかどうかにかかわらず生成され、したがって各スレッドスタックについてそれぞれメモ リリソースが消費されます。


システムチューニング

一般にシステムには、カーネルやTCP/UDP スタックのチューニングに関するオプションが用意され ており、こうしたオプションを使うことで、同時オープンのネットワーク接続数を増やしたり、 CommuniGate Pro プロセスで多数のファイルディスクリプタをオープンできるように設定できます。 こうしたチューニングオプションはほとんどのオペレーティングシステムでサポートされています が、設定の方法はシステムによって大きく異なります。そのため、事前にオペレーティングシステム のベンダに問い合わせたり、具体的な設定方法を調査するのが安全です。

例えば、利用可能(オープン可能) なファイルディスクリプタの数は、IMAP、POP、SMTP、SIP/ RTP ( コンカレント) 接続、その他の接続の必要数の2 倍に設定します。また、こうした接続に対し て十分な数のTCP/UDP ソケットが開かれるように設定することも必要です。OS によっては「ハッ シュテーブル」を使ってソケットの管理を行うものもあり、その場合、このテーブルの値を必要なソ ケット数より大きくしておかなければなりません。 通常のシステムの場合、プロセスあたりソケット数を8192、ファイルディスクリプタ数を16384 に 設定しておけば十分で、これで負荷が大きいケースでも対応できます。ソケット数とファイルディス クリプタ数をあまりにも大きくしすぎると、メモリリソースの消費が増えるので注意が必要です。ま た、オープン可能なファイルディスクリプタ数を「無制限」に設定すると、オペレーティングシステ ムによっては問題が生じます。「無制限」に設定した場合、オープン可能なファイルディスクリプタ の数が32 ビットまたは64 ビットの上限まで設定され、その結果、メモリリソースやCPU リソース に無駄が生まれることがあります。

TCP TIME_WAIT時間の設定

TCP/IP 接続の数が多い場合、サーバーOS の待機時間、つまり論理的にクローズされているTCP/IP ソケットが解放されるまで時間(TIME_WAIT 時間) の設定が重要になります。この待機時間が長すぎると、こういった「眠っている」ソケットによってOS のTCP/IP リソースがすべて消費されてしま うことがあります。また、新規の接続がすべてOS レベルで拒否されるといったことも起こります。 こういった状態になると、CommuniGate Pro サーバーから警告メッセージが出力されなくなります。

上の問題は、アカウント数が数百という小規模のサイトでも発生することがあります。つまり、ユー ザーがサーバーのメールをチェックする頻度が非常に高い場合、この問題が発生します。例えば、 ユーザーが1 分間に一度サーバーに接続し、OS のTIME_WAIT 時間が2 分間に設定されている場合、 「眠っている」ソケットの数は次第に増え、最後にはOS のTCP/IP リソースが残らず消費されてし まいます。

CommuniGate Pro がサポートしているオペレーティングシステムのうち、多くのシステムでは、デ フォルトのTIME_WAIT 設定は120 秒ないし240 秒です。また、オペレータによっては、デフォルト のTIME_WAIT 値は60 秒になっています。ただし、この設定は多少大きいようで、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)

ほとんどのシステム(Linux、FreeBSD、Solaris、Windows) ではx86 HyperThreading は完全にはサ ポートされていません。

マルチコア/ マルチCPU テクノロジーは相当の性能向上が見られますが、これとは異なり、 HyperThreading では性能の向上はほんの少しです(まったく向上しないこともあります)。その一方、 スレッドライブラリがクラッシュする、負荷の大きい状況ではNFS の性能が低下するなどの問題が あります。したがって、一般的にはHyperThreading は無効にしておいた方が賢明です。サーバーの BIOS 設定で無効にできます。


大容量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 トラフィックが大きくなります。

SMTP 外部メッセージフィルタ (プラグイン)、つまりアンチウィルス、アンチスパムなどのコンテ ントフィルタリングヘルパーを使用する場合、プラグインが使用する暫定ファイルディレクトリをメ モリやtmpfs システムに格納することでSMTP 負荷を最適化できます(ただし、十分なメモリが必要 です)。この場合、実際のメッセージはすべてCommuniGate Pro のキュー(Queue) ディレクトリに キューされるため、暫定ファイルディレクトリを使ってもリスクはありません。つまり、メッセージは暫定ファイルディレクトリだけでなく、CommuniGate Pro のキューディレクト リにも格納されます。このキューディレクトリは「安全な格納場所」であり、エラーや停電、サー バークラッシュが発生しても、その中の未配信メッセージは消失することはありません。


リソース使用状況の予想

ネットワーク接続にはそれぞれネットワークソケットディスクリプタ(ソケット/ ファイルディスク リプタ) が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 (ただし、ユーザースペースプ ロセス用の仮想メモリ上限は通常2GB) であり、したがってページスワッピングに4GB を超えるディ スクスペースを割り当てても効果はありません。また、最近はメモリの価格もかなり下がっているた め、32 ビットシステムにはできるだけ4GB のRAM メモリを搭載するようにします。これで利用可能 なメモリ容量をフルに使用できると同時に、単一のプロセスで2GB 以上の仮想メモリ空間を使用でき るという環境が整います。CommuniGate Pro の場合、コンカレント(同時) のIMAP、POP3、SIP/RTP 接続の数が増えると、ス レッドあたりの割り当て済みスタックスペースや、その他のメモリ必要量の関係でCGServer プロセ スのサイズが大きくなります。具体的には、処理スレッドの数が4000 を超えるようなときには、 CGServer プロセスに2GB 以上の仮想メモリを割り当てられるようなオペレーティングシステムを使 用し、そのシステムに4GB のRAM メモリを搭載することを推奨します。

POP3 またはIMAP4 のアクセスセッションの場合、アカウントのメールボックスのいずれか一つが開 きます。例えば、メールボックスがテキストファイル(BSD タイプ) のときには、メールボックス ファイルが開きます。また、受信SMTP セッションでは、受信メッセージについて暫定ファイルが作 成され、そのファイルはメッセージが取り出されている間、オープンの状態に置かれます。したがっ て、UNIX システムの場合、オープンしているPOP、IMAP、SMTP の各接続の合計数が、プロセスあ たりのソケット/ ファイルディスクリプタの最大数の2 分の1 を超えないようにしなければなりませ ん。例えば、高性能システムの場合、プロセスあたりのファイルディスクリプタ数として8192 以上を 設定しておくのが適当です。

WebUser セッションでは、ネットワーク接続は不要(したがってソケットとスレッドも不要) である ため、同時に複数のメールボックスを開いておくことができます(ただし、HTTP キープアライブ機 能を使用している場合、各WebUser セッションでそれぞれネットワーク接続が一つ消費されます)。

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


OS の制限とチューニング

CommuniGate Pro でサポートしているオペレーティングシステムの中には、カーネル/TCP チューニ ングパラメータが用意されているシステムがあります。ここでは、こうしたパラメータについて説明 します。主なパラメータは、次の2 つです。

カーネル/TCP チューニングパラメータを変更するときには必ずベンダーに詳細を問い合わせるとと もに、変更をテストシステムで検証してから実際にシステムを動作させるようにしてください。また、 チューニングパラメータの理想設定値は、オペレーティングシステムのバージョン、パッチ、ハード ウェア、負荷要件などによって異なりますので注意が必要です。下記の例はあくまで参考であり、実 際のシステムに必ずしも適当であるとは限りません。

Solaris

基本的にSolaris 8、9、10 が対象

CommuniGate Pro の"Startup.sh" ファイル

Startup.sh は、デフォルトでは/var/CommuniGate/Startup.sh で参照が可能ですが、場合によっ ては作成しなければならないこともあります。このファイルはスタートアップスクリプト/etc/ init.d/STLKCGPro.init によって読み込まれ、ブート時に実行されます。下は、CommuniGate Pro バージョン4.3 以降、Solaris 主要バージョン用のStartup.sh ファイルです。状況によっては、ファイ ルディスクリプタの数を増やさなければならないこともあります。この数は、"ulimit -n" の行で指定 できます。通常、32768 までは安全です。
SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10"
ulimit -n 16384

ncsize

CommuniGate Pro システムが大きい場合、とくにダイナミッククラスタのバックエンドの場合、Solarisのncsize カーネルパラメータを減らすことが必要です。このパラメータはキャッシュサイズ制御の ためのパラメータですが、キャッシュのサイズを大きくしてもファイルパスが効果的に保持されるこ とはありません。逆に、キャッシュテーブルのチェックにCPU がかなり浪費されます(CPU 使用率 が50%以上に増加し、カーネルの処理にほとんどのCPU 時間が使われるなどの問題が発生します)。 したがって、このncsize カーネルパラメータの値は、1000 ~ 2000 に下げます。   以下、システムがSolaris で、かなり大きな負荷容量が必要な場合の各種設定値について説明します。 下記の設定の値は通常、予想最大容量と同じか、その2 倍までの範囲が適当です。

/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.

* システムファイルディスクリプタ上限(システムによっては、max を32768 にするのが適当)
set rlim_fd_cur=4096
set rlim_fd_max=16384
* tcp 接続のハッシュサイズ
set tcp:tcp_conn_hash_size=16384
注意: /etc/system を変更した場合、システムをリブートしなければなりません。これで変更が有効 になります。

その他のカーネルドライバオプション

# solaris 9/10 のデフォルト値は49152
ndd -set /dev/tcp tcp_recv_hiwat 49152 # or 65536
ndd -set /dev/tcp tcp_xmit_hiwat 49152 # or 65536
# 接続キューを増加
ndd -set /dev/tcp tcp_conn_req_max_q 512
ndd -set /dev/tcp tcp_conn_req_max_q0 5120
# タイマを減少
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 は、バックエンドのときには無効に設定 
## 1= 無効、デフォルトは53 (確認困難)
# 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.

詳しくは、Microsoft Support Article Q196271を参照してください。

Linux

CommuniGate Pro の"Startup.sh" ファイル

Linux の場合、Startup.sh は、デフォルトでは/var/CommuniGate/Startup.sh で参照が可能です が、場合によっては作成しなければならないこともあります。このファイルはスタートアップスクリ プト/etc/init.d/STLKCGPro.init によって読み込まれ、ブート時に実行されます。下は、 CommuniGate Pro バージョン4.3 以降、Linux バージョン2.4 以降用のStartup.sh ファイルです。状況 によっては、ファイルディスクリプタの数を増やさなければならないこともあります。この数は、 "ulimit -n" の行で指定できます。通常、32768 までは安全です。

SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10"
ulimit -n 16384

Linux カーネル2.2 と、それ以前

Linux カーネル2.2.x より前のバージョンでは、単一のプロセスでオープンできるファイルディスクリ プタの数は256 でした。したがって、サーバーで100 以上のTCP/IP 接続を扱いたいときには、 Linux カーネル2.2.x 以降を使用しなければなりません。2.2.x 以降では、「アウトオブファイルディスクリプ タ」問題は発生しません。

Linux のスレッドライブラリは1 対1 モデルであり、そのためCommuniGate Pro のスレッドはそれぞ れ一つのカーネルスレッド(プロセス) として扱われます。この方式は、規模が非常に大きく数千と いうスレッドが動作するシステムでは、必ずしもベストではありません。

Linux の場合、スレッドはカーネル内部で処理されるため、スレッドライブラリも同じくカーネル内 部で処理されるのが普通と思われますが、これに反してLinux のスレッドライブラリには専用のスケ ジューラがあります。このスケジューラでは、デフォルトではエントリ数が1024 の静的テーブルが使 われます。そのため、1024 以上のスレッドは生成されません。ユーザーがPOP とWebMail のユーザーだけであれば、サイトが大きくても、この仕様で十分です。一方、同時IMAP ユーザーが数百という サイトの場合には問題が起こるため、スレッド数を増やさなければなりません。スレッド数を増やす には、パラメータPTHREAD_THREADS_MAX の値を変更し、Linux のスレッドライブラリを再コンパイ ルします。

Linux のスレッドライブラリでは、2MB のステップ(サイズ) でスレッドスタックが割り当てられま す。この仕様により、32 ビットマシンで起動できるスレッド数は1000 に限定されます。CommuniGate Pro では、このサイズのスタックは必要ありません。スタックサイズを小さくしてスレッド数を増や すようにします。方法は、STACK_SIZE パラメータの値を128K に変更し、Linux のスレッドライブラ リを再コンパイルします。

Linux カーネル2.4

Linux カーネル2.4 では、重要なチューニングオプションのほとんどを簡単に設定できるように改良さ れました。ただし、2.4 の配布バージョンによっては、PTHREAD_THREADS_MAX の値はまだ1024 か、 それ以下に設定されていることもあります。その場合、PTHREAD_THREADS_MAX の値を大きくし、 スレッドライブラリを再コンパイルしなければなりません。また、Linux カーネル2.4 の配布バージョ ンは、そのほとんどで"LinuxThreads" を基本にしたスレッドライブラリ(従来からのライブラリ) が 使用されています。 ただし、2.4 の配布バージョンの一部では、新しいPOSIX スレッドライブラリが使われる製品もあり ます。このPOSIX スレッドライブラリをカーネル2.4 で使用すると、CommuniGate Pro を含め、多く のアプリケーションで安定性上の問題が発生することが分かっています。したがって、カーネル2.4 でCommuniGate Pro を動作させる場合、従来の"LinuxThreads" ベースのスレッドライブラリを使用す るようにしてください。スタートアップファイル/etc/init.d/CommuniGate では、"LinuxThreads" ベースのスレッドライブラリが使用されるように設定されています(デフォルト)。
LD_ASSUME_KERNEL=2.4.1
export LD_ASSUME_KERNEL

以下は、Linux 2.4 の上記以外のチューニングオプション(シェルコマンド) です。各シェルコマンド はいずれも、ほとんどのバージョンの場合、ブートスクリプトとしてシステムスタートアップ時に実 行されるようにしておかなければなりません。また、RedHat などでは、ファイル/etc/sysctl.conf に"sysctl" データを設定するためのファシリティが用意されています。

#!/bin/sh
# Linux 2.4 チューニングスクリプト
# 最大オープンファイル
echo  131072 > /proc/sys/fs/file-max
# カーネルスレッド
echo 131072 > /proc/sys/kernel/threads-max
# ソケットバッファ
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
# ソケットバケット
echo 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets
# ポート範囲
echo '16384 65535' > /proc/sys/net/ipv4/ip_local_port_range
注意:カーネル2.4、2.6 の場合、CommuniGate Pro サーバーでNETFILTER (iptables) が不要であれば、こ のiptables を削除してカーネルをコンパイルします。ネットワーク性能が大幅に向上します。

Linux カーネル2.6 以降

Linux カーネル2.6 では、従来のLinuxThreads ベースのスレッドライブラリの代わりに"POSIX スレッ ド" が導入されました。カーネル2.6 は、POSIX スレッドの使用が推奨されるLinux としては初めて のリリースです。カーネル2.6 (カーネル2.6 がデフォルトのカーネルであるバージョン) とPOSIX スレッドを使用したい場合、スクリプト/etc/init.d/CommuniGate を変更します。変更は、次の 行をコメントアウトするという方法で可能です。
# LD_ASSUME_KERNEL=2.4.1
# export LD_ASSUME_KERNEL

上の行をコメントアウトすることにより、POSIX スレッド共有ライブラリ(場所は/lib/tls/) が デフォルトでリンクされるようになります。

以下は、Linux 2.6 の上記以外のチューニングオプション(シェルコマンド) です。各シェルコマンド はいずれも、ほとんどのバージョンの場合、ブートスクリプトとしてシステムスタートアップ時に実 行されるようにしておかなければなりません。また、RedHat などでは、ファイル/etc/sysctl.conf に"sysctl" データを設定するためのファシリティが用意されています。
#!/bin/sh
# Linux 2.4 チューニングスクリプト
# 最大オープンファイル数
echo  131072 > /proc/sys/fs/file-max
# カーネルスレッド数
echo 131072 > /proc/sys/kernel/threads-max
# ソケットバッファ
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
# sソケットバケット
echo 131072 > /proc/sys/net/ipv4/tcp_max_tw_buckets
# ポート範囲
echo '16384 65535' > /proc/sys/net/ipv4/ip_local_port_range

FreeBSD

以下、FreeBSD 4 とFreeBSD 5 の場合のチューニングについて説明します。

CommuniGate Pro の"Startup.sh" ファイル

FreeBSD の場合、Startup.sh は、デフォルトでは/var/CommuniGate/Startup.sh で参照が可能で すが、場合によっては作成しなければならないこともあります。このファイルはスタートアップスク リプト/usr/local/etc/rc.d/CommuniGate.sh によって読み込まれ、ブート時に実行されます。 下は、CommuniGate Pro バージョン4.3 以降、FreeBSD のほとんどのバージョン用のStartup.sh ファイ ルです。状況によっては、ファイルディスクリプタの数を増やさなければならないこともあります。 この数は、"ulimit -n" の行で指定できます。通常、32768 までは安全です。
SUPPLPARAMS="--DefaultStackSize 131072 --useNonBlockingSockets --closeStuckSockets --CreateTempFilesDirectly 10"
ulimit -n 16384

/boot/loader.conf.local ファイルを使って、ブート時のカーネルパラメータを設定できま

# TCP 接続ハッシュの値を増やす。値は、ピーク容量より若干高めに設定
# (ただし、必要であれば、それ以上に設定可能)
net.inet.tcp.tcbhashsize="16384"

下は、デフォルトデータサイズ、最大データサイズ、最大スタックサイズ、nmbclusters の各設定です。

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

FreeBSD 5 では、マルチプルCPU 用のSMP がフルにサポートされています。CommuniGate Pro は相当 のスレッドリソースが必要ですが、その点では、FreeBSD 5 はよく最適化されたシステムといえます。 FreeBSD 5 では、Sysctl 設定を自動的に/etc/sysctl.conf ファイルに保存することができます。
# ソケットバッファを増加
kern.ipc.maxsockbuf=1048576
kern.ipc.somaxconn=4096
# デフォルトバッファサイズを増加
net.inet.tcp.sendspace=65536
net.inet.tcp.recvspace=65536
# time wait を減少
net.inet.tcp.keepidle=300000
net.inet.tcp.keepintvl=30000
# vnodes を増加
kern.maxvnodes=131072
# 最大ファイル数/ プロセスあたりの最大ファイル数を増加
kern.maxfiles=131072
kern.maxfilesperproc=65536
# ポートの範囲を増加
net.inet.ip.portrange.last=65535
# デフォルト: net.inet.ip.rtexpire: 3600
net.inet.ip.rtexpire=300
# MSL を30000 から低い値に減少
net.inet.tcp.msl=10000

HP-UX

HP-UX の場合、カーネルパラメータの設定方法はHP-UX のバージョンによって多少異なります。と くに下記のカーネルパラメータの値は重要で、いずれもピーク容量より大きくしておく必要がありま す。

  maxfiles      プロセスあたりのファイル最大数(論理)
  maxfiles_lim  プロセスあたりのファイル最大数(物理)
  maxdsiz       データセグメントの最大サイズ
  nfile         同時にオープンするファイルの最大数
  ninode        同時にオープンするinode の最大数
  
  # 以下、各パラメータの推奨値
  maxfiles      4096
  maxfiles_lim  32768
  maxdsiz       (2048*1024*1024)
  nfile         32768
  ninode        32768

また、TCP のTIME_WAIT の値を小さくしておくことを推奨します。

ndd -set /dev/tcp tcp_time_wait_interval 60000

Mac OS X

Mac OS X の古いバージョンでは、プロセスあたりのディスクリプタの最大数(物理) の値がデフォ ルトで1600 ~ 1800 に設定されていることがあります。CommuniGate Pro バージョン5.0 では、この 値は8192 に設定されます(静的に固定)。

Mac OS X の場合、「追加」仮想メモリ(アプリケーションが割り当てできる仮想メモリ) の上限値と して6MB が設定されています。この値は、ユーザー数が2,000 を超えるサイトでは不十分なため、増 やすことが必要です。増加は、CommuniGate Pro のStartup.sh ファイルに次の行を定義することで可 能です。

ulimit -d 1048576
ulimit -n 16384

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