t_wの輪郭

Feedlyでフォローするボタン

メモリが90%台のところに来ると落ちている。indexedDBか、localforageがメモリーリークしてる?
保存している量というよりは、読み書きの回数な気がする。要検証。一度ローカルへの保存を止めてみよう


XMLHttpRequestがメモリリークしていたXMLHttpRequestの処理をpanel.jsへ移動させて、推奨ページを表示する際に更新がかかるようにすれば、強制的にメモリーを解放させられるはず
 →ダメだった。メモリー消費は変わらず、サイドバーが重たくなっただけだった

→Fetchに置き換えたら治ったっぽい。メモリーの増減が安定している。
 →ダメだった。メモリーの消費は抑えられたが相変わらず落ちる

→気が付かない間にメモリーが消費されていた。動画などの大きいデータを取ってきてしまうと、メモリーに直撃してしまうので、クローラがHTMLだけを取りに行くようにする。
 Accepttext/html,application/xhtml xml,application/xml;を設定した。よくわかってないがこれでHTML,XHTML,XMLだけが取られてくるようになるはずだ。
Assertも追加した。取ってきたファイルサイズがAMAZONの欲しいものリストの100倍以上の時にエラーを出してくれる。これでどういったデータで問題が出ているかがわかるようになる。最悪停止するから調査ができる。アンドンだ。

→トイレでうんこしてる間にFirefoxが落ちた。文字通りの>クソ<アドオンである。ログをファイル出力しないと、調査もままならない。Firefoxにログのファイル出力機能が見つからない以上、Web Prowler自身にそういうスクリプトを組むしかない。
 →やめた。ファイル出力したとしても、エラーをハンドルしなければいけないので無理だった。

→pages_register_on_messageに排他制御を入れたらメモリー消費が劇的に減った。同時に実行するとだめらしい。

①Bookmarkの再読み込みが起きている。データがある場合にはブロックする処理を突き抜けている。なんでや。

②Bookmark再読み込み際に、以上にメモリーを消費する。pages_registerの作りが悪い。一度すべてをメモリーに読み込んでから処理している。大体において再起動時にはPageのデータが増えているので、BookmarkされているPageをすべてメモリーに読み込むとすごいことになる。

上記二つを改善しなければいけない。②から先にやった方が良いだろう。①を治す前の方が現象の確認がしやすい。


②データ並列の範囲を広げた。登録まで一気通貫。一個流しは大正義。計測はしていないが、早くなった気がする。

メモリー消費推計

2021/6/3 20:51:00

トークン
1ページあたりおよそ40文字
10万ページでおよそ70MB

url
1ページでおよそ80文字
10万ページでおよそ128MB