さて、以前とあるWebサービスをsymfony 1.0からsymfony 1.4へアップデートを行ったが、バックエンドのバッチ処理は1.0のまま稼働させていた。また、とある事情でこのWebサービスを整理する必要があったため、バッチ処理の1.4化を行っていた。 いくつか、1.4化のための作業(ログ関係とヘルパー関係の修正等)を行いバッチ処理を開始!様子を見ていると1.0時代より非常に時間がかかる。さらに待っていると、良くあるメモリが足りないよ!というFatal Errorで死亡してしまった。あれ-、、と思いつつメモリの様子を見て見ると・・・ 美しすぎるメモリリークの図 メモリリークしてる!あーこんな情報前に何処かで見たなと思いつつ検索してみるも発見できず、、 仕方ないのでソースコードを少しずつ実行して原因となる場所の特定をする。複数箇所で起きているようで、どうもPropelのオブジェクトを生
http://ossipedia.ipa.go.jp/capacity/EV0603280115/ <?php $c = new Criteria(); $c->addDescendingOrderByColumn(ArticlePeer::CREATED_AT); $pager = new myPropelPager('Article', 10); $pager->setCriteria($c); $pager->setPage($page); //$pager->init(); // COUNT $pager->initFoundRows(); // SQL_CALC_FOUND_ROWS <?php class myPropelPager extends sfPropelPager { protected $results; public function initFoundRows
New ORM Designer 3 called Skipper is available on our new site www.skipper18.com visual editor for ORM frameworks Create your visual model and let ORM Designer to export schema definition files for you. Save up to 75 % of your time thanks to automatic export, error elimination and other improvements.
symfony+propelで数千回ループするバッチを走らせたところメモリリークしてどうしても途中で処理が終了してしまう。 調べた所、phpのガベコレのシステムで変数を循環参照させてしまうと、変数の参照カウンタが0にならずにメモリを開放してくれないのが原因だった。 propelで one-to-many のリレーションをしているテーブルを扱う場合、 $one_object->addManyObject($many_object); といったメソッドがあるのだがこのメソッドに循環参照するコードが含まれていてメモリリークしていた。数千回ループ回すバッチとかで使用する時は要注意。 public function addManyObject(ManyObject $l) { $this->collManyObjects[] = $l; $l->setOneObject($this); // ここで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く