iMacのレスポンス低下とその対策 - その1

僕は昔（2014年3月まで）仙台にいたころプライベートに使っていたiMac（12.5-inch,late2012）を会社のオフィスに持ち込んで、もう1台今の会社で買ってもらったMacBook Pro（Retina 13-inch, Late2013）を普段用に持ち歩いている。

Macなどまかりならん、存在すら許さん、という前の会社とは違ってそんなこと誰も気にもしないので、仕事に気楽に使わせてもらっている。iMacのほうは当時の最下位機種とはいえCPUが4coreの2.7GHzでディスプレイも広いので、長い計算を走らせっぱなしにするか、そうでないなら会社で自分の机の前ではiMacを使って、iMacのそばから離れたときはMacBook Proの方を使う、という感じになっている。

一方で、会社での光学的な実験や組み立て調整用の設備は、ここ2年ほど僕がすべて構想/設計してプログラムしている。それらのうちGigEなどの無圧縮カメラの接続が必要な設備のホストには今のところすべてMac miniを使っていて、もうそれが5台も溜まってしまった。そう言う状態に対しても誰からの文句もない。ようするに設備が機能を果たせばそれでいい、ということである。

使うsdkをホストごとに変えるなんてことはしたくないし、OSのバージョンは統一されていた方が問題は少ないはずである。そこでこないだまずiMacとMacBook ProをmacOS 10.12 Sieraに上げた。このあと順次転がってるMac miniを同じように上げる。僕はSieraで導入されたAPIを使わないといけないというようなことはなかったのでやりたくなかったけど、まもなく6台目を入れる必要があってそれには当然Sieraが乗ってくるるのでしかたなく（ハードウェアはアップデートされてないので10.11でもインストールできるかもしれないけど）。

SieraにあわせてXcodeも8.2.1に上げた。普通のunixなら/usrにある開発用のディレクトリやドキュメントを取り込んだりというせいもあるけど、それ以上にXcodeの肥大化が著しい。

というふうにOSやいろいろなアプリケーションをアップデートしたり新規に入れたりしているうちにiMacがどんどん遅くなってきた。

今回は思うこと考えたことを交えながらチンタラと書くことにする。それって、いつもの通りじゃん．．．．．

1.1  Siera以外の環境変化

OSを10.12にあげて、同時にXcodeも8.2.1にして、さらにMathematicaに続いてとうとうIllustratorとPhotoshopを古いCS2からCCに会社の費用で上げさせてもらった。CS2はOS X10.10あたりからフォント関連のメニューやダイアログには真っ白のままいっさい何も表示されない、アートボードを分割しても何かの拍子にデフォルトに戻ってしまう、特定のプラグインを起動するとフリーズする、などなどいろいろ不具合が出たまま使い続けていた。

僕は88と呼ばれた時代からずっとIllustratorを使ってきて、もういまさらぱわぽなんか使えないし、この歳で見ず知らずの新しいソフトを覚えようとしたら、使い慣れて効率が上がってくる前に僕の方が使い物にならなくなるのではないか、と思ってしまうのでこのまま行きたい（どうでもいいけどMathematicaもIllustratorも使い始めてからまもなく30年になる。そうえいばLaTeXもそうだな。化石のような前世紀の遺物だな。それらのソフトがいまだに生き残っている、というのがすごいということだろうけど）。

でもIllustratorって値段が高いのね、ほんとに。しかもサブスクリプション制になって毎年会社で稟議を起こさないと使い続けられなくなった。CC固有の新しい機能なんてまったく使わないのに。それはMathematicaも一緒で、機能を増やすより計算効率を上げてくれ、カーネルの並列化より個別の計算のレベルでMulti-threadにしてくれ、そしてもういいかげんFrontEndをx86_64にしてくれ、と僕としては切に願う。

ちなみに、MacBook Proはひと世代前でストレージが128GBしかないので

• OS本体
• Mathematica
• Parallels Desktop（レンズ設計ソフトZemax起動用のWindows8.1環境）
• IllustratorCCとPhotoshopCC
• Xcode
• LaTeX関連ファイル
• その他メールやブラウザなど

