Solaris10カーネルチューニング２

それにしてもここまで細かい設定をしなければならないのだろうか。
VineLinux3.2でTCPバッファの大きさまで検討したことはなかったけれど、リンクダウンしたことは一度もなかった。
（実際にはリンクダウンしていたけれど表示されていなかっただけかもしれませんが、速度は十分速かったので、リンクダウンしていたとも思えません。）
Solaris10は元々サーバー用なので、LANのトラフィックの状態によって細かく設定ができる方が望ましいのかもしれませんが、既定値で使用していてリンクダウンするのはおかしいでしょう。NICのハードがらみの問題でエラーがでているのかもしれませんが、100Base/TのNIC位メーカーに頼らず、OS側でサポートできないものだろうか。
少し酷すぎるんではないかと思う。

Solaris10カーネルチューニング１

「Solarisカーネルのチェーンアップ・リファレンスマニュアル」（2006年11月）に「これまで動作させるためにシステムチューニングが必要だったアプリケーションの多くは、デフォルト値の資源の自動割り当てにより、チューニングしなくても動作する可能性があります。」なんて書いてあるものだから、よくわからないのも手伝ってチューニングしなくてもよいかと思っていました。
実際、Linuxで設定していた共有メモリもデフォルトで「物理メモリーの１／４」割り当てられれいて、今回2Gbyteの実メモリなら500Mbyteが共有メモリーに割り当てられていることになります。データベースをダンプした時の大きさが約150Mbyteなので、共有メモリが500Mbyteなら十分ではないかと思いました。
Vine3.2の時は
　kernel.shmmax = 268435456　（256M)
としていました。
しかし、以前書いたSambaでのファイル転送でリンクダウンしてしまう現象が多発してしまい、売上伝票起票時にもリンクダウンしてしまいます。画面を見ていると、link downとlink upの羅列です。絶えず、切れたりつながったりしているものですから動作も遅いし、VPN経由でサーバーにつなぎに行っている広島では販売管理プログラム使用時にプログラムがハンブアップしてしまうこともあります。また、MS-Accessでテーブルとリンクしているフォームにフィルターをかけると、リンクダウンしていまいます。
さすがにカーネルごと落ちてしまうということはないのですが、Vine3.2使用時よりも使用感が非常に悪いので、カーネルチューニングすることにしました。
TCPがらみのようなので、下記を実行しました。また、再起動時にも設定が保存されるよう、同じものをファイルの最初に　#!/bin/sh　を付けて、/etc/rc3.d/S99setnddとして保存しました。

ndd -set /dev/tcp tcp_deferred_ack_interval 200　（既定値は100）
ndd -set /dev/tcp tcp_max_buf 4194034（既定値1048576)
ndd -set /dev/tcp tcp_cwnd_max 2097152（既定値1048576）
ndd -set /dev/tcp tcp_recv_hiwat 400000（既定値49152）
ndd -set /dev/tcp tcp_xmit_hiwat 400000（既定値49152）

また、postgresql.confも下記に変更しました。

listen_address = '*'
max_connections = 64
shared_buffers = 20000 #160M
temp_buffers = 5000 #40M
work_mem = 10000 #10M
wal_sync_method = fdatasync
commit_delay = 10
effective_cache_size = 5000 #40M 2G*2%
random_page_cost = 3
silent_mode = on

Postgresqlのログを見ても、大したエラーもないので、silent_mode をオンにしました。またpostgresのプロセスサイズが160Mbyteにもなっていたので、shared_buffer を　20000にしました。これでプロセスサイズは100Mbyte程度になります。
Vine3.2の時Postgresqlの設定には特に問題がなかったので、postgresql.confのメモリがらみはVine3.2の時に近い値に修正しました。
nddで設定した値はWebから拾ってきた値で、まあ自分の環境でも適当ではないかと思う値です。この条件でリンクダウンはかなり減りました。また、VPN経由で接続している広島で販売管理プログラムがハングアップするということは無くなりました。
クライアントの数が減ると販売管理プログラムの動作速度が速くなります。クライアントの数といっても通常、最大で７台程度で、少ない場合で２台程度になります。その程度でサーバーの負荷が大してかかっているとも思えないので、リンクダウンがクライアントの多寡によって起こっているとも思えないのですが。
現時点ではnddで設定したtcpのバッファがらみの原因でリンクダウンしているのではないかと考えています。もっとバッファを大きくとれば良いのだろうか？