iMacのレスポンス低下とその対策 - その2 [日常のあれやこれや]
昨日の続き。使い続けるのが嫌になるくらい反応が悪くなったiMacに対して、MacBook Proとの比較のストレージベンチマークの結果と、その対策をどうしたか、そしてとりあえずの解決は見た、という話。
そのためにこの数日、会社のオフィスでiMacをがば、と開けて臓物をあらわにしながら派手に作業をしていた。これも仕事の効率を上げるため、と周りのみんなに言い訳した（言い訳しなくても僕の普段の様子からみんな気にもしないようだったけど）。そして待ち時間も多いのでこの文章は仕事時間中に書き始めていた。仕事時間中にこんなことを書いているとなぜかダラダラといっぱい書いてしまう．．．．
まず生データ。パラメータはすべてアプリのデフォルトの値になっている。
左がiMacのHDDで右がMacBook ProのSSD。それぞれ左の列がReadで右がWrite、上からNCQつきのSequentialとRandom、さらにNCQなしのSequentialとRandomであるらしい。デフォルトなのでデータサイズは全体で500MBで、Randomの場合のブロックサイズは4kBとなっている。NCQのキュー長さは32だけどHDDがその長さのキューを持っているかどうかわからない。
まず左のHDDではNCQがあろうがなかろうがパフォーマンスに差はない。これはつまりこのHDDにはNCQが実装されていなかったということらしい。一方のMacBook ProのSSDはなぜかNCQでRandom Readに大きな差が出ている。SSDなのになんで一桁以上も違うのかよくわからない。
これだけではiMacのHDDとMacBook ProのSSDの差がパッと見てわからないので、比をグラフにしてみると
縦軸はMacBook ProのSSDのスピードに対するiMacのHDDの比を対数で表したもの。0だとiMacはMacBook Proと同じで、-1だと一桁（十進で）遅い、ということを表している。
MacBook Proを基準にするとだいたい10〜100分の1のスピードしかなく、どちらかといえばReadのほうで差をつけられている。とくにNCQつきのRandom Read（これがごく普通に使っているときの読み込みパフォーマンスに近いだろう）ではなんと千倍近い差がある、つまり極端に言えばMacBook Proでは1m secで終わるはずのことがiMacでは1秒近くかかってしまう、ということになる。
Writeの方が差が小さいというのは単にSSDは読むより書く方に時間がかかる、ということだろう。
まあ、これだけ違えば体感であきらかな差がでても不思議ではない。
僕は遅いiMacをマシにしたいんだけど全部をSSDにするわけにもいかず、またマシン本体を買い換えるなんてことはありえないし、かといってこのままでは使い続けるのが厳しいと思ったので、ついこないだこわれて交換したばっかりなんだけど、iMacのHDDをそのハイブリッドHDDに替えてみることにした。置き換えられるHDDは交換したばかりでまだ若々しくて達者なんだけど、実験専用のNAS用ストレージとして余生を送ってもらうことにする。
買ったのは東芝の1TBのMQ02ABD100H。Specには書いてないんだけどウワサではSSDを8GB積んでいるらしい。1TBに対して8GBというのはキャッシュとしてはちょっと小さいという感じがしないでもないけど、クリティカルなファイルがSSDに収まってしまえば改善はかなり期待できるはずである。
Fusion DriveではHDD1TBにSSD24GBらしいので、OS本体とそれ以外のよく使うアプリのイメージはほとんどSSDに乗ってしまうだろう。またFusion Driveの場合はOS（というかファイルシステム）の介在が可能なので、どのデータをSSDにキャッシュするか、という意図を反映させることもできる（たとえばOSのイメージは優先的にSSDに乗せるようになっているらしい）。ハイブリッドHDDの場合はそれが不可能なのでキャッシュアルゴリズム頼りとなる。
しかし僕はブートが速くなる必要はない。アプリケーションの起動も10分を超えたりしなければ我慢できる。問題なのはまずかな漢字変換、Illustratorの起動後に利用時点で読み込まれるプラグインのモジュールとかなので、ちゃんとキャッシュされれば8GBで十分すぎるぐらいである。
したがってハイブリッドHDDの場合、ストレージアクセスは定常化されているのが望ましい。つまりだいたい同じようなデータを読み書きしている、という状態だとSSDの読出し速度の優位性が発揮されるはずである。
まあ、それはどんなキャッシュシステムでも同じだけど、この場合はマシンをいったん立ち上げて普段使っているアプリをロードしたら、あとはなるべくそのまま使い続けるのがいいということになる。ごく普通のキャッシュアルゴリズムを使っているのであれば、おそらくOSのロードとアプリの起動でキャッシュとしてのSSDの中身は書き換えられてしまうだろうからである。
書き込みのデータをキャッシュに残すかどうか（SSDに書くかどうか）、というのも微妙な問題である。SSDとHDDとでは読出しには大きな差があるけど、書き込みでの差は縮まる。パソコンのストレージではWrite Onlyなデータも多いので、SSDには読出しデータだけを選択的に残したほうがヒット率は上がるかもしれない。
キャッシュアルゴリズムとして読み出し回数を保持して多いほどstickyにする、つまり追い出されにくくするとパソコンのストレージ用途ではヒット率が上がるということもあるかもしれない。また、そうすればフラッシュメモリ固有の問題である書き込みによる劣化を軽減できるはずである。実際にハイブリッドHDDがそうなっているかどうかは全然知らないし、確認できない。
そんなことを考えていると、それはそれで面白い問題という気もしてくるが、まあ僕のやるべきことではない。
しかしひとつ問題が発生した。TimeMachineから復元しようとするとまずHDDをフォーマットするところから始まるんだけど、何度やってもそのフォーマットに失敗する。単独の「ディスクユーティリティ」では問題ないのに、なぜかうまくいかない。焦ってしまった。
TimeMachineを諦めてすっぴん状態に戻す、というのを試した。OS X10.8（Mountain Lion）がネットワーク経由でインストールされる。これはなぜかフォーマットもうまくいって立ち上がった。そこからTimeMachineで復元するとうまくいって元に戻すことができた。
「TimeMachineからの復元」のフォーマッタは「ディスクユーティリティ」のとは違っているようである。Appleはおかしなことをしている。
立ち上がってから「ディスクユーティリティ」で見てみるとTypeがApple_CoreStorageではなくてApple_HFSとなっていた。CoreStorageの論理ボリュームではなく古い物理ボリュームとして動いていた。なんらかの理由でハイブリッドHDDはCoreStorage用のデバイスにならなくて、「TimeMachineからの復元」のフォーマッタが対応していなかったのかもしれない。こういうのは「できませんでした」ではなくてちゃんと理由を言うべきである。
まず、同じパラメータで交換前後で比較したグラフがこれ
書き込みはとんとん、読み込みはちょっとマシ（3倍くらい）、という結果。こっちはRandom ReadでNCQありなしの差がちょっとだけある、ということで買ったハイブリッドHDDはNCQに対応している、ということらしい。「ちょっと」と書いたけど、それは僕の感覚でということで、読み出しを非同期にするだけで3倍の改善がある、という意味ではNCQはすごい技術である。
デフォルトのパラメータでは1回しか読まないのでハイブリッドHDDに内蔵されたSSDのキャッシュの意味がない。キャッシュの効果をはかるために読み書きを5回繰り返すという設定に変更して、1回のときと比べたのがこちら
Writeはすべて変わらず、ReadのRandomだけが数十倍に改善されている。データとしては非常にもっともらしい。ようするに内蔵SSDのキャッシュとしての効果がある、ということである。Sequentialで差が出ていないのはベンチマークのデータの使い方によっているんだろう。つまりおそらく同じものを読んでいないんだろう。
ベンチマークアプリとしては5回繰り返せばその平均を表示するだろうから、1回目に対して2回目以降はこの値よりももう少しいいはず（2割り増しぐらい）である。
最終的にMacBook Proに対して交換したことでどのくらい改善されたかを見たのがつぎ
図のそれぞれの左側はひとつめのグラフと同じで、右側がハイブリッドHDDに交換した後の5回読み書きの時のMacBook Proに対する比である。つまり右側が0.0に達したらMacBook ProのSSDと同じパフォーマンスになったということになる。この図を見ればそこまではいっていないということはわかる。
ところで、MacBook ProのSSDも5回読めば違うかもしれないけどそれで一桁変わるということはないはずである。めんどうで時間もかかるのでそれはやめた。だから完全に同じ条件での比較ではない、ということに注意だけど、僕にとってはどうでもいい。
NCQつきのSequential読み書きの改善はHDDがNCQ対応かどうかの違いのように思えるけど、もしほんとに500MBを連続して読んでいるならNCQは関係ないだろうし、HDDのSpec上はバッファサイズが違う（8MB vs. 64MB）ぐらいで他はまったく同じなのでなぜかはよくわからない。NCQなしのRandom読み出しがMacBook Proにせまっているのは、実質的にSSDとしての比較になっているからで、この比が1にならない（対数が0にならない）のはバスが律速しているのか、と思ったけど絶対値はバススピードの一桁下なので、理由はやっぱりよくわからない。
体感的な差がでるのはNCQつき（OSのファイルシステムがNCQに対応したら、わざわざそれを使わずにおくことはないはずなので）の読み込みで、これは大幅改善がある、ということで効果が期待できる。それでもMacBook Proよりは一桁遅いということでこの差がなにによっているのかよくわからない。キャッシュとしてのSSDがヒットしないのが1割含まれていたということなのかもしれないけど、1回あたりのデータサイズが500MBなので、普通のキャッシュアルゴリズムを使っていればSSDの中身は1回目で書き換わってしまってそれ以降は100%ヒットするはずである。ベンチマークアプリのデータの読み書きの仕方にもよる。
これが実際に体感に反映されるか、は使っていきながら確認することになる。とりあえず二日ほど使った感じ（その間リブートしていない）では一番煩わしかったかな漢字変換中のビーチボールはほとんど現れなくなった。ほとんど使い物にならなかったライブ変換もほとんどMacBook Proと感触的には変わらなくなった。これはなかなか素晴らしい。ライブ変換をオンにして使い続けるか、というと微妙なところではあるけど。
IllustratorやPhotoshopの「新規ウィンドウ」が現れるまでの時間もかなり改善された。でもフォントパネルはなぜか開き直してもそれほど差がない。これはなんでだろう。また、Launchpadはやっぱり1分近くまたされることがある。キャッシュのされ方になんで違いが出るのかわからない。他にもブートが速くなるとかアプリの立ち上がりが速くなるとかはよくわからないが、僕としてはそれはどうでもいい。
一点、ハイブリッドHHDをCoreStorageデバイスとしては使えないようなので、ひょっとするとあとあとのmacOSでは「物理ボリュームはレガシーだ」とか言って、ブートデバイスとして使えなくなるかもしれない（Appleはすぐそういうことをするので）。まあ、でもそのときはそのときである。ひょっとするとベータのままの新しいファイルシステムではまた違うことを言い出すかもしれないし（Objective-Cのガベージコレクションがトラウマになってる）。
しかしよくよく考えるとそれなりの出費をして、それなりの時間を割いてなんとかなるとことまで来たんだけど、たかだか3年弱前に仙台でプライベートに使っていたころは、このハードウェアパフォーマンスでなんの問題もなかった。何が悪いと言ってIllustrator、Xcode、Mathematicaと言った僕がふだん使いたいソフトが肥大化していること、そして何よりOSが肥大化してるということである。
企業戦略上しょうがないということは僕もサラリーマンなのであるレベルまでは理解しているつもりだけど、やっぱりどこかおかしいんではないか、と思ってしまう。こんなイタチごっこをしてまでやるしかないのか、と僕自身も悩むところがある。でもそんなことを言ったら僕が仕事でやってることの全否定になりかねない。
まあ、他人から見たら全否定だよそんなもん、で終わりだよな。ああ。
そのためにこの数日、会社のオフィスでiMacをがば、と開けて臓物をあらわにしながら派手に作業をしていた。これも仕事の効率を上げるため、と周りのみんなに言い訳した（言い訳しなくても僕の普段の様子からみんな気にもしないようだったけど）。そして待ち時間も多いのでこの文章は仕事時間中に書き始めていた。仕事時間中にこんなことを書いているとなぜかダラダラといっぱい書いてしまう．．．．
3.2 ベンチマーク結果
普段からしょっちゅうこういうベンチマークを走らせている人にはごくあたりまえの結果だろうけど、僕はこんなに違うのかとびっくりした。まず生データ。パラメータはすべてアプリのデフォルトの値になっている。
まず左のHDDではNCQがあろうがなかろうがパフォーマンスに差はない。これはつまりこのHDDにはNCQが実装されていなかったということらしい。一方のMacBook ProのSSDはなぜかNCQでRandom Readに大きな差が出ている。SSDなのになんで一桁以上も違うのかよくわからない。
これだけではiMacのHDDとMacBook ProのSSDの差がパッと見てわからないので、比をグラフにしてみると
MacBook Proを基準にするとだいたい10〜100分の1のスピードしかなく、どちらかといえばReadのほうで差をつけられている。とくにNCQつきのRandom Read（これがごく普通に使っているときの読み込みパフォーマンスに近いだろう）ではなんと千倍近い差がある、つまり極端に言えばMacBook Proでは1m secで終わるはずのことがiMacでは1秒近くかかってしまう、ということになる。
Writeの方が差が小さいというのは単にSSDは読むより書く方に時間がかかる、ということだろう。
まあ、これだけ違えば体感であきらかな差がでても不思議ではない。
4 ハイブリッドHDDへの交換
ハイブリッドHDDというのがあるのは知っていた。SSHDとも呼ばれるらしいけど、TCPの22番ポートをlistenしているデーモンのことではない。iMacやMac miniではちょっと前からFusion Driveというのが選択できるようになっている。Fusion DriveはOS、というかデバイスドライバのレベル（CoreStorageというらしい。AppleでCoreなんとかというとCoreFundationやCoreAudioみたいなもんか、と思うけどプログラマに解放されたAPIはないのでDeveloper siteにはまったくでてこない）で別々のSSDとHDDをひとつの論理ボリュームとして見えるようにしたものらしいけど、ハイブリッドHDDはそれをSATAより下のレベルで統合したものらしい。ようするにSSDをHDDのキャッシュにして、SATAのコマンドレベルには隠蔽したものだろう。僕は遅いiMacをマシにしたいんだけど全部をSSDにするわけにもいかず、またマシン本体を買い換えるなんてことはありえないし、かといってこのままでは使い続けるのが厳しいと思ったので、ついこないだこわれて交換したばっかりなんだけど、iMacのHDDをそのハイブリッドHDDに替えてみることにした。置き換えられるHDDは交換したばかりでまだ若々しくて達者なんだけど、実験専用のNAS用ストレージとして余生を送ってもらうことにする。
買ったのは東芝の1TBのMQ02ABD100H。Specには書いてないんだけどウワサではSSDを8GB積んでいるらしい。1TBに対して8GBというのはキャッシュとしてはちょっと小さいという感じがしないでもないけど、クリティカルなファイルがSSDに収まってしまえば改善はかなり期待できるはずである。
Fusion DriveではHDD1TBにSSD24GBらしいので、OS本体とそれ以外のよく使うアプリのイメージはほとんどSSDに乗ってしまうだろう。またFusion Driveの場合はOS（というかファイルシステム）の介在が可能なので、どのデータをSSDにキャッシュするか、という意図を反映させることもできる（たとえばOSのイメージは優先的にSSDに乗せるようになっているらしい）。ハイブリッドHDDの場合はそれが不可能なのでキャッシュアルゴリズム頼りとなる。
しかし僕はブートが速くなる必要はない。アプリケーションの起動も10分を超えたりしなければ我慢できる。問題なのはまずかな漢字変換、Illustratorの起動後に利用時点で読み込まれるプラグインのモジュールとかなので、ちゃんとキャッシュされれば8GBで十分すぎるぐらいである。
したがってハイブリッドHDDの場合、ストレージアクセスは定常化されているのが望ましい。つまりだいたい同じようなデータを読み書きしている、という状態だとSSDの読出し速度の優位性が発揮されるはずである。
まあ、それはどんなキャッシュシステムでも同じだけど、この場合はマシンをいったん立ち上げて普段使っているアプリをロードしたら、あとはなるべくそのまま使い続けるのがいいということになる。ごく普通のキャッシュアルゴリズムを使っているのであれば、おそらくOSのロードとアプリの起動でキャッシュとしてのSSDの中身は書き換えられてしまうだろうからである。
書き込みのデータをキャッシュに残すかどうか（SSDに書くかどうか）、というのも微妙な問題である。SSDとHDDとでは読出しには大きな差があるけど、書き込みでの差は縮まる。パソコンのストレージではWrite Onlyなデータも多いので、SSDには読出しデータだけを選択的に残したほうがヒット率は上がるかもしれない。
キャッシュアルゴリズムとして読み出し回数を保持して多いほどstickyにする、つまり追い出されにくくするとパソコンのストレージ用途ではヒット率が上がるということもあるかもしれない。また、そうすればフラッシュメモリ固有の問題である書き込みによる劣化を軽減できるはずである。実際にハイブリッドHDDがそうなっているかどうかは全然知らないし、確認できない。
そんなことを考えていると、それはそれで面白い問題という気もしてくるが、まあ僕のやるべきことではない。
4.1 交換作業
作業は前やったのと同じ。しかしひとつ問題が発生した。TimeMachineから復元しようとするとまずHDDをフォーマットするところから始まるんだけど、何度やってもそのフォーマットに失敗する。単独の「ディスクユーティリティ」では問題ないのに、なぜかうまくいかない。焦ってしまった。
TimeMachineを諦めてすっぴん状態に戻す、というのを試した。OS X10.8（Mountain Lion）がネットワーク経由でインストールされる。これはなぜかフォーマットもうまくいって立ち上がった。そこからTimeMachineで復元するとうまくいって元に戻すことができた。
「TimeMachineからの復元」のフォーマッタは「ディスクユーティリティ」のとは違っているようである。Appleはおかしなことをしている。
立ち上がってから「ディスクユーティリティ」で見てみるとTypeがApple_CoreStorageではなくてApple_HFSとなっていた。CoreStorageの論理ボリュームではなく古い物理ボリュームとして動いていた。なんらかの理由でハイブリッドHDDはCoreStorage用のデバイスにならなくて、「TimeMachineからの復元」のフォーマッタが対応していなかったのかもしれない。こういうのは「できませんでした」ではなくてちゃんと理由を言うべきである。
4.2 ベンチマーク
とりあえず同じベンチマークソフトで比較することにする。SSDはキャッシュとして使われているだろうから、こういうベンチマークでは本体のHDDが律速して、2回以上同じデータを読み出す以外では差が出ないはずである。まず、同じパラメータで交換前後で比較したグラフがこれ
デフォルトのパラメータでは1回しか読まないのでハイブリッドHDDに内蔵されたSSDのキャッシュの意味がない。キャッシュの効果をはかるために読み書きを5回繰り返すという設定に変更して、1回のときと比べたのがこちら
ベンチマークアプリとしては5回繰り返せばその平均を表示するだろうから、1回目に対して2回目以降はこの値よりももう少しいいはず（2割り増しぐらい）である。
最終的にMacBook Proに対して交換したことでどのくらい改善されたかを見たのがつぎ
ところで、MacBook ProのSSDも5回読めば違うかもしれないけどそれで一桁変わるということはないはずである。めんどうで時間もかかるのでそれはやめた。だから完全に同じ条件での比較ではない、ということに注意だけど、僕にとってはどうでもいい。
NCQつきのSequential読み書きの改善はHDDがNCQ対応かどうかの違いのように思えるけど、もしほんとに500MBを連続して読んでいるならNCQは関係ないだろうし、HDDのSpec上はバッファサイズが違う（8MB vs. 64MB）ぐらいで他はまったく同じなのでなぜかはよくわからない。NCQなしのRandom読み出しがMacBook Proにせまっているのは、実質的にSSDとしての比較になっているからで、この比が1にならない（対数が0にならない）のはバスが律速しているのか、と思ったけど絶対値はバススピードの一桁下なので、理由はやっぱりよくわからない。
体感的な差がでるのはNCQつき（OSのファイルシステムがNCQに対応したら、わざわざそれを使わずにおくことはないはずなので）の読み込みで、これは大幅改善がある、ということで効果が期待できる。それでもMacBook Proよりは一桁遅いということでこの差がなにによっているのかよくわからない。キャッシュとしてのSSDがヒットしないのが1割含まれていたということなのかもしれないけど、1回あたりのデータサイズが500MBなので、普通のキャッシュアルゴリズムを使っていればSSDの中身は1回目で書き換わってしまってそれ以降は100%ヒットするはずである。ベンチマークアプリのデータの読み書きの仕方にもよる。
5 交換後の印象と今回の結論
HDDからハイブリッドHDDに交換して、ベンチマーク上はSSDのキャッシュ効果はあきらかだということである。もっとも体感に影響のあるRandom ReadでSSDに対して千倍遅かったのが十倍以下にまで差が縮まった、というのは数字の上ではすごいことである。これが実際に体感に反映されるか、は使っていきながら確認することになる。とりあえず二日ほど使った感じ（その間リブートしていない）では一番煩わしかったかな漢字変換中のビーチボールはほとんど現れなくなった。ほとんど使い物にならなかったライブ変換もほとんどMacBook Proと感触的には変わらなくなった。これはなかなか素晴らしい。ライブ変換をオンにして使い続けるか、というと微妙なところではあるけど。
IllustratorやPhotoshopの「新規ウィンドウ」が現れるまでの時間もかなり改善された。でもフォントパネルはなぜか開き直してもそれほど差がない。これはなんでだろう。また、Launchpadはやっぱり1分近くまたされることがある。キャッシュのされ方になんで違いが出るのかわからない。他にもブートが速くなるとかアプリの立ち上がりが速くなるとかはよくわからないが、僕としてはそれはどうでもいい。
一点、ハイブリッドHHDをCoreStorageデバイスとしては使えないようなので、ひょっとするとあとあとのmacOSでは「物理ボリュームはレガシーだ」とか言って、ブートデバイスとして使えなくなるかもしれない（Appleはすぐそういうことをするので）。まあ、でもそのときはそのときである。ひょっとするとベータのままの新しいファイルシステムではまた違うことを言い出すかもしれないし（Objective-Cのガベージコレクションがトラウマになってる）。
しかしよくよく考えるとそれなりの出費をして、それなりの時間を割いてなんとかなるとことまで来たんだけど、たかだか3年弱前に仙台でプライベートに使っていたころは、このハードウェアパフォーマンスでなんの問題もなかった。何が悪いと言ってIllustrator、Xcode、Mathematicaと言った僕がふだん使いたいソフトが肥大化していること、そして何よりOSが肥大化してるということである。
企業戦略上しょうがないということは僕もサラリーマンなのであるレベルまでは理解しているつもりだけど、やっぱりどこかおかしいんではないか、と思ってしまう。こんなイタチごっこをしてまでやるしかないのか、と僕自身も悩むところがある。でもそんなことを言ったら僕が仕事でやってることの全否定になりかねない。
まあ、他人から見たら全否定だよそんなもん、で終わりだよな。ああ。
2017-02-02 21:43
nice!(0)
コメント(11)
トラックバック(0)
ハイブリッドHHDは、アプリケーションによっては相性が悪いみたいです
Adobe系のアプリで、時々わけの分からないエラーが出るようになりました。
特に、書類の保存時に出ることが多いです。
by お名前（必須） (2017-02-02 22:35)
コメントありがとうございます。
ハイブリッドHDDは単にキャッシュを積んでいるだけなのでアプリケーションを区別できる能力はないと思います。
可能性としてはアプリケーション側がタイミングに依存する実装をしているということが考えられますが、それはアプリのコードがヘボい、ということであって、ハイブリッドHDDにとっては濡れ衣だと思います。
僕としては「相性」ではなくて、技術的な原因があると考えたいのですが、どうでしょうか？
by decafish (2017-02-03 08:44)
AmorphousDiskMark の作者です。
参考までに、"4K Random QD=1" と "4K Random" は同等のテストですが、"Seq QD=1" と "Seq" は異なるテストになります。"Seq QD=n" はブロックサイズ 128KiB、"Seq" は 1MiB。
通常 HDD の Queue Depth は 32 です。
https://www.hgst.com/sites/default/files/resources/Ultrastar_7K6000_SATA_OEM_Specification_Rev1.3.pdf
75: Queue depth: 0x1F (31): Maximum queued depth – 1
https://en.wikipedia.org/wiki/Native_Command_Queuing
Samsung 950 PRO NVMe SSD の Queue Depth は 64K x 8 (512K) です。
• Support for 8 queues with 64K command queue depths in each queue
http://www.samsung.com/semiconductor/minisite/ssd/downloads/document/Samsung_SSD_950_PRO_White_paper.pdf
by katsura (2017-02-03 12:07)
コメントありがとうございます。
作者の方からコメント頂けるとは光栄です。
ブロックサイズが違うというのは理解しました。
それと大変面白い資料をありがとうございます。こんなのがすぐ見られるとは思っていませんでした。
HGSTのHHDだとコマンドレベルでキャッシュのフラッシュと同じようにNCQのアボートができるんですね。TTAGで特定のエントリを消すというのもできるのでしょうか。面白いです。
Samsungの資料ではNVMe接続のSSDだとSubsystemごとにキューを持っているということですか。それぞれのSubsystemが並列化できるならインターフェイスのバンド幅がいっぱいになるように並列化すればいいということですか。そうなるとHDDはSSDには絶対かないませんね。データが特定のSubsystemに偏らないようにするのはファイルシステムの仕事なんでしょうか。それとももっと低いレベルで制御するんでしょうか。
非常に面白いです。
by decafish (2017-02-03 13:05)
Samsung 950 PRO NVMe SSD は 2,500MB/s read、1,500MB/s write と、とんでもなく速いので、Sequential の読み書きでもどこのデータを読み書きしたいのかを前もって queue に入れておかないと、NVMe SSD の性能を最大に活かせないんです。
http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/950pro.html
Samsung 960 PRO NVMe SSD は 3,500MB/s read、2,100MB/s write。
http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/960pro.html
by katsura (2017-02-05 06:45)
ちなみに“レスポンス低下”の対策としては、ストーレッジ（HD や SSD）を性能が高い新しいものに取り替える他、メモリのアップグレードが必要かもチェックすることをお勧めします。
Mac をしばらく（数日とか１週間とか）使ったあと（レスポンス低下が続いてる状態で）、以下のコマンドを Terminal で実行してすると（macOS 10.9 以降）、メモリが足りなくなっている状態がどのくらい頻繁に起こっているかがわかります。swapouts の数値がゼロまたは少ない（数千とか）なら、メモリが十分にあるということ。レスポンス低下はメモリの容量が少ないのが原因ではないということになります。
uptime ; top -l1 | grep outs
わたしの“反応が遅くなってしまった”（虹色のカーソルが頻繁に出る）iMac (Late 2012）での実例（メモリ増設が必要）：
13:59 up 13 days, 15:06, 12 users, load averages: 1.71 1.65 1.83
VM: 898G vsize, 623M framework vsize, 11881982(0) swapins, 12532027(0) swapouts.
Activity Monitor アプリの Memory タブで Compressed 数値が大きいかどうか見るだけでもいいかな。メモリが十分にあるならこの数値はゼロ（または非常に小さい）。GB（ギガバイト）単位になってたら、メモリ増設がお勧めです。
by katsura (2017-02-05 07:09)
なんだかSSDはすごいことになっているのですね。ビット単価が逆転するよりずっと前にHDDの歴史は終わるのでしょうか。Fusion DriveのようにSSDをHDDのキャッシュにするような汎用のシステムがあれば少しは生きながらえるかもしれません。僕のメシの種だった光ディスクは30年ほどだったのでさらに短命でしたが．．．．
メモリに関してのご提案ありがごうございます。ただ、僕は根っからの貧乏性なもので、適度にページアウトされている状態が正常だと思っています。追い出されたページがストレージを圧迫するのは辛いところではありますが。
よそ様でユーザインターフェイスのレスポンスだけを追求して巨大なメモリを積んでいるのをみかけることがありますが、動作中CPUもバスも9割以上NOPというのは、便座を温めるヒータと同じで電気代の無駄に思えて僕には苦痛です。
もちろん、ロシアみたいにうっかり座って尻の皮が剥けるようなシチュエーションで使っている人には何をけち臭いことを言うとるんじゃ、でしょうけど。
by decafish (2017-02-05 18:20)
decafish さんの“レスポンス低下”の原因追求と対策に関心しました、と初めに書いておくべきでしたね。
必要以上にメモリを増設したり大容量の SSD に入れ替えるようなことは、わたしもお勧めしません（資源や電気やお金の無駄）。
スワップアウト（または Compressed）の数値はメモリ増設が必要かどうかの参考になりますよとと言いたかったんです。スワップアウトがゼロならすでに十分なメモリがあるということだから、メモリ増設の必要はないですよね。
スワップアウトはもちろん OS の正常な機能なんですが、複数のアプリを頻繁に切り替えて使うときに、切り替えるたびに数十秒待たされるようだと仕事の効率に直接影響するので、時間と予算と電気代のトレードオフですね。
by katsura (2017-02-06 06:07)
僕も偉そうなことを言って失礼しました。
おっしゃること理解しました。
僕もさすがにアプリの切り替えで数十秒待てるほど気は長くはありません。今使っているiMacでは普通に使っている状態でスワップは1〜2GB前後確保されていますが、そこまでのレスポンスの低下はありません。MBPではスワップはさらに大きくて（なんでiMacと違うのかよくわからないのですが）平均的に3GB近く食っていますが、使い勝手で不便を感じたことはあまりありません。
もちろん何がスワップに追い出されているかにもよるとは思いますが、このくらいなら僕にとっては許容範囲かな、と考えています。少なくともよそ様で時々みかける「スワップは悪」という主張は僕には間違っているように思えます。
それよりも僕としては「肥大化は悪」を主張したいのですが．．．．特にAdobeに対して．．．．
by decafish (2017-02-06 09:07)
わたしの方が明白に意図を伝えることが出来てないみたいですね。申し訳ない。
短絡的に（一概に）「スワップは悪」と言っているのではなくて、「レスポンスの低下」になっている原因が悪（原因がなんであろうと）と言いたいんです（当たり前ですよね）。
「肥大化は悪」にも同感です。アプリ自体の肥大化は十分なメモリがない場合にアプリを切り替えた時にレスポンス低下の原因になるスワップを起こすことにつながります。さらにスワップが起きたときにストーレッジの性能が悪いと「レスポンスの低下」につながります。
OS やアプリのバグ（メモリ leak やメモリ hog）が原因で必要以上にスワップが起きて「レスポンスの低下」につながることもあります。メモリ leak や hog のバグがあると /var/vm に複数のスワップファイルが作られるので目安になります。
ls -l /var/vm
by katsura (2017-02-06 15:34)
すみません、僕もよけいなことを書きました。
「スワップは悪」云々は時々見かける極論をとりあげただけで、今回のお話とは無関係でした。
おっしゃっている意味は理解しているつもりです。
すみませんでした。
ご容赦ください。
by decafish (2017-02-07 09:01)