swap onができるM001くん。
Swapper2で試しても、前の記事と同じように動作しているのが確認できた。
で、具体的にswapによってどの程度の効果があるのか。
M001を使っていて、こんなことはないだろうか?
・重いアプリのMENUを出した時、MENUの表示がつまずく。
・アプリからHOMEに戻った時にしばらくブラックアウトする。
・エラー"ホーム操作(プロセス:android.process.acore)は応答していません。"
M001の決定的な貧弱さはCPUにあるんだけど、それに輪をかけて足を引っ張っているのがメモリの少なさ。
Androidが立ち上がって、各種バックグラウンド処理が走り、アプリが起動して行くとあっという間にメモリ残が少なくなってくる。
で、それでもがんばってけなげにアプリを動かしているんだけど、足りなくなってくるとどうするのか?
それは、使い古しのメモリ領域を開放するようにカーネル(や多分Java)が作業を始めてしまう。いわゆるガベージコレクション。
そうなると、メモリ領域が確保できるまで表の処理は固まったように止まってしまい(あるいはノロノロと動き)非常にストレスになる。
"応答していません。"エラーは典型的な処理待ち状態のエラー。と言えるだろう。
で、結局原因は、狭いメモリ空間に縛られるからこうなるわけで、swapによって少しでも広げれば重いガベージ処理が走らなくて済むはずだ。
問題は、ガベージ処理時間 > ページスワップ処理 である状況にしなければ、swapが頻発して足を引っ張れば意味を成さない。
しかし、幸いに、と言うか、不幸にと言うか、CPUがしょぼいおかげで、ガベージに高いCPUコストを払うより、ページスワップした方が効率が良さそうなのだ。
必要なときに掃除しなきゃならないのはコスト高。
必要なときにすぐに仮想メモリ空間が使えた方がストレスがない。
ま、理にかなってますわな。
よく誤解されるのが、
「swap onにすれば、サクサクだよ」
ってこと。
swapはより広いメモリ空間を取れるようにする仕組みで、決してマシンを高速化するものではない。
しかも、swapが多発すると逆に負荷が掛かり遅くなる。
でも、実際にはトータルでのメモリ利用効率の改善があり、体感でストレスが減っていると感じられると言うこと。
なのでしょうな。
ところで、swapパラメータに、"swappiness" と言うのがある。
これを上げるべきか下げるべきかは、どんな風に利用するかによると思う。
小さな値にすると、できるだけオンメモリ処理するように、swapしにくくなるけど、アプリによってはメモリを確保しようとガベージ処理が走る可能性がある。
大きな値にすると、頻繁にswapしてガベージ処理の発生を押えるけど、swap先のメモリ参照が多く発生すると、余計なswapが増えてしまう可能性がある。
ちなみに、私は今のところswappiness = 40で動かしている。
"応答していません。"エラーが頻発するようなら数値を上げる方向で調整するのがいいのかも。
0 件のコメント:
コメントを投稿