最強.NET開発PCを作るよ OSチューニング

目次はこちら 最強.NET開発PC

最強.NET開発PCが完成しました…と、その前に「.NET開発PC」なので、.NET の開発環境を入れないといけません。というか、更にその前に OS を入れないとダメですね。今回 .NET の開発環境といして準備するのが、以下の環境です。

• Windows 8 Pro
• Visual Studio 2012 Pro
• SQL Server Standard
• IIS + ASP.NET 4.5
• Office 2013
• VMWare 8

といったところです。他にも、xamp、Perl、OpenCV などを入れていますが、ひとまず、.NET アプリの開発をするときは、上記の環境で ok です。あと、ソース管理用に Team Foundation Server Express 2012 を入れていきます。

数々の開発環境を何処にいれるのか？という問題があります。今回の PC は 512 GB の SSD を積んでいるので、あらゆる環境を C ドライブに入れています。かなり突っ込んだ状態で、150GB 程度使っている状態ですね。このうち 50GB ぐらいは試験的に VM に割り当てているので、開発環境としては 100 GB ぐらいで収まっているはずです。

なので、C ドライブの SSD の容量としては、256 GB 程度あればあまり容量を気にせずに使えると思います。それ以下となると残り容量が気になったりするので、精神的によくありません。そういう場合は、アプリケーションの多くを D ドライブなどの別に領域に移すとよいでしょう。ただし、ツールによっては C ドライブに固定されているものもあるので（テスト的に作ったものとか）、それに対する先行きのトラブルの対処時間を考えると C ドライブにまとめておけるような容量を使ったほうが「作業コスト」が安くなります。

■仮想メモリを調節する

この開発 PC には、64 GB のメモリを積んでいます。なので、仮想メモリは自動で 128 GB 取ることになります…といいますか、貴重な SSD の容量をたかだか仮想メモリ（ページング）のために 100 GB 以上の消費するのはばかばかしいです。64 GB あると普通の作業をしている間はキャッシュアウトはしません。なので、仮想メモリの容量を「0」にしてしまいます。

多分、32 GB の場合も 0 にしてしまって ok です。16 GB の場合は微妙な時がありますが、VMWare などの仮想環境を使わないのであれば、 0 にしてもよいかもしれません。そのあたりは実際に運用して調節していきます。

■ディスク構成を考える

最初に構成を考えていたので、最強.NET開発PCを作るよ（その１） この構想の通りにインストールをしています。

※ F ドライブは DVD です。

C ドライブは、OS と 開発系のアプリを入れます。SSD で高速に動作するのと、一度突っ込んでしまえば、あとは Read だけで済むようなアプリの実行ファイルを入れます。仮想メモリを使っている場合だと、HDD はそれ専用のほうが高速に動作します。今回は、仮想メモリが 0 なので関係はありませんが。あと、デフラグや OS 領域のクラッシュの関係から、作業領域とは別のドライブにしています。

D ドライブは、数々のツールの類（テスト的に作ったものや、他のツール）、プログラムのソースコードなどを置きます。ソースコードをコンパイルすると、一時ファイルがたくさんできるので、実はこの領域は Read/Write が高速なほうが良いのです。が、今回はコスト上の関係から HDD にしています。それでも、OS 領域と別にとることでビルドが高速になるのと、OS 領域のクラッシュに無関係なように別のドライブに配置させます。

E ドライブと G ドライブは、それぞれ SQL Server 専用、VMWare 専用領域にしています。データベースも仮想領域も、それぞれ頻繁に HDD にアクセスするものなので、シーク時間を短縮させるために別のドライブにします。ここも SSD にすると高速化するだろうなと思われます。HDDのアクセススピードは VMWare に影響するのか？ で実験したように、同じドライブに複数の VMWare を置いてしまうと仮想されている OS が遅くなる可能性があります。この実験では、ドライブに対する書き込みしか調べていないので、コンパイルや実行時間、仮想メモリを頻繁にアクセスさせるなど、いくつかの実験ツールを作って試してみたいところです。

■故障と復旧時間を考える

私が非常にノーマルな状態でアプリや PC を組むのは、

• トラブルに巻き込まれる頻度を少なくする。
• トラブルから復旧する時間を短くする。

という、MTBF（平均故障間隔）, MTTF（平均復旧時間） というのを考慮するためです。サーバー系の場合には当然の考え方なのですが、プログラミング環境やアプリケーションを使う場合も同じで、トラブルにあたる頻度は少ないに越したことhあありません。ですが、サーバーの場合とは違い、開発 PC には、最新の危うい技術/アプリを入れ込む必要が多々あります。これは、別に危険なツールを入れるという意味ではなくて、Visual Studio 2012 のアップデートを頻繁に入れるとか、なんらかのパッチを入れるとかという作業が頻発するのです。そのたびに、開発環境自体が壊れる（動かなくなる）というリスクが少なからず発生します。この頻度は、普通にゲームをしたり、普通に業務アプリを動かしている場合とは比率が異なります。逆に業務アプリを動かしている PC は、OS もアプリも最初のままというパターンになります。

かつ、仕事柄、最新の OS に付き合うパターンも含まれるので、OS がバージョンアップするタイミングで、OS の入れ替えと、しばらくしてから PC 自体の入れ替えが交互に発生します。このパターンで考えると、減価償却的な意味合いの消耗品としての PC と、開発効率を優先させるための投資先としての PC が混在しているのです。そんなこともあって、結構ノーマルな形で開発 PC を使っています。