2012年7月1日日曜日

消費メモリの検証

前回少し書いたが、parmanent vacationアルゴリズムの検証時に、1100件前後読み込んだ段階でcode=12のエラーが吐かれた。生成したpostのuiviewを配列に入れたままいつまでも使えるようにしていたので、いつかは限界を超えるのは素人の私でもうすうす気付きつつ見ないようにしてきた。でもやっぱり逃げられないようなので検証してみた。Instrumentsでallocationsの推移を見守るだけ、という検証というのもおこがましい作業だが、私にはこれで限界。

まず、配列にpostのuiviewをぶちこみ続ける現状の仕組みのままでの数値。

・500posts / Live Bytes:171.24MB / Living:141153
・1000posts / Live Bytes:325.78MB / Living:223672

このまま続けようかと思ったが1250件あたりで400MBを超えたので一旦停止。4Sでもメモリ512MBなのでこれはいくらなんでもまずい。

で、直近100件だけ残して、それより前のpostはNULLで殺してみた。配列の要素としては残す。

・500posts / Live Bytes:55.00MB / Living:69924
・1000posts / Live Bytes:48.86MB / Living:76970

歴然。ここまで予想通りに結果が出ると逆に怖くなる。postによってメモリの喰い方が違うみたいなので、Live Bytesはだいたい38~55MBあたりをうろちょろ。100件戻る奴はおらんやろー。個人的にはもうちょい少なくてもいいけど、一旦これでいく。これで文字通り原理上ほぼparmanentな仕組みになった。というより早くAPI側でoffsetの制限取っ払って欲しい。こんなトリッキーなことさせるほうがよっぽどサーバに負荷がかかる気がする。

0 件のコメント:

コメントを投稿