などのアプリのインストールだけでほぼ使い切ってしまう。しょうがないのでこないだ200GBのmicro SDカードを買ってMacBookのSDスロットに入れっぱなしにして普段使わないアプリなんかを追い出した。出費がかさむが、まあSSDを倍にするよりは安上がり。

一方のiMacは今の会社に移ってからそのまま仕事にだけ使うことにしたので基本的に同じことができるようにしてある（Adobe製品は一つのライセンスで主と従の最大2台までのマシンにインストールできて、Mathematicaは買って1年間はおまけでホームユース1本がついてくる）。またiMacでは去年一回HDDを換装するということをしている。

1.2  iMacが遅くなってきた

いろいろ続けざまに変えてしまったせいで何が支配的な原因なのかわからないんだけど、iMacがどんどん遅くなってきた。

まずブートに時間がかかる。これはもちろんmacOS 10.12のせいだな。遅くなる要素になにがあるのかわからないけど。Xcodeも起動するのに1分を超える。巨大なソフトなのでしょうがないといえばしょうがないのかもしれない。

もっとひどいのはIllustratorCCで、起動に10分近くかかるときがある。立ち上がってからも「新規ファイル」に1分以上待たされる。何かの拍子に（自覚的な原因なく）ビーチボールが回りだして分（ふん）のオーダの時間待たされたあげく入力待ち状態に戻るだけで、なにを待っていたのかわからないことがよく起こるようになってきた。また特にフォント関連は非常に遅い時がある。MacBookのディスプレイは13インチでiMacは21.5インチなので、Illustratorのパネルを開きっぱなしにして作業するにはiMacのほうがやりやすいのにレスポンスが悪いせいで、作業効率はかえって低いということになってしまった。

しかし何が困ると言って、キーボードからの文字入力でビーチボールが回ること。特にかな漢字変換でひどい。ライブ変換がオンになっていると一文字入力したあとビーチボールが現れてそのあとの入力が表示されなくなるのでオフにしたけど、やはり変換を起動するたびにビーチボールになる。

それになぜか辞書に登録しないかぎり例えば「こうがく」という入力に対して「高額」や「工学」や「後学」が選択肢の上位にいつまでも居座るようになった。僕は「光学」以外入力したことがないのに。

Lauchpadでも名前で検索しようとすると、文字が入らない。数十秒待って検索フィールドに文字が現れるけど、すでに入力済みのリターンキーは無視されるらしくて、さらにぼーっと待ってしまったりする。もうLaunchpadは全く使えなくなってしまったので、普段使うアプリのエイリアスを集めたフォルダを作ってドックに入れるという、OS Xになったばっかりのころ使っていたやり方が復活してしまった。

1.3  iMacでの作業効率低下要因

ようするにどれも肥大化してしまって動きが悪くなっている、ということだろう。こういうのはある面しょうがないのかもしれないけどなんとかならないものかと思ってしまう。起動が遅いだけなら先に立ち上げておけばいいだけだし、僕はどっちかと言えばCPU律速な使い方が多いので、それほど大きな問題ではないと自分に言い聞かせていた。なのでSieraに上げた直後はまあしょうがないか、とあまり気にしなかったんだけど、そのあとIllustratorをCS2からCCにしてCCの重さが相まって作業効率に影響がでるようになってきた。ただでさえ歳のせいで気が短くなっているので反射的な反応を期待しているときに待たされるとイライラする。数十秒なんて間隔が空くとウロがきてそれまで何をやってたのか忘れてしまうこともある。

Illustratorに関しては、起動中にスラッシングでも起きてるのかと調べたり、PreferenceやCacheのファイルを捨てるといいとかいうのを読んで試したりしたけど、それほど改善しない。Illustratorがビーチボールを回しているあいだ、アクティビティモニタを見ると、CPUの負荷は10%台、ディスクもネットワークもわずかなデータの読み書きしかしていない。ようするにコンピュータ全体としてほとんど何もしていない、という状態。これを見るだけでは何が律速しているのかまったくわからない。

