いまから5〜6年前だろうか。「ネットブック」、あるいは「ミニノート」と呼ばれるコンピュータがはやったことがあったのを覚えていらっしゃるだろうか。
比較的能力の低いCPU、狭い液晶画面、小さなHDD、少ないメモリ領域という形で、性能をぐんと抑えつつ価格を5〜6万とものすごく安くしたコンピュータである。
ただ、その後間もなく登場したタブレット機器に押されて、一気に下火になり、今は店頭で見かけることもまずなくなってしまった。
さて、私の手元には、2008年9月に投入したこのネットブックがある。Acer Aspire ONE、AOA-150Bbである。
性能はといえば、
- CPU…Intel Atom N270 (1.6GHz, デュアルコア)
- メモリ…1GB (増設不可)
- ハードディスク…160GB
- プリインストールOS…Windows XP Home Edition
というものである。ちなみに、私が欲しいなぁと思っているタブレット、Xperia Z2タブレットでは、
- CPU…Snapdragon 801 (最大2.3GHz, クアッドコア)
- メモリ…3GB
- 記憶容量…32GB
- プリインストールOS…Android 4.4
と、ストレージさえ除けば処理性能は圧倒的に上回っている。もうそんなボロいネットブックなんて処分してしまえばいいとは思うのだが、そこは「もったいない」精神が働くというわけで、できる限り現役のまま使ってあげたいというのが私の気持ちである。
現在このネットブックは、Ubuntu 12.04 LTS(当然32ビット版)が動作している。以前はWindows XPとのデュアルブートであったが、XPのサポート終了に伴ってWindows領域を削除、さらにディスクパーティション構成を組み替えて、完全にUbuntu専用機になっている。
なお、さすがに処理性能を考えて、Unityは2Dとしてある。他の軽量デスクトップも考慮に入れてはあるのだが、持ち歩いて頻繁に使うこと、電源性能(サスペンド、ハイバネートのしやすさ)の問題で、重いがUnityを使用している。
で、これがどれだけ遅いのかということだが、簡単なベンチマークということで、Google ChromeとFirefoxを、起動後Unity操作可能時点で同時にクリックし、両方が起動する時間を測定してみることにした。Google ChromeもFirefoxも、数個のタブがすでに開いており、それを読み込みながら起動する設定となっている。
- Google Chromeの画面(どこか1つ)が出てくる時間…4分10秒
- Firefoxの画面(どこか1つのタブ)が出てくる時間…7分30秒
普通のコンピュータでブラウザ1つを立ち上げるのに7分かかっていたら処分した方がよいに決まっている。
このようにとんでもなく遅い原因はメモリ不足である。最近のブラウザであれば、数個タブを開いていれば1GBなんてあっという間に食ってしまう。つまり、ブラウザを立ち上げていると(もちろん、起動直後なので、他のプロセスも次々に起動しているが)メモリを食い、1GBを使い尽くすと、今度は仮想メモリ(スワップ)領域へのデータ移動が始まり、両方でディスクアクセスを取り合ってずっとディスクにアクセスしたままになる、という構図である。
(なお、この実験のときには、スワップのしやすさを表す数値 swappinessは通常の60から10へと変更して、よりスワップがかかりやすくしている。)
この遅いマシンを何とか改善したい。そこで目をつけたのは、使われずに自宅で放置されていた2GBのSDカードである。
Aspire ONEには2つのカードスロットがある。1つは右側にあるSDカード専用スロット、1つは左側にある、SDカードなどいろいろなカードを読み込めるマルチカードリーダースロットである。
作戦としては、このどちらかにSDカードを挿入、スワップ領域をこちらに移設して、高速なアクセスを実現させようというものである。
なお、大量のアクセス(読み書き)が発生するため、SDカードの寿命は著しく短くなってしまうが、もともと使われていなかったSDカードなので、そう惜しいという気持ちはない(もし皆さんが実践されるときには、その点よく注意して欲しい)。
作戦はこうである。
- Aspire ONEのSDカードスロットにSDカードを挿入
- 起動時にマウントさせるように認識、かつそれがスワップ領域であるようにする
- スワップ領域をこのSDカードに割り当て
- swappinessを調整してわざとスワップされやすいようにする
今回は、左側のマルチカードリーダースロットをスワップ用SDカードに割り当てた。これは、Ubuntu上では/dev/mmcblk0p1として参照することができる。
普通に挿入するとリムーバブルメディアとして認識されてしまうので、まずマウントを解除、次にディスク領域をスワップ領域として確保する。これは、Ubuntu付属の「ディスク」ツール、GParted、コマンドラインからであればfdiskなどいずれかで可能である。これらでSDカード領域をまるごとスワップ領域にする。
最後に、起動時に必ずマウントされるようにするため、/etc/fstabをちょっとだけ改良する。もしもともとスワップ領域を設けているのであれば、そのエントリーを参考に次の行を付け加える。なお、もともとあるスワップ領域の行は消さないで、先頭に「#」を入れておき、コメントで無効にする。
/dev/mmcblk0p1 none swap sw 0 0
これでOKだ。再起動するか、
sudo swapoff /dev/sda4 (デバイス名は機器によって変更すること)
sudo swapon /dev/mmcblk0p1
を実行すれば、新しいSDカード上のスワップ領域が有効になる。cat /proc/swapsにより、スワップ領域の使用状況を確認することが可能だ。一応、確認しておこう。
次は、スワップしやすくしてしまう(積極的にメモリからSDカードに「吐き出す」)設定である。これは、swappinessという数値をいじる。この値は、スワップのしやすさを表す数値で、0に近づくほどスワップしにくくなる。通常は60であり、最近の大容量メモリを搭載した機種では10や0という値をとることも珍しくないが、今回は逆に、80や90という値にしよう。これを設定するのは、/etc/sysctl.confというファイルである。ここに1行、こういうふうに記述する。
swappiness = 90
再起動してこの設定を有効にすれば、準備完了である。
それでは、どのくらい速くなったかを調べてみよう。先ほどと全く同じ設定で、起動直後にGoogle ChromeとFirefoxを起動して、両者のタブ(のうち1つ)が操作可能になる時間を測定する。まず、swappinessが60(デフォルト値)の場合。
- Google Chrome…3分33秒
- Firefox…2分ちょっと(10秒程度。このとき計測がうまくいかなかった)
まぁもちろんまだ遅いといえば遅いが、先ほどのケースからすれば劇的に改善された。さらに、swappinessを90とし、preloadを有効にした上で(いままではメモリが少ないので有効にしなかった)改めて測定する。
- Google Chrome…2分40秒
- Firefox…2分10秒
となる。Google Chromeで性能が向上しているのは、タブあたりのメモリ割り当てが多いGoogle Chromeで効果が顕著に出ていることを示していると思われる。
もちろん、Firefoxが起動して2分もかかって表示されるのはそれでもイライラするかとは思うが、起動したあとしばらく待ってマシンが落ち着いてから起動するようにするなど、運用を工夫すれば若干気分的にも改善できると思う。
なお、この時点でスワップ領域の消費量は300MBほどで、2GBのSDカードの10数パーセントである。
いろいろ書いたが、この方式は、いってみればWindowsのReadyBoostと同じような考え方で、HDDよりは高速な半導体デバイスに記憶領域を間接的に移動させるというアイディアである。
同じ考え方はデスクトップ機にも応用可能である。例えば、使用していない2GBや4GBのUSBメモリなどが余っているのであれば、それらをスワップとして割り当ててやれば、メモリが少ないマシンでも高速化の効果が出る可能性はある。
ただ、この設定で運用を行って以来、サスペンドやハイバネートが効かなくなってしまった。
サスペンドについては原因が不明である。
ハイバネートは、このSDカードの領域が足りないためと推測される(Write errorが出るのだが、SDカードそのものの検査を行ってもディスクエラーは確認されない)。そこで、ハイバネートをかけたい場合、いったん無効にしたHDD上のスワップ領域を有効にする。
sudo swapoff /dev/mmcblk0p1 && swapon /dev/sda4
これでハイバネートは元に戻るが、運用上面倒ではある。このあたり、いいアイディアがあれば追求してみたいが、もう6年ものとなっているネットブックがいつまで持つかという点も問題ではある。
【2014年8月28日追記】その後のスリープ・ハイバネート対応を別記事にまとめてみました。参考になさってください。