Linuxサーバ上のHTTPプロキシサーバでシステム負荷が高くないにもかかわらず処理が遅い場合：TechLabo：So-netブログ
仕事で、Linuxサーバ上でHTTPプロキシサーバとして動作するとあるURLフィルタリングソフトを使っているユーザから、「お昼頃からプロキシサーバ経由でのアクセスが非常に遅い、ちなみにCPU使用率とメモリ使用率、ディスクI/Oは正常時と変わりないのになぜ？」という問い合わせがあり対処したときのメモ。 システムリソースの負荷が高くなく、処理遅延が発生している場合の疑う点としては、 ファイルディスクリプタが不足している アプリケーション（プロキシサーバ）の最大同時接続数以上のアクセスを受け付けている カーネルチューニング不足 の3つが考えられる。 1．のファイルディスクリプタ不足はプロキシサーバアプリケーションが1セッション1スレッドで動作するようなもの（メジャーなものではsquidなど）が発生しやすい。 ログファイルに”too many open files”というメッセージが記録されるので
Programming UNIX Sockets in C - Frequently Asked Questions: クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問
Previous Next Table of Contents 2. クライアントとサーバ(TCP/SOCK_STREAM)両方に関する質問 2.1 相手側のソケットが閉じられたことをどうやって知ることができますか? Andrew Gierth 氏 ( andrew@erlenstar.demon.co.uk) より: 私の知る限り… 相手側が (SO_LINGER を使ったややこしいことをしないで) close() するか終了したとすると、こちらの read() の呼び 出しは 0 を返すはずです。同じ場合で、write() 呼び出しで何が 起こるかは、もうちょっとわかりづらいです。直後の呼び出し時ではな く、その次の呼び出し時にEPIPE が返るでしょう。 もし相手が再起動するか l_onoff = 1, l_linger = 0 を設定して から閉じたとすると、read() からは(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