CS2からCCにしてなにやらわけのわからんデーモンプロセスが大量に立ち上がるようになった。しかも同じ名前のプロセスが3つも4つもある。まったくもってひどい。目に止まるものだけでもAdobe Spaces Helper×3プロセス、AdobeCRDaemon×4、CEPHtmlEngine×4、CEPHtmlEngine Helper×10、Core Sync Helper×4などなど山のようにある。それ以外にもOS側が起動している複数起動デーモンがaslmanager×2、 AssetCacheLocatorService×2、cfprefsd×3、coreaothd×3、dbfserventsd×3、distnoted×5、lsd×3、mdflagwriter×3、mdworker×5、nsurlsessiond×2、nsurlstoraged×2、periodic-wrapper×2、secinitd×3、sharedfilelistd×2、trustd×4などなど、見たくなくなるほどある。

それぞれ全部がたくさんのファイルをオープンしたままにしているし、CPUやメモリなどのリソース要求は高くないといってもunixの一般的なデーモンプロセスの要求量に比べると1桁も2桁も多いものがほとんどである。こういうのはボディブローのようにパフォーマンスに影響しているということは十分考えられる。

このままではiMacを使い続けるのが嫌になりそうなので、律速段階を調べることにした。

1.4  MacBook Proとの違い

ところで、iMacとMacBook Proとで同じ環境でないと不便なので合わせることにしてるんだけど、MacBook Proではそれほどひどくない。かな漢字変換のライブ変換も快適、というほどではないけどビーチボールは現れずに入力できる（もちろん僕には両方で同じ扱いでないと不便なのでMacBook Proでもライブ変換は切ることにした）。iMacの反応の悪さがOSやアプリケーションの肥大化が主な原因であるにしても、この差はおかしい。

それぞれどういう状態かというと

• メモリはiMacもMacBook Proも同じDDR3の8GB
• 両方ともほぼ同じアプリケーション（Mathematica/Xcode/Illustrator/LaTeX/その他）が常時起動
• MacBook ProのほうだけにさらにZemax用Windows環境（が、めったに起動しない）
• ネットワークはWi-Fi接続、ただしiMacは11nでMacBook Proは11ac（環境が悪くてどちらも50Mbps程度しかでてない）
• ブートストレージのバスはiMacがSATA Rev3.0、MacBook Proは2レーンのPCIe2.0
• ストレージデバイスはiMacが2.5インチHDD 1TB、MacBook ProはSSD 128GB

少なくともSpec的にも環境的にもそれほど差はない。ストレージ用のバスは違っているけどビットレートで言えば倍までの差はない。ということで詳しく調べるまでもなく、やはりストレージ用デバイスの違いが原因で、この差がこれだけの応答性に反映しているということだとしか考えられない、ということになる。

iMacはデスクトップマシンのくせしてHDDは2.5インチを使っているので、パフォーマンス的には不利である。しかしもしそのストレージデバイスの性能のせいだとすると、今売られている最新のiMacの最下位機種はストレージ周りが僕のiMacと同じなので、そのレスポンスはあまり変わらないということになる。そんなので売り物になるんだろうか。まあ、最下位機種でIlustratorを使おうとする方が悪い、とか言われるんだろうな。

2  ストレージベンチマーク

僕はいわゆるハードウェアのベンチマークの結果を何かの参考にすることはまったくなかった。僕はソフトウェアからAPI経由で見える部分ぐらいまでしか理解していないので、ハードウェア固有の違いをあまりわかっていない。だからベンチマーク結果が違っていても「ふーん」で終わってしまうことが多い。

そもそも、CPUのオーバークロックなんかと同じでムービーのエンコードならいざしらず、1割2割の違いが作業のスループットに影響を与えるとは僕は思わない。ましてやストレージのスピードなんて倍半分違っても、多画素高fpsムービーのリアルタイム読み書き以外で直接影響することはまずない。

したがってパフォーマンスの違いといっても桁（十進で）が変わるか、あるいはそれに近いぐらいの差でないと意味がない、と僕は思っている。

