- PR -

apacheが遅い原因（libhttpd.ep？)

投稿者

投稿内容

ぽんす: ぬし; 会議室デビュー日: 2003/05/21; 投稿数: 1023

投稿日時: 2005-06-14 19:10

私としてもあんまり分かっていないので、かなり当てずっぽうで
言ってしまってるところはあるのですが...

引用:
はゆるさんの書き込み (2005-06-14 12:29) より: どういう web システムを構築されているのか分からないので、ちょっと前に身近な人がハマっていた「Namazu のインデックス作成が～（涙）」みたいなパターンも、あり得るのかなぁと思ったんですね（ちょうど朝方に cron に仕込んでいたのでした）

その線も確認しておいたほうがいいような感じですねえ。
どんなプロセスが動いているのか？なにか余計なことをしていないか？

引用:
McLarenさんの書き込み (2005-06-14 16:41) より: こちらに関しては今年2月の時点のバックアップデータを残しておくことを条件に古いデータを削除しておりまして、2月時点よりはデータ量は減っております。（↓）

ん～と、データ全体じゃなくて、「ふだんアクセスされるデータ」が
増えていないか、ということです。でもその線は薄そうなのかな？

引用:
・4月半ばに土日に出勤してインターネット側からのアクセスをシャットアウトしまし。（ファイアーウォールでアクセス拒否にしました）。するととたんに速くなりましたのでインターネットから誰かが悪さをしているのかと思い、apacheを最新の1.3.33にしました（それまでは1.3.31）。

ふむふむ。アクセス数が多過ぎて遅くなるということが過去にあった、
ということでいいですかね。

引用:
・するとそれから5月のGWまでは快適に動いていたのですが、GWを空けるとまた同じように遅くなっていていました。またインターネットからのアクセスを閉じると直るのかと思いましたが今度は直りませんでした。

ログは見ていないのでしょうか？アクセス数に変化は？
単純に「アクセス過多でメモリを使い切った」ということも
ありそうな...

引用:
これが経緯ですが、とりあえず私にほうではcronで夜中に実行するshellスクリプトの最後で、shutdown -r now　を書き加えて実験しようと思います。明日の朝方に結果が出ます。（apacheのrestartで十分でしょうか・・・）

OSを再起動したほうがよいかもです。
仮に、ダンプしてtarしているのが重くなる「きっかけ」になって
いるのだとすると、その後、OSのメモリ管理がうまく行かなくて
残すべきメモリページと捨てるべきメモリページとの判定がうまく
働かなくなって、やらなくていいスワップをやってしまうように
なっている、という可能性もあるかもしれないので。
・・・でも、あまり期待できなさそうな...

まず、「どんなプロセスが動いているのか把握すること」と、
「ログの確認」ですかねえ。

[ メッセージ編集済み編集者: ぽんす編集日時 2005-06-14 19:15 ]

McLaren: ぬし; 会議室デビュー日: 2002/01/15; 投稿数: 784; お住まい・勤務地: 東京

投稿日時: 2005-06-14 19:33

いろいろアドバイスありがとうございます！
まずは明日の結果を見て、即こちらにご報告させていただきたいと思います。

あんとれ: ぬし; 会議室デビュー日: 2004/01/14; 投稿数: 556

投稿日時: 2005-06-15 09:55

私もLinuxのメモリ管理機構についてはよく分かっていないことがあるので、ついでに教えていただければと思うのですが、

free + buffer + cacheのメモリ量が空きメモリとの認識ですが、ここに提示されているvmstatの結果によりますと、これらの合計は１ＧＢ近くもあります。それでいながら、swapが多発しているようです。Solarisなどではこのようなことは起こっていないようですので、散々ディスクキャッシュにメモリを使用しておきながらメモリがないとしてswapするLinuxのメモリ管理機構がよく分かりません。

もし、この辺に詳しい方がいらっしゃれば教えていただけると幸いです。

McLaren: ぬし; 会議室デビュー日: 2002/01/15; 投稿数: 784; お住まい・勤務地: 東京

投稿日時: 2005-06-15 10:13

　お世話になります。
先日例のshellスクリプトをcronから削除しましたところ、何とサクサク動きました。朝から非常に快適でした。

下記はcronで実行していたスクリプトですが、まずい点があればご指摘願います。

#!/bin/sh
# backup.sh
# 2003.08.02 McLaren
#
PGCMDPATH="/usr/local/pgsql/bin/"
BKPATH="/usr/local/Data/app_dev/databk/"
DATED=`date +%d`
DATEW=`date +%w`
MYDBFILE="${BKPATH}mydb"
DATAFILE="${BKPATH}data"
APPPATH="/usr/local/apache/htdocs/ni/"
DAT="/root/shells/backup.sftp"
SSHSERVER="root@webbkserver"
#
# function
#
ExecBackup()
{
# Set backup.sftp
_SNM=$1
echo "put ${MYDBFILE}.dump ${MYDBFILE}_${_SNM}.dump" >> $DAT
echo "put ${DATAFILE}.tar.gz ${DATAFILE}_${_SNM}.tar.gz" >> $DAT
}
#
# vacuum db
#
if [ -x ${PGCMDPATH}vacuumdb ]
then
su - postgres -c "${PGCMDPATH}vacuumdb -z mydb > ${BKPATH}vacuumdb.log"
fi
#
# dump db
#
if [ -x ${PGCMDPATH}pg_dump ]
then
su - postgres -c "${PGCMDPATH}pg_dump mydb > ${MYDBFILE}.dump"
fi
#
tar czvf ${DATAFILE}.tar.gz ${APPPATH}app/data
#
# ExecBackup
#
rm -f $DAT
echo "cd $BKPATH" > $DAT
#
# Dayly Backup
#
ExecBackup d
#
# Mouthly Backup on 5th day
#
if [ $DATED = 05 ]
then
ExecBackup m
fi
#
# Weekly Backup on Sunday
#
if [ $DATEW = 0 ]
then
ExecBackup w
fi
#
# Sftp
#
sftp -b $DAT $SSHSERVER
#
exit 0
# end of script

