BugTrack/732

[backup] 書き込み時にメモリ不足†

• 元タイトル: 書き込み時にメモリ不足

• ページ: BugTrack
• 投稿者: みこ
• 優先順位: 低
• 状態: 完了
• カテゴリー: 本体バグ
• 投稿日: 2004-10-18 (月) 19:52:43
• バージョン: 1.4.4

メッセージ†

　とりあえず、あまりありえないお話だとは思いますが (^^; いちおう記しておきます。書き込み時に backup.inc.php がmemory_limit エラーが発生したので何故？とおもったら、gzopenが展開しきれずメモリ不足に陥ったようです。

　たしかに pukiwiki.ini.php は $cycle=0 で $maxage = 999 としているのでありえないことはないかなとはおもったのですが (^^; レアなケースでも、さすがにエラーはまずいかなとおもい、ここに報告します。

• そもそも、PHPでメモリ不足をトラップなんてできるのかな？ (^^; -- みこ 2004-10-18 (月) 19:53:20
  • こんにちは、いつもありがとうございます :) その現象は再現可能ですか、それとも「たまに」起こるものですか？ 再現可能であれば、問題のページのデータ(backupとdiffとwiki)を送って下さい。(つづく) -- henoheno 2004-10-18 (月) 21:03:57
  • 問題のページの実際のバックアップ件数(世代数)は何件ありますか？ファイルサイズの増加の伸びはともかく、現在何キロバイトありますか？更新頻度は週あたり何回くらいですか？ -- heheno henoheno 2004-10-18 (月) 21:07:07
  • (ぜぇはぁ) とりあえず知りたいのはこんなところです。お時間の空いた時にでも教えて下さい :) (hehenoって誰だ・・・) -- henoheno 2004-10-18 (月) 21:07:46
  • なぜ細かく知りたいかというと、その挙動は何かおかしいと思っているからです。gzopenについてだけ言うならば、dumpプラグインでtar.gzファイルを作成・展開するときの方が負荷は高いと思います。真犯人はbackupの処理周りのどこかのメモリオーバーヘッドじゃないだろうかと。 -- henoheno 2004-10-18 (月) 21:12:05
  • 件数＝250近く、サイズ＝1.5MB(gzで2KB)、頻度＝コメントページなのでほぼ毎日とおもってください。 -- みこ 2004-10-18 (月) 23:32:28
  • もういちど8Mに戻しておこなってみたところ、いろいろ出ますね。 -- みこ 2004-10-20 (水) 13:04:36

    Fatal error: Allowed memory size of 8388608 bytes exhausted
    (tried to allocate 3084929 bytes) in /path/to/pukiwiki/lib/backup.php on line 56

  • 前と現象が違う(gzopenではない)ので、たしかにhenohenoさんの言われているとおりlib/backup.php には何か問題があるのかもしれません。 -- みこ 2004-10-20 (水) 13:06:22
  • 念のため、環境は RedHat 9+Apache 2.0.40(redhat-custom)+php 4.3.8です。 -- みこ 2004-10-20 (水) 13:09:36
  • というより、get_backup関数でバックアップ全体を配列に詰めているのですね。これはたしかにメモリ不足になるかも・・・ (^^; -- みこ 2004-10-20 (水) 13:18:36
• お疲れ様です :) 実行時間の制限秒数を超えた時と似ていますが、PHPに実行を停止させられた (のだろう)という時点で、どこかに富豪的な処理が存在する気配が濃厚でした。停止させられる場所が変動するということはほぼ確定でメモリの無駄使いでしょう。といった事を踏まえつつ、get_backup() にそのような処理の部分があるのならば大変怪しいと思います。うまい別解があるかな？ -- henoheno 2004-10-20 (水) 21:28:15
  • これもひとつのスケーラビリティの問題っぽいですね -- henoheno 2004-10-20 (水) 21:29:05
• 普通の運用では発生しない問題だとおもうので、とりあえず運用対処で凌ぎます。落ち着いてコードがみれるようになったときにでもお願いします。 -- みこ 2004-10-21 (木) 00:35:55
  • ちなみにわたしだと、こういうときこそデータベースの使用をといいかねない（＝お手軽ではなくなる？）ので (^^; これ以上のコメントは控えます (_ _@ -- みこ 2004-10-21 (木) 00:38:27
• 私も同じ問題が出ました。バックアップ(12Mもありました)を消すと動作しましたので、やはりファイルサイズではないでしょうか。 -- 2004-11-01 (月) 11:53:56
• 必要の無いデータをメモリに積まず、速やかに次の工程に叩き込む様でないと駄目だろうなーと想像だけしております :) -- henoheno 2004-11-01 (月) 21:24:58

• この件は一つの結論として、ko-zuさんによって実際にメモリオーバーヘッドが見つけられ、修正されました(BugTrack2/159)ので完了とします。また何かあればぜひお願いします ;) -- henoheno 2006-06-18 (日) 23:36:10

• PukiWiki 1.4.5_1で同様のエラーが起きたので、とりあえずbackupディレクトリのファイルを（index.html以外）全部消してみたところ、エラーは解消しました。 -- Gimite 2008-03-01 (土) 20:04:56
  • 上に挙がっている、BugTrack2/159 の修正が同梱されているパッケージは、1.4.7 以降なので、アップデートしていなければ、この問題が起こる可能性があります。 -- 2008-03-01 (土) 21:59:12
  • バックアップファイルのSPLITTER の設定を変数から定数にする修正が終わっている、1.4.5 以降からアップデートするのなら、lib/backup.php だけ1.4.7 に同梱されているものに置き換えるという方法で、おそらく問題はないと思われます。 -- 2008-03-01 (土) 22:22:43

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件