新経理システムのカットオーバを迎えて、N社内の担当者は新しいシステムに期待して端末から処理を始めました。ところが、何人かの担当者から「応答が遅い」、「接続できなくなる」などのクレームが上がってきました。その日の伝票処理が終わらない可能性がある・・・そこでシステムの開発ベンダーが調査を始めました。「こんなハイエンドサーバなのに何でぇ!?」。応答性能は極めて悪く、カットオーバ前のテストと大きく異なるレスポンスに一同あ然としていました。20クライアントでやっと1秒の応答って事は20件/秒? ひど過ぎる!!

システム性能情報分析ではCPU使用率が高いことを除けば、メモリ消費量、ディスク入出力とも異常無し。CPU使用率は常に70%を超えています。特にシステムCPUが高い!! あるエンジニアが、ネットワーク接続情報がおかしいことに気付きました。netstat -nの表示でTIME_WAIT状態の接続がゴマンとある!? いくらハイエンドサーバと言っても5万(ゴマンの駄洒落ではありません)のコネクションテーブルを持っているとタイマー処理が大変です!!

tcp_time_wait_interval【備考】を240秒から3秒に設定変更しました。TIME_WAITコネクションは激減。システムCPU使用率も劇的に低くなり、クライアントのレスポンスが良くなりました。 【備考】S社サーバの場合、nddコマンドで設定。

この問題に最初に遭遇したのは1995年頃です。エンジニア達はtcp_time_wait_intervalの値を小さくすることに躍起になりました。1秒という設定も見たことがあります。しかし、近年、ハードウェア性能が向上し、またマナーの良いクライアントソフトウェアが浸透して、システムのデフォルトで問題無くなってきました。Linuxでは60秒がデフォルトです。もし60秒で問題が発生した場合は5秒にすると良いとの情報が多く見られます。繁忙時の接続数を監視して適切に設定することが望ましいと考えます。

■効果：5倍の性能向上!!

■コスト：1人1日あたり4万円が8千円、年間720万円のお得!!

余談

:

システム待ち状態が解消され、仕事がテキパキ進むようになったので、人件費は1/5(とまではいかないか?)に。また、気持ち良く仕事がはかどるのでメンバー間のコミュニケーションも向上したとのことです。ヨカッタヨカッタ!!