つぶねこ

　processor数を1か2で選択できるわけだが、これ2にしても大して速くにゃらにゃいんだよにゃぁ。
　むしろホストがbusy気味の時に極端に遅くにゃる。
　ので、よほどホストが絶対的に2コア以上空いてる保証がにゃい限り、1CPU設定にしとかにゃいと滅ぶ感じ。
　このあたりはもちっと新しいvmware使った方がいいんだろうにゃぁ。MSのにも手を出してみる時期だろうか

　.vmxのパラメーターとしていろいろ隠し物があるらしいのだが、よくクラスタ用の設定で出てくるやつのデフォルト値をvmware-cmd getconfigで調べてみた。win 2003用だと、

diskLib.bufferedMigrate = 1
diskLib.createSpaceSafetyMargin = 8192
diskLib.dataCacheMaxRABusyCnt = 4
diskLib.dataCacheMaxReadAheadSize = 512
diskLib.dataCacheMaxSeqRA = 0
diskLib.dataCacheMaxSize = 2048
diskLib.dataCacheMinReadAheadSize = 0
diskLib.dataCachePageSize = 8
diskLib.dataCacheSeqThreshold = 8
diskLib.dataCacheUpdateFrequency = 10000
diskLib.dataCacheUseExtraRA = 1
diskLib.defaultEmbeddedDescSize = 20
diskLib.defaultGTEsPerGT = 512
diskLib.disableSparseChecker = false
diskLib.flatAllocWriteSize = 128
diskLib.grainCoalescing = true
diskLib.gtCacheMode = 0
diskLib.gtCacheSize = 0
diskLib.ignorePermissions = false
diskLib.legacyCheckerTolerateHoles = true
diskLib.maxNumGrainsCoalesced = 10
diskLib.maxUnsyncedWrites = 64
diskLib.redoGrainSize = 128
diskLib.redundantGrainMetadata = true

　で、
　それぞれ正確にゃ解説が見つからにゃいのだが何とにゃく分かる系で嫌にゃ感じ(笑)
　ReadAheadはそのままだし、maxUnsyncedWritesにゃんかはWriteBackCache量相当じゃにゃいかと思うんだが、このあたりはベンチしにゃいと判明しにゃいだろうにゃぁ。で、ベンチ結果がネット上に皆無にゃのは何でにゃんだろうにゃ。
　ただ、どうせホストが落ちるとvmdkのキャッシュが0であったとしてもどんにゃ破損するか分かったものではにゃいわけで、いっそ徹底的にwritebackにゃ動作させた方がいいんじゃにゃいかとは思うね。

　2003鯖のDFSレプリケーションで負荷かけるとさくさくDBエラーが出て死ぬんだが、徹底的に分離すると比較的安定してる模様にゃのでメモ。
　
　レプリケーショングループどころかレプリケーションフォルダ単位でドライブを分離する。つまり、RG:A(RF:abc), RG:B(RF:abc)が有ったとすると、ドライブを6つ作って分散配置する。RF数だけドライブを作ることににゃるのでマウントポイントを使用した方が良い。これでとりあえずマシに動いてる。より負荷を高めればやはりこけるが。
　
　stagingフォルダのドライブにはデータベースは作られにゃいので、これは1ドライブにまとめてしまって良い。よって実データはパーテーション細分化して独立ドライブ、ステージングフォルダは別のディスクに変更して負荷軽減がよさそう。
　にゃおドライブを細分化するとディスク容量が無駄ににゃるのだが、vmゲストにゃのでそのあたりは全く問題にゃい。効率的である。

　共有フォルダのシャドウコピーは正常に動いていればある程度便利にゃのだが、致命的欠陥がいくつか(笑)
　RAIDの1発が落ちて、多分ディスクがしばらくbusyのまま帰ってこにゃかったらしい。するとVSSがタイムアウトして全シャドウコピーデータが消滅・・・
　いやー潔い消え方で。
　さてどうしようかこれ