設定変更

気胸で１週間入院してしまいました。
入院前に設定を下記に変更しました。

<Solaris>
tcp_max_buf = 33,554,432 (32M)
tcp_cwnd_max = 16,777,216 (16M)
tcp_recv_hiwat = 4,194,304 (4M)
tcp_xmit_hiwat = 4,194,304 (4M)
tcp_deferred_ack_interval = 100
tcp_local_dack_interval = 10

<PostgreSQL>
shared_buffers = 20000 (160M)
temp_buffers = 5000 (40M)
work_mem = 10000 (10M)
effective_cache_size = 2000 (16M)

もちろん入院中は設定を変更することはできなかったので、この設定で全く１週間過ごしました。退院後特に、クレームも無かったので、これで良いかと思います。
また、入院中ベットで「リンクが切れてしまうのはサーバーの設定でなくクライアント側のバッファがあふれているせいではないか」と思い、退院後、WindowsXPのTCP受信バッファの大きさを8Mbyteに変更してみましたが、特にリンクダウンの回数が減ったということはありませんでした。
http://www.microsoft.com/japan/technet/community/columns/cableguy/cg1105.mspx

リンクダウンの症状としては、やはり、クライアントの数が多い時にリンクダウンする回数が多いように思います。また、一端、販売管理プログラムを終了しても、ソケットそのものは直ぐには切断されず、しばらく残っているのではないかと思います。そのため、「今、接続しているのは俺様のパソコンだけだ！」と思っても、ftpでダンプファイルをgetするとリンクダウンしてしまう。（大抵、一通り業務が終わって他のPCを止めた直ぐ後にバックアップをとっているので、ソケットそのものが残っている。）といったことになっているのではないかと推測しています。
だからといって、販売管理プログラムを終了して直ぐソケットを切断するようにサーバーを設定すると、再度販売管理プログラムを使用する時に、立ち上がりが遅くなってしまうので、ソケットが接続したまま残ってしまうのは仕方がないと思います。
また、はっきりこの場合はリンクダウンしてしまうというケースで、Accessのフォームのデータソースとしてテーブルを指定していて、openイベントでフィルターをかけていると、リンクダウンしてしまいます。
例えば商品マスターメンテナンスフォームで削除フラグの立ったレコードは通常は表示したくないので、フィルターをかけてはずしています。しかし、場合によっては削除フラグのたったレコードも見たいことがあるので、コマンドボタンでフィルターをオフするようにしています。フォームのレコードソースは削除フラグの立ったレコードも含んでおかなければ、見たい時に見れないので、データソースとしては全てを指定しています。
この場合にリンクダウンしてしまうような現象はRedHat9、Vine3.2の時にはありませんでした。いずれの場合もサッとフォームが開いていました。原因は全くわかりません。仕方ないので、削除フラグの立った明細を最初から表示するように変更しました。

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のバッファがらみの原因でリンクダウンしているのではないかと考えています。もっとバッファを大きくとれば良いのだろうか？

ホンチャンインストール１１

Solaris10を使用してみての感想

Vine3.2からSolaris10に変えた原因というのは、DMAエラーがでてカーネルごとOSが落ちてしまうためでした。そういう意味ではPCと合わせて、Solaris10に変えたのは成功でした。カーネルごと落ちるというこことは無くなりました。しかし、ODBCドライバーの接続の問題があって、少し使用感が落ちたのが残念です。

sambaにも問題があって、pg_dumpしたデータは150M程度あるのですが、/export/pub/に保管したダンプデータをバックアップ用にsambaを使用してWindowsパソコンに持ってこようとすると、ネットワークエラーが出て、ファイルのコピーができません。ftpではgetできます。小さい数十Mbyte程度のファイルならsambaでも問題ないのですが。

このようなことはVine3.2ではありませんでした。Vine3.2ではコピー中にPostgreSQLを使用していると、DMAエラーがでてカーネルごと落ちていましたが、他に何も使用していない状態でsambaでのファイルコピーは問題ありませんでした。Solaris10ではカーネルごと落ちたりしませんが、他に何も使用していない状態でsambaでファイルコピーをしているとネットワークエラーがでます。これはNICのドライバーの問題かもしれません。
（同様にODBCのソケット切断の問題もNICのドライバーの問題かもね）

Solaris10では64bit化したのですが、その効果は全くなかったと言っても良いと思います。大して速度は上がりませんでした。速度についてはPostgreSQL Ver8.1がかなり高速なので、ボトルネックがアプリケーション側ではなく通信速度側になっているためだと思います。それなら、次回は100BaseTではなく1000BaseTにしなければならないのかな。回線ごとやり直しかい！

やはりSolarisは少し難しいです。特に、NICやVideoCard周りはドライバーが限定されているか無いという状態で、新しいPCではインストールそのもので行き詰まってしまう場合もあるかと思います。
「なら、SPARC買えよ！」ってことですか。

Vine3.2でPCだけ変えた場合は試していないのですが、もし、Vine3.2で運用できるなら、それがベストだったかもしれません。
まあ、unixの天才ビル・ジョイのSolarisを使えただけでも幸せか～

ホンチャンインストール１０

ODBCドライバー

前回の更新時（PostgreSQL Ver7.3からVer8.1に変更した時）にも同じようなことがあったのですが、MS-AccessからODBC経由でPostgreSQLでアクセスしていると、しばらく操作しないでほおっておくとソケットが切れてしまう、という現象がありました。

Vine3.2の時はODBCドライバーをUnicode 8.01.02.00に変更することで、この現象が止まりましたが、同じPostgreSQL Ver8.1.3+Unicode 8.01.02.00でもSolaris10では操作なしで時間が経つとソケットが切れてしまいます。最新版のODBCドライバーUnicode 8.02.02.00を使用しても直りません。

結局、今度こそKeepAliveの問題のようなのでMS-Access側でタイマーイベントを使用して１分おきに簡単なクエリーを飛ばしてやることで、ソケット切断をふせいでいます。これで販売管理プログラムが凍ってしまうということはなくなりましたが、Vine3.2の時とは違い、しばらくするとソケットを再接続しているような様子があります。このことがあって、動作速度が遅くなったような感じがするのです。

これがSolaris10のカーネルに由来するものなのか、postgresql.confの設定に由来するものなのか良くわかりませんが、つながってしまうと、前回より動作が少し速い感じなので、やはりカーネル側の問題なのではないかと思います。
実際、PostgreSQLのログにはこれに容量についての警告等はでていないようです。

（これを書いてて気が付いたのですが、

log_min_error_statement='error'

じゃ警告は記録されないよな。'notice'に変更して様子を見てみよう。）