もちろんソフトウェアの実行効率のベンチマークは特に数値計算ではアルゴリズムの違いで実行効率が何桁も違う、なんてことがよくあるのでちゃんと比較するようにしている。しかし、ハードウェアのベンチマークソフトとかを使ったことも動かしたこともなかった。

しかしこのiMacとMacBook Proとの差がストレージだとしか思えないので比較することにした。

HDDを新しく買った人たちが数字の（僕から見れば）わずかな差に一喜一憂するのに使っているベンチマークソフトであるWindows用のCristalDiskMarkがAmorphousDiskMarkという名前でmacOSにも移植されているらしい。これを使って比較することを考えた。

2.1  何を測ってるの?

Windows版のベンチマークアプリCristalDiskMarkはMicrosoftのdiskspdというコマンドラインツールを使っているらしい。dsikspdはソースがGitHubで公開されている。cloneして中身を見るとちゃんとドキュメントがあるが、大量にある測定パラメータの説明があるだけで、具体的に何を測っているのかよくわからない。

しかし、おおすじとしては

1. ある大きさのデータを読み出すのにかかった時間（Read）
2. ある大きさのデータを書くのにかかった時間（Write）

を測っているらしい。データの大きさはパラメータとして可変になっている（が、大きさそのものはけっこう大きい）。そして

1. 連続したデータ（Sequential）
2. 全体サイズは同じで場所がいろいろのデータ（Random）

に対して行うらしい。場所がいろいろの場合でもそれぞれのデータのサイズは同じで、それもパラメータになっている。さらに

1. NCQを使わない場合
2. 使った場合

を比較しているらしい。NCQって？

2.2  NCQって何?

NCQ、つまりNative Command Queuingというのは読み書きのコマンドをHDDが持っているキューに入れて、その中で一番早く実行できるコマンドから処理するというものらしい。どのコマンドから実行されるかはHDD自身が決めるようである。このおかげでシークの効率を考慮して全体のスループットをあげられる、という発想だろう。ホスト側から見るとコマンドが非同期に投入順に関係なく実行されて見えるということになる。

簡単に考えれば、HDDではディスクの回転位置とヘッドのトラック位置で最適化するということだろうけど、読み書きするデータがある程度大きい場合は、直前のコマンドが実行終了する時点でもっとも回転位置の近いデータに向かってヘッドをトラック移動させることを考えればいい。そのときトラック移動が間に合わない位置にある（トラッキング時間が回転時間より長い）場合はそれを後回しにしてその次を計算するというアルゴリズムだろう。計算そのものはデータを読み書きしている間にすればいいのでそのオーバーヘッドはたいしたことはない。

しかし、小さなサイズ、極端な場合セクタごとにの読み書きが連続すると計算が間に合わない場合があるかもしれない。そのときはちょっとめんどくさいことになる。コマンドがキューに追加された時点で割り当てを最適化する必要がある。そのほうが計算は複雑になるけど、計算量は減らすことができる。HDDってどんなコントローラを積んでいるのか知らないので計算のスループットもよくわからない。まあ細かい話はどうでもいい。

コマンドの到着順に処理していたら平均的にはコマンドごとにほぼ半周+αのディスク回転が必要になるはずなので、要求されているデータが小さく、ランダムにたくさんあるときにはNCQによって効率の改善が期待できる。

ベンチマークアプリが表示するQDというパラメータがそのキューの長さらしい。QDというと業界ではQuatum Dotのことだと思ってしまうんだけど（どこの業界じゃ）そうではなくてQueue Depth、つまりキューの長さ（深さ）を言っている。QDもパラメータになっているけど、HDDごとにその上限はおそらく決まっているはずである。

2.3  HDDとSSDのベンチマーク条件の違い

2.3.1  SSDでのNCQなど

あきらかにNCQはHDDのためのもので、SSDには無関係と思われる。しかしSSDも全てのバイトがリニアにアドレスされているわけではなくて、ページなどに分割されて階層化されているだろうから、読み書きのデータサイズがページサイズ以下の場合に、同じページへの読み書きが集中した方がスループットがあがる、とかいうことはあるはずである。従ってSSDでも差が出るかもしれない。少なくともアクセス順がデバイス側である程度自由度を持つことができるということは、悪い話ではないだろう。

