質問箱/4437 の変更点 - PukiWiki-official

追加された行はこの色です。
削除された行はこの色です。
質問箱/4437 へ行く。
質問箱/4437 の差分を削除
**[[質問箱4/437]] [#b1ad4982]
#author("2018-03-11T20:38:26+09:00;2009-03-08T11:05:25+09:00","","")
**[[質問箱/4437]] [#b1ad4982]
|RIGHT:70|LEFT:410|c
|~カテゴリ||
|~サマリ|編集ボタンを押すとページが真っ白。|
|~バージョン|1.4.7|
|~投稿者|てる|
|~状態|質問|
|~投稿日|&new{2009-03-05 (木) 12:53:14};|
***質問 [#m3056a99]
pukiwikiにてリンクはりまくりの超でかい編集を実行したり、&br;
一括置換プラグインで置換を実行すると&br;
ページが真っ白になり、編集もされないという現象に直面。&br;
&br;
php.iniでdisplay_errors　onにてエラー表示したところ&br;
&br;
 Fatal error: Allowed memory size of 25165824 bytes exhausted 
 (tried to allocate 8305809 bytes) in /(途中省略)/lib/backup.php on line 62

といったエラーが表示されているようです。&br;
[[dev:BugTrack/732]]など、&br;
真っ白ページ現象の事例と解決策を確認させていただきましたが&br;
とかを確認しましたが、これはもうmemory_limitのメモリを上げるしかないでしょうか？&br;
レンタルサーバーの共有サーバーの為簡単に変更はできなそうなのです･･･。&br;
&br;
大きいページの編集でエラーが出る際は該当ページのバックアップファイルを削除したり分割したりくらいで対応できましたが、&br;
一括置換プラグインで置換できないのはなかなか辛いです･･･。&br;
なにかよい解決方法はないでしょうか？&br;
&br;
(環境)&br;
pukiwiki1.4.7&br;
PHP 5.2.8&br;
バックアップサイクル：3時間&br;
120世代保存&br;
総ページ数:7000ページほど&br;
置換プラグイン:replace.inc.php&br;
memory_limitは24M&br;

よろしくお願いします。

***回答 [#w935f465]
- [[teanan]] さん作の[[replace.inc.php>teanan:自作プラグイン/replace.inc.php]] だったら、データの置き換え、その保存、とRecentChanges の更新だけのはず（バックアップを変更しない）。&br;てことは、[[みこ]] さん作の[[replace.inc.php>http://pukiwiki.cafelounge.net/plus/?Plugin%2Freplace.inc.php]] を使ってますか？ --  &new{2009-03-05 (木) 18:16:28};
-- どちらを使っているにしろ、AutoLink を一時的にOFF にしておかないと、「1ページのデータを置き換えするごとに、全てのページデータの更新日時を調べて、recent.dat やRecentChanges を更新したり、サイトのページ構成が変わってないのにautolink.dat を毎回作り直す」などという無駄なこと((特に、autolink.dat の生成は、対象ページ数が増えると、リソースやメモリの消費量が爆発的に増えるおそれが・・・)) をやらかしてくれるので、注意が必要ですね。&br;（7000ページもある時点で使ってなさそうなの気がしますが、念のため） --  &new{2009-03-05 (木) 18:28:09};
--- replace.inc.phpは２種類あるのですね(汗)みこさん作の方を使用しています。AutoLinkはOFFにしていますが、[[belong.inc.php>自作プラグイン/belong.inc.php]]や[[tag.inc.php>自作プラグイン/tag.inc.php]]等のプラグインを使用している為そこらでさらにメモリの消費が増えてるのかもしれませんね･･･。メモリー増設が不可能な場合はこれらのプログラム周りを見ていくしかないのかもしれません･･･。と言う事は一般的にPukiwikiの使用は6000ページまでの使用が望ましいという事になるのでしょうか？ --  てる &new{2009-03-06 (金) 13:40:39};
- 質問以降ですが、本日はページ名の変更でも同様の真っ白ページが出るようになってしまいました･･･。 -- [[てる]] &new{2009-03-06 (金) 13:43:25};
-- Pukiwikiの扱えるページ数は、稼動環境や、ユーザ数、使っている機能などでも前後してくるので、これだという数を示すのは難しいですね。&br;そのときのエラーも、（発生行数は別にして）lib/backup.php で起きていましたか？違うエラーだったのなら提示してもらわないと、追加でアドバイスしづらいのですが・・・。一応、「[[負荷対策のまとめ>dev:BugTrack/763]]」を挙げておきますが、レンタルサーバということなので、できることは限られてきそうですね。&br;「負荷対策のまとめ」で思い出しましたが、$attach_link = 1 で運用していますか？もしそうなら、[[dev:BugTrack2/264]] の修正を適用しておいたほうがいいですよ。 --  &new{2009-03-06 (金) 16:59:04};
--- 負荷対策のページにはお世話になりました。$attach_linkや$list_indexなどなど、これらはほとんどが0で追加で「[[get_existpages() の高速化>http://www.revulo.com/PukiWiki/Cache/PagenameCache.html]]」と言う作業を行っています。情報が後出しになってしまって申し訳ないです。今回のページリネームのエラーについて普段はdisplay_errors　offでしたので、帰宅次第しらべて報告します、申し訳ありません。。たくさんのアドバイスありがとうございます･･･。 -- [[てる]] &new{2009-03-06 (金) 17:21:38};
--- lib/backup.php で起きていました。全く同じ内容のエラーとなります。 -- [[てる]] &new{2009-03-06 (金) 21:34:23};
- backupフォルダのファイルをindex.html等以外、全部削除すると正常動作するようになりました。ページ数が多くなるとバックアップ関連のどこかの処理で非常に重たい作業を行っているように感じます。(dumpでは今回のようなエラーはおきません) -- [[てる]] &new{2009-03-06 (金) 22:38:11};
- 主たる原因は、7000ページもある事でしょう。他の人が書いているけど、一概に何ページでこうなるというのは言えないけれど。（私の場合、文書名が長かった製か、2500ページ程度でもうこの現象になった）なので、現状で解決は難しいでしょう。Wiki分割を考えた方が良いかも？どこだったか、20個くらいに分割しているところもあるとか。私もまねして、分割してたけど、結構管理がわずらわしいというのが本音。（なので、最終的に安易に文書数制限がほぼ無いMediawikiに走っちったけど。(^^;） --  &new{2009-03-06 (金) 23:48:19};
-- （ちなみに個人的に使い勝手はPukiwikiの方が良いので、この辺の問題を解決を望むというのが本音。10万ページは扱えるようにして欲しい！） --  &new{2009-03-06 (金) 23:50:52};
- バックアップファイルを消して解決した（他に原因が無い）のなら、バックアップファイルのサイズが問題だったのかも。問題が無い程度に「記録するバックアップの世代数を減らす」ようにしないと、いずれまた同じことが起きますよ。&br;バックアップファイルの中身は、「各世代のフルバックアップ」ですので・・・。 --  &new{2009-03-07 (土) 00:09:03};
- 一応エラーはbackup.phpから出ていたのでバックアップ関連のエラー･･･というか処理でメモリーが不足しているのは確定だと思います。記録を80まで下げてみましたが、これからもページはどんどん増えますのでそれに反比例してバックアップ世代を減らしていくような対応をしていかないといけないのかもしれませんね。。私もこれからPukiwikiを使用したいと思っているのでこのあたりの問題が解決されることを望み、状態を完了ではなく、質問のままにしておきます。 -- [[てる]] &new{2009-03-07 (土) 19:52:54};
-- 1.4.7 を使っているという事は、[[dev:BugTrack2/159]] の修正が済んでいて、過去のものと比べればそれなりには改善はしてるんですけどね・・・。&br;これ以上となると、バックアップファイルの更新時に1つのファイルを全部メモリ上に展開する、という今の形を変えるしかないんでしょうけど、[[その方法しだい>dev:BugTrack2/103]]では、過去と非互換になるかもしれないというジレンマが・・・。 --  &new{2009-03-08 (日) 11:05:25};

#comment