- - PR -
apacheが遅い原因（libhttpd.ep？)
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-06-15 12:46
私もあんまり分かってませんが...
バッファキャッシュ、ファイルキャッシュはそのままfreeと同等と いうわけではありません。この中にはディスクと同期していない、 dirtyなページも含んでいるはずです。 それから... カーネル2.4でファイルキャッシュから他へ直接転用する ことが出来るようになった、ということが解説記事なんかに書いて ありますが、それでもfreeと同じというわけではないようですし。 実際、カーネル2.4以降でもキャッシュを解放する関数がありますし、 freeの割合の管理が行われています。 # ソースコード中にハードコードされていて、簡単には設定変更 # できなくなってますが。 キャッシュを転用せず、スワップが発生するのはなぜか、という ことについては... これは、使われて間もない領域は解放しない、というポリシーに よるものと思います。各メモリページが使われたかどうか、スキャンが 行われて情報が管理されていますが、その結果が絡んでいると思います。 ・・・ただ、Linuxのメモリ管理はどうも問題がある印象は否めません。 | ||||||||||||
|
投稿日時: 2005-06-15 13:01
付け加えますと、スキャンの度に前回のスキャン以後に参照されたかどうか 調べて優先度を管理していたと思います。
ダーティなページはディスクに書き出して、クリーンにするのが 基本であったと思います。
スラッシングとは、スワップインさせるためにスワップアウトさせて 空きを作り、スワップアウトさせたところがすぐまた必要になって 再びスワップインさせる、その際にやはりメモリが足りないので スワップアウトさせて... とスワップばかりを繰り返して処理が 進まなくなる状態を指します。 パフォーマンスの観点からは致命的な状態です。 さきのvmstatの結果は、スラッシングが発生していることを示しています。 スラッシングが発生するのは、「メモリ不足」ということもあるのですが、 「カーネルのメモリ管理がまずい」という面もあります。今回は 後者のほうが主だったようですね。 # たまに、空きメモリがたっぷりあるのにスラッシングが発生するという、 # 「おい、ちょっと待てよ」なOSもあったりするようですが 
ちなみに、メモリが極めて危険な状態になると、カーネルがプロセスを killして回って空きを作ります。これが oom killer です。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-06-15 13:07 ] [ メッセージ編集済み 編集者: ぽんす 編集日時 2005-06-15 13:18 ] | ||||||||||||
|
投稿日時: 2005-06-15 20:13
ばらばらと書き込んですみません。
その点は少々気になりますね。本当に解決したのか？ たまたま今日は違っていたのではないか？等。 クラックされている可能性まで頭に置きつつ、 何がどうなってるのか調べたほうがよいとは 思うのですが... 難しいでしょうね。 | ||||||||||||
|
投稿日時: 2005-06-16 02:38
拾っていただいて、ありがとうございます。
とのことですが、これが 「cron の登録は削除したけど、手動で vacuum とバックアップはやりました」 であれば、また話が変わってくるのかな？ と思ったりしているんですね。 # どうして方針を変えたのかな？ とも思いますが ですので、先のポストで shell スクリプトの内容（またはそれ自体）を実行したのかどうかをお聞きしてみました。 メモリの使いっぱなしが気になったのは、あんとれ さんのポストがお詳しいのですが、
が気になったからです。 平常時？ も同じような結果になっているのですが、それとは違うのかな？？ と。 カーネル周りは勉強不足なのですが、inactive なのになかなか clean にならない状態、といえばよいのでしょうか。 Namazu を例に出したのですが、それにしては CPU が遊びすぎのような気がしますね… メモリ管理があやしいとのことですので、uname -r の情報も提示していただけると、参考になるかもしれませんね。 クラックの可能性まで含めると、本当に難しいです。 PHP と PostgreSQL は、セキュリティ問題が修正される前のバージョンですので、インターネットにホストを晒すのは気がかりだったりします。 _________________ はゆる Smile, Smiles make me happy. | ||||||||||||
|
投稿日時: 2005-06-16 09:02
皆様ご回答ありがとうございます。確実にスクリプトが原因であることを突き止めるために、cronのエントリを削除して（cronではこのスクリプトしか実行しておりませんでした）、まず晩のうちにshutdown -r nowを手動で実行して帰り、夜中に何もしない状態で次の朝を迎えて状態を確認したいな〜と思ってしまい、方針を変更してしまいました。 したがいまして手動で vacuum とバックアップは実行しておりません。 上は昨日の早朝の実験でしたが、今朝はスクリプトの最後に apachectl restart を追加して、再度cronを朝の2時にセットして今を迎えました。 # # Sftp # sftp -b $DAT $SSHSERVER # # Restart Apache (朝4時ごろのユーザーさんごめんなさい。) # /usr/local/apache/bin/apachectl restart > apachectl.log # exit 0 # end of script 上のapachectl.logのファイル更新日時を確認してみると04時09分となっていまして、ファイルの中身も /usr/local/apache/bin/apachectl restart: httpd restarted となっていましたのでリスタートされたことは確かだと思っております。 しかし、今朝はまた1ページのphpページの表示が数十分かかったり（昨日は一秒未満）しておりましたので、apacheのrestartでは駄目と判断しました。 最後の手段として /usr/local/apache/bin/apachectl restart > apachectl.log を shutdown -r now にして明日を迎えてみようと思います。明示的にpostgreを終了させてからのほうがよろしいのでしょうか。。 [ メッセージ編集済み 編集者: McLaren 編集日時 2005-06-16 09:05 ] | ||||||||||||
|
投稿日時: 2005-06-16 10:04
いろいろ貴重な意見をありがとうございました。
参考にさせていただきたいと思います。 | ||||||||||||
|
投稿日時: 2005-06-16 10:17
おはようございます。
ぽんすさん、ご指摘ありがとうございます。
あれから少し考えて見ました。 私も一般論としてスラッシングの事は聞いてはいたのですが、今回のMcLarenさんの症状が、スラッシングによるものとは考えられない ( 影響があるにしても極々小さい ) との結論に達しました。 ※ 少しでも swap I/O があればスラッシングということでは無いですよね ? vmstat の結果を改めて見て要約しますと、 (1) 1G あるメモリのうち、9割弱をキャッシュとして使用( 100M のbuffer、800M弱 のcache ) (2) freeは 10M程度、swapは 30M程度 (3) 〜数十KB/sのswap-in、数十〜100KB/s程度のswap-outが常時発生 (4) 1.5MB/s前後のbuffer-in、100KB/s前後のbuffer-outが常時発生 (5) CPUはほぼ、95%以上が idle これが、高負荷時のMcLarenの機器の状態ということになるでしょう。 もし、スラッシングの影響で性能が落ちているということであれば、 ・CPUが動作に必要なメモリを得る前にswapのI/Oが入るため、結果CPUが遊んでしまう ・swap I/O との競合で、buffer I/O の性能が悪くなる の2点が考えられます。しかし、 ・(3) 程度のswap I/Oでは、90% 以上もの CPU idle の原因となるとは、単純計算でも考えられない。つまり、CPU は本気で遊んでいる ( 元々やることが無い )。 ・全I/Oを足しても 2MB/s 程度であり、これでディスクの性能をフルに使いきっているとは考え難い、つまり I/O にも余裕がある。 ということで、この vmstat からは応答性能悪化の原因は読み取れない、というのが私の結論です。 で、cron で PosstgreSQL の vacuum をかけていることをあわせて考えると、今回はむしろ Postgre の限界 ( vacuum と多数のクエリーを同時に捌けない )か、チューニングが足りないかのどちらかではないかと推測しています。 ※ もちろん、HWトラブルで性能が落ちている可能性は常にあり得ますが。 もしメモリ不足という問題であれば、それはPostgreの使用できるメモリにリミットがかかっているということであって、決して OSのメモリ管理に限界が来たということにはならないと思います。 ※ Postgre のメモリ上限を引き上げた結果、システム全体がメモリ不足になることは考えられますが。
この結論は性急だと思うのですが…。 P.S. Linuxのメモリ管理に踏み込んだ話を続けるなら、元のMclarenさんのお話とズレて来そうなので、スレッドを分けた方が良いでしょうか ? [ メッセージ編集済み 編集者: angel 編集日時 2005-06-16 11:26 ] | ||||||||||||
|
投稿日時: 2005-06-16 11:34
了解しました。お返事ありがとうございます。 う〜ん、一定時間だけ処理が遅いんですよねぇ… 思いつきで、vacuum のあとに sync（3回発行・笑）と sleep（5秒じゃ短いかしら…）をかましたら症状が改善されないものかと考えたりしたのですが、vacuum は DB のお掃除処理とのことですので、その際に統計情報がボロボロになって影響が出ている、なんてことはないのかなぁと思ったりもしています。 # ご意見求ム > 識者
それをしてしまうと、cron からのメール（shell スクリプトの実行結果）が来なくなってしまうのではないでしょうか。 at で shutdown するようにするとよいと思います。 # おまけでスレ紹介を。 # ・ cron起動の際にatコマンドが使用できないです。 _________________ 夢から醒めた夢 ★「2005年夏のOFF」やります★ 企画＆参加希望へのご投稿お待ちしています！ [ メッセージ編集済み 編集者: はゆる 編集日時 2005-06-16 15:49 ] | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。