[ メッセージ編集済み編集者: McLaren 編集日時 2005-06-16 12:28 ]

angel: ぬし; 会議室デビュー日: 2005/03/17; 投稿数: 711

投稿日時: 2005-06-15 11:39

おはようございます。

引用:

あんとれさんの書き込み (2005-06-15 09:55) より:
free + buffer + cacheのメモリ量が空きメモリとの認識ですが、ここに提示されているvmstatの結果によりますと、これらの合計は１ＧＢ近くもあります。それでいながら、swapが多発しているようです。Solarisなどではこのようなことは起こっていないようですので、散々ディスクキャッシュにメモリを使用しておきながらメモリがないとしてswapするLinuxのメモリ管理機構がよく分かりません。

Linux V2.4 カーネル内部解析報告ドラフトのページ開放処理詳細はいかがでしょうか?

私も詳しく理解できているとは思っていないのですが、このようなイメージを持っています。
(1) 再利用のことを考え、キャッシュは簡単に開放しない
(2) (1)の戦略により、利用頻度の低いページは「優先度低」と印をつけるのみ
(3) (2)においてダーティなページは、いざ開放する時に楽ができるよう、スワップおよびスワップキャッシュに移す
(4) 本当にヤバくなったら、実行中のプロセスのページもどしどしスワップアウトする(これがスラッシング)

今回のような、実メモリの3～4%程度のスワップは、(3)の戦略によるもので、致命的ではないと捕らえています。

キャッシュを開放せずにスワップとはこれいかに? という疑問については、

・開放したページ(ファイル)が欲しくなったときに、またディスクから読み直すというペナルティと、スワップアウトしたページがスワップキャッシュからも失われた状態で必要となり、スワップインを行うというペナルティとの比較。
※スワップキャッシュに残っていれば、スワップインのペナルティはない。

・急激にメモリ不足が発生した時に一気にスワップアウトを行うリスクを残して、普段は全くスワップを使用しないか、普段から多少のI/O負荷は覚悟して、予め優先度の低いページを徐々にスワップアウトさせておく(しかしスワップキャッシュには残る)か。
※時間軸で見たI/Oの分散

を考慮すると、少量であれば害は無いと思っています。

以上、ご参考まで。
※私も定性的・定量的に確信が持てない所なので、他の方の意見も是非聴きたい…

[ メッセージ編集済み編集者: angel 編集日時 2005-06-15 11:51 ]

はゆる: ぬし; 会議室デビュー日: 2004/02/16; 投稿数: 1008; お住まい・勤務地: 首都圏をウロウロと

投稿日時: 2005-06-15 12:24

引用:
McLarenさんの書き込み (2005-06-15 10:13) より: 先日例のshellスクリプトをcronから削除しましたところ、何とサクサク動きました。朝から非常に快適でした。

昨日「実験しようと思います」とおっしゃっていた内容と、だいぶ違いますね…
# プロセスやログの状態も分かりませんし…

shellスクリプトに書いてある内容（vacuum やらバックアップやら）は、今朝はまったく実施していない、という認識でよろしいですか？
_________________
はゆる
Smile, Smiles make me happy.

kami: ベテラン; 会議室デビュー日: 2004/08/21; 投稿数: 95; お住まい・勤務地: 大手町

投稿日時: 2005-06-15 12:28

どうも、こんにちわ。

私の場合、ソース及び文献などによる裏づけがなく
自分で使っていた時の経験というか感想的な物になります。

ＲＨ９を使っていてメモリの開放タイミングについてふと思ったことがあります。
どのファイルをメモリに残しておくかということですが
これは、容量と使用頻度でやっているのでは？と思いました。

バックアップの際にメモリを確保する。
で、そのあとのＳＱＬを使っているページにアクセスした際に容量的にバックアップデータの方が優先度が高くなっている。
で、ＳＱＬを使っているページに対して一定のアクセスがあり、使用頻度の面か容量の面でバックアップデータより優先度が高くなった。
その時点で、ＳＱＬをつかってるページのアクセス速度が元にもどる。
それが、今回では朝の１０時頃だった。と、思います。

解決策としては、バックアップが終わった時点でリスタート(メモリ開放)をかけるか
メモリ増設。かな。

以上、参考になれば幸いです^^

ぽんす: ぬし; 会議室デビュー日: 2003/05/21; 投稿数: 1023

投稿日時: 2005-06-15 12:31

引用:
McLarenさんの書き込み (2005-06-15 10:13) より: 先日例のshellスクリプトをcronから削除しましたところ、何とサクサク動きました。朝から非常に快適でした。

うまく行ってよかったですね。やや意外ですが。
この結果からすると、ダンプしてtarするところでメモリが足りなくなったのが
きっかけで、カーネルのメモリ管理がうまく行かなくなった、ということに
なるかと思います。

対策案：
1. sftpが終わったところでOSを再起動する
2. カーネルをアップデートしてみる。効果があるかどうか、？？？
3. ダンプをバックアップ機に書き出す（そもそも可能なのかどうか知りませんが）
4. tarの処理をバックアップ機のほうで行う
こんなところでしょうか。

«前のページへ 1|2|3|4|5|6 次のページへ»

＠IT SpecialPR

apacheが遅い原因（libhttpd.ep？)

スキルアップ／キャリアアップ（JOB@IT）