またNCQとはべつに、Wear Leveling（同じセルばかり書かないように分散して均一化する）との関係でSSDではしばらく使った後はデータが連続していようがバラバラだろうが関係なくなると思うんだけど、どうなんだろう。

それにHDDは磁気記録のレベルでは読み書きのビットレートは同じだけど、SSDはフラッシュメモリなので書き込みには時間がかかる（一旦消してから書き込む）。それがスタティックメモリのキャッシュによって埋め合わされたりかえって差が出たりするんだろう。厳密には難しいな。

また、コマンドレベルでは大きなサイズもサポートされているはずなので（SATAのコマンドはSCSI互換だったっけ。忘れた）コマンドごとの読み書きのサイズによってSequentialだろうがRandomだろうが関係なくなるかもしれない。

2.3.2  ファイルシステムとの関係

diskspdのソースを見てもなかなか何をやっているのかすぐにはわからない。gitで落としてきたCommon.cppにあるTargetというクラスがドライブを表していて、IORequestGeneratorが読み書きをするクラスのように見えるけど、ちょっと眺めただけではわからない。

ざっと見る限りではSATAコマンドを発行するようなコードは含まれていないようで、読み書きはファイルシステムを経由していると思われる。その場合、当然ファイルシステムのスループット込みでの測定ということになる。そうだとするとNCQの有無ってどこで制御するんだろう。よくわからない。ダイナミックライブラリをコードの中で明示的にロードしているように見えるところもあるので、ひょっとしたらそのライブラリがなにかやってるのかもしれない。僕はWindowsはまったく知らないので全然わからない。

root権限になってファイルシステムを飛ばして、ストレージに対して直接コマンドを発行すれば裸の測定に近いものになる。その場合書き込みは中身をいったん読み出して保存しておいて、書き込み速度を測定して、そのあと保存したデータを書き戻す、あるいは読んだデータと同じものを書いて測定すればいいように思える。しかしそれは非常に危険である。書き込み測定の最中にファイルシステムが書き換えを行ったり、ベンチマークアプリが書き込み測定中にクラッシュするとファイルシステムに壊滅的な打撃を与えることになる。

したがって、読み書きのための領域をファイルシステムに対して確保したあとロックして、その領域に対して直接コマンドかあるいはそれに近いレベルのファイルアクセスAPIを呼ぶということをやっていると思われる。連続した大きな領域を確保できるかどうかはそのときのファイルシステムの状態によるので、そのへんどうなんだろう。

そういったいろいろな条件によって結果がかなり左右されるかもしれない。まあ、ハードウェア設計をしているわけではないし、基準は「最低倍半分」なので細かい話は無視することにする。

ちなみにdiskspdのソースを見るとWindows固有のAPIを使っていてWindowsしか眼中にない。macOSへの移植はどうやったんだろう、と思ってしまった。 AmorphousDiskMarkの作者のフォーラムによると、macOS版はdiskspdの移植ではなくて、CrystalDiskMarkと同じことを実行するような専用のテストエンジンを書いた、と言っている。すごいな。驚いた。

3  MacBookに対するiMacのベンチマーク結果

3.1  ベンチマーク条件

ということで比較してみた。僕は倍半分以下の差は差ではないと思っているので、細かなパラメータの違いはどうでもよくて、代表的な値さえ得られればいい。また今回は、数値の絶対値そのものにも興味はなくて、MacBook Proに対してどのくらい違うのかがわかればいい。

ということでベンチマークソフトのデフォルトで比較してみた。メモリの状態はスラッシングみたいなことが起こっていなければ関係ないと思われるので、どちらも作業中に行った。

また、iMacのHDDはS.M.A.R.T.情報によると交代セクタの発生はなく、大筋では健康な状態ということだった。MacBook ProのほうのS.M.A.R.T.はsmartmontoolsの知らないアトリビュートばかりらしくてよくわからない。

ちょっとダラダラ書きすぎた。結果は次回にする。それは僕にはびっくりするぐらいのものだった．．．．．