| カテゴリ | |
|---|
| サマリ | ?cmd=read&page=&p=1による高負荷 |
|---|
| バージョン | 1.4.7 |
|---|
| 投稿者 | しゅん |
|---|
| 状態 | 質問 |
|---|
| 投稿日 | |
|---|
こんばんは。
私の利用しているサーバーの管理者から以下のようなメールをいただきました。
－－－－－－－－－－－－－－－－－－－－－－－－－
お使いのアカウントのPHPスクリプト処理が非常に高負荷になっております。現状では制限を掛けざるを得ません。
具体的には
?cmd=read&page=&p=1
を呼び出した際の動作です。
無動作し続ける時間が3分程度続くことが多々あります。
動作しつづけるプロセスが常駐しますので、お客様サイトの許容同時接続が減っていく症状が発生します。
リクエストが「?cmd=read&page=&p=1」である時が、特別高負荷です。
－－－－－－－－－－－－－－－－－－－－－－－－－
改善したいと思うのですが、どこをいじればよいのかが分からず途方にくれております。
また、個人的な推測ではあるのですが、PukiWikiに備わっている検索機能が原因ではないのかと思っていますが、分かりません。
回答よろしくお願い致します。
- Q. PukiWiki の動作が重くなったので、どうにかしたい とか？ --
- 回答ありがとうございます。しかし、そのページは過去に既に確認しており、可能な限りは実践しましたが、やはり高負荷です；； -- しゅん
- そもそも、なぜこのURL にアクセスがあるのでしょうか？keitai.skin.php を経由しなければ'&p=1' がURL に付かないはずですし、ページ名が空というのも謎ですし・・・ --
- 回答ありがとうございます。携帯からは1日20万程度のアクセス（PV）がありますので、keitai.skin.phpはかなり高頻度で呼び出されています。また、言われてみたら、そのURLにアクセスがあること事態謎ですね＾＾；サーバー管理者に聞いてみることにします。 -- しゅん
- dev:BugTrack2/248 にメモの状態ですが問題点を追記しておきました。'?cmd=read&page=&p=1' へのリンクが作られる原因は判明したかも。 --
- ページ分割機能を閲覧時のみとなるように改造するのが（緊急手段としては）手っ取り早いのですが、そうするとkeitai.skin.php 経由の場合、閲覧・（データ量が少ないページの）編集・コメントや投票、ぐらいしか満足に機能しないかも・・・（機械分割なので、分割される場所しだいではフォームやリンクが動かなくなるのは、そのままですが・・・） --
- 回答ありがとうございます。つまりkeitai.skin.phpで
if ($pageno < 0 || $pagecount - 1 < $pageno) $pageno = 0;
の一行を
// Get one page
$body = substr($body, $pageno * $max_size, $max_size);
の上に追加すれば一応は改善されると解釈してよろしいでしょうか？
なお、私のサイトでは携帯からの編集は禁止しており、閲覧専用としていますので、恐らくそれで十分満足なはずです＾＾；
また、間接的にPukiWikiの検索機能が負荷をかけていたということになるのですよね？ということは、やはり検索機能は利用しない方がよろしいでしょうか？
質問が多くなり申し訳ありません。回答よろしくお願い致しますm(__)m -- しゅん
- その1行の追記は、「分割の必要がないページで分割を指定（'&p=1' など ）した場合に、本文が表示されなくなる」問題を回避するだけです。（それでも、「有効なWikiName ではありません」というエラーメッセージすら本文に表示されない状況よりは、一歩改善ですが）
閲覧時以外なのに閲覧へのリンクが作成されるのが問題なので、例えば
// Previous / Next block
if (arg_check('read') && $pagecount > 1) {
$prev = $pageno - 1;
$next = $pageno + 1;
if ($pageno > 0) {
$navi[] = '<a href="' . $script . '?cmd=read&page=' . $r_page .
'&p=' . $prev . '" ' . $accesskey . '="7">7.Prev</a>';
}
のように変更し、閲覧時以外は「7.Prev」や「8.Next」のリンクを表示しないようにする必要があります。
あるいは、'cmd=read' と閲覧固定になっている部分を修正するかです。（プラグインに応じてパラメータを変化させなければならないので、難易度は上がりますが・・・） --
- ただ、'?cmd=read&page=&p=1' とアクセスされた場合にPHP が動作し続ける原因が、まだ分かっていないという問題が・・・（存在しない分割ページへのアクセスをなかった事にするとか、無意味なリンクを表示しないとかは、どちらかといえば外堀であって、内部の問題がそのままになっている可能性があります）
PHP エラーが出ているとか、どのあたりの処理で時間がかかっている（STOP している）とかいった情報があれば、もう少し掘り下げられるのかもしれませんが・・・ --
- 回答ありがとうございます。上記のように修正してみました。現在アクセス数が最も多く、負荷がかかりやすい時間帯ですがサーバーは快適です。「'cmd=read' と閲覧固定になっている部分を修正」というのは、cmd=readの記述を削除するということだと解釈してよろしいでしょうか？まあ、難易度が高いというこそだそうなので、とりあえずそれについては保留にしておきます＾＾； -- しゅん
- PC でアクセスしたときに表示されるナビゲーションのリンクを見れば、多少はイメージしやすいかと思います。（デフォルト以外だと、表示されないものもあったりしますが）
「バックアップ」なら'cmd=backup&page=test' のようになっていますし、「単語検索」なら'cmd=search' になっていると思います。こういったパラメータの変化を全部吸収させた上で、'&p=1' のような分割後の何ページ目（ただし最初が0）かを表すパラメータをURL に足さなくてはいけないので、すべてのプラグインに対応しようとするのは、めんどう 難易度が上がるというだけです。対応させるプラグインを減らせば、それだけ実現しやすくはなるでしょうが・・・
ちなみに、cmd=read を省略した場合は、閲覧扱いで処理されます。（'?cmd=read&page=test' と'?test' は共にtest というページを閲覧することになります） --
- あと、「負荷がかかりやすい時間帯ですがサーバーは快適」だそうですが、肝心の'?cmd=read&page=&p=1' の問題は解消したのでしょうか？（アクセス数が減ったとか、あまり変わらないけど負荷が段違いに減ったとか）
状況しだいでは、追加対策が必要になるかもしれませんよ。（制限を掛けられてからではアレですし） --
- 回答ありがとうございます。「cmd=read を省略した場合は、閲覧扱いで処理されます。」ということは恥ずかしながら知りませんでした。携帯からの使用時に対応させたいプラグインはさほどありませんが、方法も分からないのでやはり保留にしておきます。'?cmd=read&page=&p=1'の件ですが、土日でサーバー管理者からの返事がいただけていない状況です。こちらからでは大雑把にしか負荷を把握できないので分かりません。なお、アクセス数はさほど変わっていません。というより元から2～3件ほどしかありません＾＾；また、この問題は全てのPukiWikiで起こりうる問題なのですよね？＾＾； -- しゅん
- 「本文が表示されなくなる～」と「リンクが表示される～」という部分は、修正しない限り発生しますね。'?cmd=read&page=&p=1' にアクセスした結果として何が起こるのか、という部分がまだ完全には解明されていませんが・・・（どの環境でも高負荷になるのかなど） --
- 「省略した場合～」は、1.4.5_1 → 1.4.6 の変更点（オーバーヘッドの削減 / Webクローラー対策）で変わった部分ですからね。pgid プラグインを使っているなら余計に忘れがちになるかも・・・（そういえばpgid 入れた状況では、テストしてない・・・、pgid 経由だと「7.Prev」や「8.Next」が表示されてないかも・・・） --
- 先程サーバー管理者から回答をいただきました。'?cmd=read&page=&p=1'にアクセスした場合に限って異常な高負荷になるそうです。URLに「?cmd=read=page=」が付いていれば起こるというわけではなさそうです。これをどうにかしない限り、制限を掛けられるのは時間の問題のようです；；； -- しゅん
- 「無動作し続ける時間が3分程度続く」という事は、「サーバーがSTOP させるまでPHP が動き続けている」という事ですよね、たぶん・・・。初期状態でも起こるのか、それともカスタマイズした結果発生するようになったのか、といった辺りを調査していくしかないかもしれません。 --
- ただ、タイムリミットがせまっているので、とりあえず'?cmd=read&page=&p=1' や'index.php?cmd=read&page=&p=1' など問題の起こるアクセスを.htaccess で拒否するようにして、今すぐ制限を掛けられる事を回避する方がよさそうです。（そして、その間に問題点を探す） --
- そうですね。とりあえず応急処置としてアクセスだけでも禁止して方がいいですね。早速アクセス制限しようと試みたのですが、「?」から始まるページをどうやって制限すればいいのかが分からないです；；
普通は、
<Files a.htm>
deny from all
</Files>
と記入しておけば、「a.htm」へのアクセスを全て制限できますが、
<Files ?cmd=read&page=&p=1>
deny from all
</Files>
と入力しても制限できませんでした。何か別の方法があるのでしょうか？m(__)m -- しゅん
- google:.htaccess query_string で検索してみるとか？（役に立たなかったらスマン） --
- index.phpを修正しQUERY_STRINGを判断し、該当URLにアクセスした人に対する説明ページもしくはトップページに強制的に転送してしまうのが手っとり早いかと。
$redirect = "http://案内ページへのURL";
if ($_SERVER['QUERY_STRING']=='cmd=read&page=&p=1') {
header("Location: $redirect");
exit;
}
requireの前に記述で -- mashiki
- 回答ありがとうございます。上記の記述を加えることでとりあえず'cmd=read&page=&p=1'へのアクセスは遮断することができました＾＾ -- しゅん
![[PukiWiki-official]](image/pukiwiki-official.png "[PukiWiki-official]")
