コンピュータの最近のブログ記事
Windows 2008 R2の上でWindows 7をゲストOSとして利用していますが、高速化のためにはいくつもの注意点があるようなのでまとめておきます。
ちなみに環境としては、Intel Corei7 930, Crucial SSD 128GB (OS, VHD設置ドライブ)、メモリ12Gです。
自分の期待値としては、ホストOSの50～70％の性能がでればよい(参考資料)・・・というところなのですが、現状では10％以下です。ホストOSのCPU利用率は1～3％程度・・・。
ホストOS側のタスクマネージャーでは表示されているCPU利用率は、ゲストOSのCPU利用を含まないので、実際には、パフォーマンスモニターでHyper-V Hypervisor Logical Processorで見ないとわかりません。これでみると、かなりいい値がでてきます。CPUはほぼ100％利用できる感じですね。
それでも、遅いので色々調べたら、細かいTipsがありました。
高速化Tips:
ホストOSでVHDファイルをセキュリティ検査の対象外にする。
VHDは容量固定のほうがパフォーマンスがよい。(データ)
統合コンポーネントをインストールする。(リンク)
Hyper-V Managerを閉じる
IPv6をホスト・ゲスト双方で切る
ホストOSの仮想ネットワークカードのLarge Send OffloadをDisableにする。
ゲスト用とホスト用のネットワークカードを分ける。可能ならホスト毎に物理NICを増設し、仮想ネットワークアダプタをつくる。
手動でパッチをあてる。(パッチ一覧)
ゲストOSにWindows 2008 Serverを使う。
その他 Tips
仮想ネットワークアダプタ周りはチューニングしないと、IEなんかがもっさりして使い物にならないですね・・・
結論からいうと、Google Appsは使い物にならない！
以前より現場から、「メールがエラーになる場合がある」というクレームがあがっていたのですが、借りていたValue-DomainのDNSの不調もあり、「原因不明」のままにしていたGoogle Appsでのメール不調ですが、原因がGoogle側にあることが確定しました。
Google Appsで、登録ユーザには普通にメールが届くのですが、グループメールアカウントにメールを送ると、下記のような「Bulk Emailガイドラインに抵触したからチェックしろよ！」というエラーメールが返って来ます。昨日までは普通にメールが出せていたのに急にです。
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
Technical details of permanent failure:
Message rejected. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines.
違うSMTPサーバからメールを出すと届くので、どうやら自分の使っているSMTPサーバが「大量メール発信サーバ」とGoogle側で判断されてしまっているようです。
件のSMTPサーバは、いくつかのWebアプリケーションでメール送信サーバとして利用はしていますが、SPAMと呼ばれるほどMailを送信しているわけではありません。せいぜい1日100通程度、Gmail向けメールは10通に満たない程度です。
Google Apps Known Issues こちらに(日本語には記載がないので英語を選択する)書かれているように、既知の課題のようで、「SPFレコードをしっかり設定しても、ダメだったら、個別に連絡ください」 (もちろん返事など来ない)、という有様。「返信はスプレッドシートで集計されます」がよけいに腹立たしい。
Googl Apps ディスカッショングループでも、Google Apps Helpでも困っている人がいるようですが、2月頃から問題がわかっていて、未だに解決していません。誰からも反応がもらえない人もいます。怒り狂っている人も。
10万円払ってでもすぐに解決してほしい問題なのに、対応の進捗すらわからない・・・・、半年近くたってもIssueのまま。これはGoogle Appsのビジネス利用はできないということです。
他のメールサーバに乗り換えます。
最近管理しているシステムで、DBのストレージがシステムボトルネックになっています。
大体、一日1～5億トランザクション、インサートが5000万行くらい発生するので、主にストレージのランダム書込がボトルネックになっている様子です。
現在はRAIDも使わず単純にHDDを単体でぶら下げているだけなので、200IOPS(IO per Second)程度しかありません。DBのInsertやUpdateはランダム書込なので、IOPSが低いと使い物になりません。
IOPSをあげるための選択肢は3つあります。
- より高速なHDD使い、かつ多重化(RAID)を組む
- 半導体ディスク(DRAM)を利用する
- 半導体ディスク(FLASH)を利用する
それぞれ、メリットデメリットがあります。
| メディア | IOPS | G当たり価格 | 信頼性 |
| HDD RAID | 1,000 IOPS | 1000円 | 高い |
| DRAM SSD | 2~400,000 IOPS | 10万円 | 高い |
| Flash SSD RAID | Read 100,000 Write 10,000 | 3~5000円 | 低い |
選択肢1ですが、SATA HDD 1500回転の製品を使って、5~8台程度のRAIDを組んでもさほどIOPSは向上しません。(RAIDコントローラがバッテリー持っていて、Writeもキャッシュするようなストレージシステムは対象外です)
DRAM SSDは、高性能なんですが、さすがに高すぎます。いくら、1000倍の性能でても、お値段も1000倍です。また、上限サイズも限られ上位製品でも64~128GByteです。テラ単位のストレージを調達するのは現状ではかなり難しくなります。
そこで、Flash SSDでRAIDを組むという選択肢なのですが、昨年くらいまではランダム書込の性能がSATAと比べて優位性があまりなく、選択外だったのですが、ここにきて一気に性能があがってきました。
インテルの新製品X-25EですとRandom 4KB Writesで最大3,300 IOPSというスペックになっています。既存のHDDの15倍です。
これをみるとランダム書込で38MByteでています。9,500IOPSです。HDDのRAIDと比べて一桁良いパフォーマンスをだしています。(まあ、実際にはRAID1+0でくむ必要があるので、もう少し性能おちるでしょうが・・・) 価格性能比でみると前者2つの選択肢を圧倒します。
Flash SSDが書き込み回数寿命が短いだけでなく、過渡期の技術なので実績がほとんどありません。また、SSDを12~16台くらいつんだeSATAのエンクロージャーなど製品としてでてないので、自分で組まないといけません。となると、信頼性にどうしても疑問が残ります。
あと1年くらいすれば、環境もこなれてきてサーバストレージにFlash SSDを導入する選択も自然になると予測しますが、今年度はFlash SSDのサーバへの導入は控えるべきです。
システムの本格的なリプレイスが計画にあり、それまでのつなぎにどうしてもストレージ性能を2～5倍にする必要がある場合に限り、延命のためのシステム投資としてFlash SSD RAIDを1年だけ使うというのはありかとおもいます。
仕事で検索をしようとしたらGoogleが開かない！
ルータが落ちたのかとおもって調べてみると、他のサイトは普通に接続できるのに、Googleだけがまったくなしのつぶてです。検索だけでなく、Gmailも、Google Analysisも、AdSenseもすべて動作していない・・・。
世界中にサーバを分散させているGoogleのシステムがいっせいにおちるわけはないので、DNSをnslookupで問い合わせてみると、案の定返答がない。
GoogleのDNSが落とされたようです・・・。
しかし、Google使えなくなると一気に不便になります。他の人のHP開いても、Google AnalysisやAdSenseが入っていると例外なくデータ取得のリクエストがまわりっぱまなし。
過去にもGoogleのDNSサーバが障害でおちたこともあるようですが、今日のはどうもGoogleのせいではないっぽい。
DNS関係をつかったDDos攻撃がおこっているようです。
しかし、ここまでGoogleにドップリなのも困ったもんだな。
デフラグ楽しいです。
[ﾟдﾟ]
/[＿]ヽ
| |
■■□■■□◇＿◇□□□
Gigazineさんの記事でUltraDefragの紹介がありました。
Windows９5の頃はボーっとデフラグの様子をみたものです。当時はHDDが500メガ程度でしたらので、しばらく待っていると完了していたのですが、昨今では500ギガが当たり前の時代です(僕のパソコンも1テラつんでいます)。とてもデフラグをまっているわけにはいきません。
そもそもデフラグって必要なんでしょうか？
初心者向けの解説本には、「デフラグさんが、分割したファイルを連結してくれます」なんて書いてあります。HDDは普通4kbyteのセクタと呼ばれる小さな箱が並べられていて、そこにデータをいれておくわけです。データファイルは4kbyte以上あるものがほとんどなので、複数の箱に入れられるのですが、これが連続した箱に入るのと飛び飛びの箱に入る場合では、データを取り出したり、書き込んだりするときの速度が違う・・・というお話です。
OSのファイルシステムドライバからみると、上記の理屈で良いのですが、物理的なHDDの挙動を考えると、多くのパソコンでデフラグなんて気休めです。
連続してないセクタの読み込みのためにはHDDのヘッド(読み取り用の針)を移動させる必要があり、パフォーマンスペナルティ(針の移動時間、針の定位固定までのディスクの回転時間)が発生します。しかし、この針移動のペナルティは、データファイルが一定以上のサイズであればトラックの移動を行うので連続したファイルでも発生しています。HDDメーカの制御技術者は、このヘッドの定位の速度を上げるために血のにじむ様な努力をしています。
たとえば手元にあるHDDではシリンダ数が16383、トラックあたりのセクタ数が63なんて表示されていますが、これは論理ジオメトリで、本当のシリンダ数やセクタ数ではありません。
HGST(旧IBM)のHDDのデータシート(PDF)をみてみましょう。
そりゃ、ディスクの内側と外側で、円周違うんだから、セクタ数かわりますよね。
この資料をみると、最低の1シリンダあたりのセクタ数でも250ギガモデルでは2520個、つまり約12MByte程度です。ディスクヘッドは複数あっても、並列にデータの読み出しはできないので、ヘッドの移動無く読み込めるデータファイルは現状では十数MByteくらいです。
用途にもよりますが、メガ単位のファイルは2、3個に分割されていたところで、読み込みパフォーマンスのペナルティは気にするところではないと思います。むしろ、パフォーマンスに影響があるのは数キロ程度の小さいファイルがプログラムの読み出し実行順序に並んでいるほうがパフォーマンスに効いてきます。
下手なデフラグソフトを使うと、せっかくWindowsが最適配置してあるDLL群のアロケーションを壊します。結果としてデフラグをしたほうが遅くなるということもありえます。
それでも、こんな風に赤い線が混じっていると、全部青くしたくなるのが人情です。
そんな人たち(含む私)はデフラグ潔癖症候群に陥っているのだとおもいます。
そんな方はWikipediaでも読んで、HDDへの愛を深めてください。
【Let'snote R3ベンチマークテスト】
Let'snote R3 dynabook SS SX/210LNLW LaVie J LJ700/7E
CPU 超低電圧版Pentium M 1.10GHz 超低電圧版Pentium M 1GHz 超低電圧版Pentium M 1GHz
ビデオチップ Intel 855GME内蔵コア Intel 855GM内蔵コア MOBILITY RADEON 7500
MobileMark2002
Performance rating 134 130 132
Battery life rating 425 218 178
SYSmark 2002
Internet Content Creation 138 127 127
Office Productivity 121 108 110
3DMark2001 SE
1,024×768ドット32bitカラー(3Dmarks) 1,850 1,724 4,095
Quake III Arena
640×480ドット32bitカラー 93.8 90.3 154.8
800×600ドット32bitカラー 70.1 55 117.6
1,024×768ドット32bitカラー 44.6 44.4 78.3
Let'snote R3におけるMoblieMark2002のPerfomance ratingは134で、このクラスのモバイルノートPCとしては標準的なスコアだが、バッテリ駆動時間を表すBattery life ratingは425と、dynabook SSやLaVie Jの2～3倍ものスコアを記録している。425ということは実に7時間5分であり、これまでの常識を破る長時間駆動を実現している。
もはや、バッテリーと重量以外のパフォーマンスはあまり重要ではないことがはっきりわかる。
ではなぜ他社はPanasonicと同じ商品戦略をとらないのでしょうか？
戦略要因、技術要因、企画要因の3つの理由が考えられます。
1、コンシューマ向けの主力はTVのリプレイス。もしくはコンシューマPCは利益率が悪いので、注力しない。
2、部品の組み立てだけで商品をつくっているので、Panasonicのように自社で部品開発できない。もしくはOEMに頼りすぎてOEMの技術力不足で実現できない。
3、技術職の発言力が大きく、企画部門の統率力が低い。
原因が1であれば問題ないのですが、原因が2や3にあるならばPCベンダーは反省が必要ですね。特に消費電力を抑えるためには、モジュールごとにキメの細かい調整が必要です。このあたりは家電メーカならではの強みがでています。コンデンサ一個、DCDC一個とっても、どの製品が効率がいいか熟知しているエンジニアがいるんでしょうね。
