4

ここでメモリリークが発生する可能性があります。たぶんコハナだろう。私はあなたから洞察を得ることを望んでいます。(このスクリプトを何日もデバッグしようとして、私はついに昨夜あきらめました)。

このスクリプトの機能は次のとおりです。

基本的に、これはバックグラウンドワーカー(Pagodaboxでホストされています)です。それが無限のwhileループである理由です。ステップバイステップ:

  1. 未処理の記事を1つ取得しようとします
  2. 次に、関連するテーブルから関連する情報を取得します
  3. 情報をテーブルに保存します(emailerscheds)
  4. 当然、テーブルからフェッチされる記事レコードは1つだけなので、先頭に戻って別の記事を取得します。
  5. そして再び1から始まります。

問題:最初のレコードの後でメモリがクリアされず、最終的に、割り当てられたメモリがどれほど大きくても、不足します。新しいデータベースオブジェクトを処理しているので、メモリをクリアする必要があると思います。しかし、そうではありません。

私はあなたが記憶をクリアすることを考えることができるさまざまなアプローチを試しました。変数をNULL、unset()、gc_enable、gc_collect_cycles()を宣言し、ガベージコレクターが落ち着いた瞬間に仕事をすることを期待してスクリプトを60秒スリープさせようとしました(wink-私は夢中だと知っています)。ORMが問題だと思ったので、DBを試してみました。私はプロファイリングをオフにしてみました-ちなみにそれは助けになりましたが、何よりもまず問題ではありません。__destructを試しました。

まだメモリが不足しています。

おそらくデータセットは巨大だと言うかもしれません。です。ただし、これにより、メモリが不足する前に約3〜4件の記事レコードを処理できます。つまり、実際には少なくとも1つを処理できます。そして、1レコード後にメモリが解放されることを望んでいます。


public function action_grab_article_topics()
{
    gc_enable();

    $x = 1;
    while ($x == 1)
    {

        // $articles = ORM::factory('article')
        //   ->where('sent', '=', 0)
        //   // ->limit(1)
        //   ->find();

        $articles = DB::select()
                ->from('articles')
                ->where('sent', '=', 0)
                ->as_object()
                ->execute()
                ->current();

        $topics = array();
        //foreach ($articles as $a)
        //{
            //$topics = $articles->topics->find_all()->as_array();
        if ($articles)
        {   
            $topics = DB::select('topic_id')
                    ->from('articles_topics')
                    ->where("article_id", '=', $articles->id);

            if (! empty($topics))
            {
                $members = DB::select('members.id', 'members.email', 'members_topics.topic_id', 'topics.topic_name')
                        ->from('members_topics')
                        ->join('members')
                        ->on('members.id', '=', 'members_topics.member_id')
                        ->join('topics')
                        ->on('topics.id', '=', 'members_topics.topic_id')
                        ->where('members_topics.topic_id', 'IN', $topics)
                        // ->limit(20)
                        ->as_object()
                        ->execute();

                foreach ($members as $m)
                {
                    $topic_id = $m->topic_id;
                    $topic_name = $m->topic_name;

                    $data = array(
                                "member_id" => $m->id,
                                "topic_id" => $topic_id,
                                "article_id" => $a->id,
                                "topic_name" => $topic_name,
                                "title" => $a->title,
                            );

                        $emailersched = ORM::factory('emailersched')->values($data)->save();

                        unset($m);

                 }

                $members->__destruct();

            //sleep(2);

            //$m = NULL;
            }

            $data = array('sent'=> time());

            $query = DB::update('articles')
                    ->set($data)
                    ->where('id', '=', $articles->id)
                    ->execute();

             // $articles->sent = time();
             // $articles->save();


            //}

         //echo "done";
            //$a = NULL;
            //$articles->__destruct();

            $articles = NULL;
            $topics = NULL;
            unset($articles);
            unset($topics);

            }

        gc_collect_cycles();
        //sleep(60);

    }
}

編集:さらに私の「メモリリーク」調査では(コードで問題が発生し続けているため)、ここに私が見つけたいくつかの奇妙なものがあります:

http://pastebin.com/c7pc5XjWこのコードは、KohanaとFuelPHPの両方で実行されます。同一の基本的なコードベースで、組み込みのDBモジュールを使用し、ORMは使用せず、同じデータベースにアクセスします。燃料はオイルを使用しませんでした。これは、コハナがアクセスされた方法でパブリックhttpを介してアクセスされました。

このコードは、合計で約10kレコードの50レコードを処理しようとします。

これがコハナの私の記憶ログです:http://pastebin.com/gUiF9D2w

これがFuelPHPの私のメモリログです:http://pastebin.com/v8Pzwu77

コハナは3Mbで始まり、7Mbで終わったことに注意してください。ただし、FuelPHPは約11Mbで始まりましたが、11Mbで終わりました。コハナは小さく始めましたが、この点でリークがあるように見えました。

何かご意見は?

4

3 に答える 3

4

また、データベースプロファイリングを無効にしていることを確認しましたか?

config / database.php

'profiling'    => FALSE

これは、TRUEに設定されている場合、大きなリークを引き起こします。デフォルトではそうです。

この設定を見逃しがちで、ブートストラップファイルのメインプロファイリング設定のみを変更します。

于 2012-09-18T11:04:24.303 に答える
1

従来のKohana1プロジェクトのデバッグで、原因はconfig/database.phpの「ベンチマーク」設定であることがわかりました。既存の構成でTRUEに設定すると、UPDATE/INSERTのデータのサイズまたはSELECTの結果セットのサイズに対応するすべてのデータベースクエリでメモリリークが発生しました。FALSEに設定すると、メモリリークが解消されました。

于 2015-03-23T12:36:50.530 に答える
0

これがあなたのためのジューシーなフレームワーク戦争です:私の必死で、私は同じコードをFuelPHPに実行しようとしました(OILのタスクを介して)。

結果:

-302kレコードが2分で処理されました-メモリリークがなくなりました!

ですから、ここでの結論は、どこかでコハナコードベースにリークがあるということだと思います。

于 2012-05-05T15:38:03.217 に答える