Dock.app 10.7で暴走

MacOSX 10.7で時折CPUが長時間100%を記録するようになりました。
同時にメモリの消費量もうなぎ昇りに。
アクティビティモニタによると何故かDock.appが原因のようです。

よく見るとDockに書類フォルダなどを登録していてもCPU使用率が上がるようです。
そのことからDockの役割が増えているのではないかと推測しました。

LaunchPad??

調べてみるとDockがDBを持つようになったとのこと。主にLaunchPad用に
indexを作り、そのために定期的にDock.appがフォルダを探索する模様です。

Macの手書き説明書/Launchpadに登録されたアイコンをリセットしたり全消去したりする方法
http://veadardiary.blog29.fc2.com/blog-entry-3429.html

Macfan.jp
Launchpadに表示されるソフトを自分で登録したい
http://macfan.jp/guide/2011/11/30/launchpad_1.html

10.6までアプリケーションフォルダをDockに登録して使っていたのですが、これを辞めてLaunchpadを使えということなのかも知れません。

VM用共有フォルダが怪しい

これらによりだいぶCPU使用率が下がったのですが、それでもDock.appが暴走することがありました。更に調べていくと
vmwareやFusionでの共有フォルダが原因の模様です。

Lion update 10.7.2 - Dock eating memory and CPU
http://communities.vmware.com/thread/333119

vmwareを起動し、共有フォルダが有効になることでDock.appの
アイコン探しdaemonが無限ループに陥り、暴走すると推測中です。

その後、PRAMのリセットで治るとAppleから言われた人がいるようですね。
こちらは当人も様子見中。私も未検証です。

Lion update 10.7.2 - Re: Lion update 10.7.2 - Dock eating memory and CPU
http://communities.vmware.com/thread/333119?start=105&tstart=0

共有フォルダ無しにどう過ごすか

共有フォルダが使えなくなるとあまりにも不便なので、代替案としてMacOSX上で
ネットワーク共有(SMB)をさせるようにしました。
使っている感じでは(当然と言えば当然ですが)動画再生で様子を見る限りは
VMWareのネットワーク設定をブリッジではなくNATにし、クライアントから見たゲートウェイのアドレスで
SMBアクセスする方がホストOSのローカルで完結するようで早い印象です。
しかし一部のソフトウェアではそうしたネットワーク共有時のPATHが気に食わないようで
開けなかったり保存時にうまく行かなかったりするので面倒です…
いっそNASを導入してそこにホストOSもクライアントOSもアクセスするのが良いのかも…

2012年1月25日追記

その後,代替案二つを試しています.一つはベタですがDropboxによるファイル共有.
アクセスに関しては一番ストレスがない方法と思われますが,
一台のMacの上にも関わらずクラウドを経由するのはあまり美しくありませんね.
もう一つはゲストOSであるWindowsでファイル共有を行い,ホストOSのMacOSXからSMBマウントする方法です.
そもそもゲストOSの使い方はゲストOSにあるアプリを頼ってのことなので,
ホストOSから激しく読み書きしない限りは良さそうな雰囲気です.ひとまず日本語ファイル名のファイルをコピーしてテスト中です.