目次はこちら 最強.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を作るよ(その1) この構想の通りにインストールをしています。
ハード | 容量 | 用途 | |
C | SSD | 512 GB | システム、開発系アプリ |
D | HDD | 2 TB | ツール系、作業エリア |
E | HDD | 2 TB | データベース |
G | HDD | 1 TB | VMWare |
※ 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 を使っています。
確かに開発用でも、現場環境考えてVMで動かすのは必須ですし、
そこはノーマルじゃないと後で怖い事発生しそうですものね。
特に古いOSをVMで動かして、時計とか時計とか・・・
VM 動かすときは、ホストはノーマルでなくてもいいんですけどね。ただ、OS がクラッシュしたときの復旧が面倒なことが多いので、基本は C ドライブに突っ込んでいます。ツールの類は、HDD ごと移行したいから D ドライブにという方式。
時計は、もっぱら VMware tools 頼りで BIOS 設定。たまに日付を戻してテストをするので、その時は立ち上げてちまちま直す感じ。