vmware playerが遅い、重いなどの不具合の解消 [修理]
VMwareを使っても あまりに重すぎ、固まってばかりで使うのを断念する人もいると思います。
(私もそのひとりでした。)
しかし、XPの時代に挫折したものの、W7の時代では CPUも早くなり メモリも大容量。
今なら使えるかも!と 再インストールしたものの・・・・・・・・・・・ やっぱり 使えない・・・・・・・・
しかし ためしにぐぐってみると対処方法が結構UPされてたので メモします。 以下 メモ。
=====================================
VMware が頻繁にディスクアクセスして OS 全体が固まる件
http://www.drk7.jp/MT/archives/001215.html
VMware で仮想メモリを使わず実メモリを使う方法
1. 仮想マシンの Advanced オプションで disable memory page timing にチェックをいれる。
2. 仮想マシンの環境設定ファイル .vmx に mainMem.useNamedFile = "FALSE" の1行を加える。
これだけです。設定変更前と後で .vmem が消えているかどう違うか確認しました。まずはこれが変更前。
設定変更後はちゃんと .vmem が生成されないくなっています。
リソースモニタでメモリの使用状況をみるとちゃんと vmware がワーキングセットとしてメモリを確保してるのがわかります。
================================================
1・プチフリーズ
ゲストOSのディスクアクセスが頻繁過ぎて、ホストOS巻き込んでプチフリーズする、って話で、
対策として、.vmxに以下を追記しました。
mainMem.useNamedFile = "FALSE"MemTrimRate = "0"
2.ゲストOSを物理的に配置するHDD自体を、別のディスクに変更したら、解消しました。
3.ゲストOSに割り当てるメモリ量が多過ぎたようで、1024MB⇒512MBに減らしたら解消しました。
参考URL→vmware playerが遅い時の対処法(まとめ)
http://blogs.yahoo.co.jp/beweiskoiken/35625425.html
======================================
VMWare Playerの起動が遅い問題
http://d.hatena.ne.jp/taepodong-user/20091208/1260277324
バージョン情報でログファイルの存在を知ったので確認して見た。
どうやらプロクシの自動検出に時間が掛かり、そのためVMWare Playerの起動が遅くなっていたようだ。
インターネットオプションにあるプロクシ設定のLANの設定を変えたところ
起動が速くなった。
Wordより遅かったのが、Wordより速くなった。
===========================
もう憂鬱じゃないVMware Server管理者
http://wizardbible.org/49/49.txt
0x01.) 前回の結論と残った課題 WB43での筆者の結論は以下のようになっていた。 ・すべてのゲストOSがフルにメモリを消費しても大丈夫な量のメモリをホストOSに載せておく ・ホストのメモリが実際にいくつ消費されているのかはぶっちゃけわからないので、 気にしないwww ・どうしても気になる場合は/proc/meminfoを見る ・mainMem.useNamedFile = "FALSE"は使わない ・そのほかは普通にやる(Fit all virtual…やDisable memory page trimming など) これらの方針通りにしばらくサーバー運用を続けたのだが、どうにも状態がよ ろしくない。数週間から1ヶ月以上立ち上げっぱなしにしているゲストOSのパフォ ーマンスが思わしくなく、徐々に調子が悪くなってくるのだ。特に具合が悪くな る(あらゆる場面で遅くなる)のが、ホストOS上で巨大なファイルのコピーなど の作業を行った後だ。つまり、ホストOSのディスクキャッシュが大きな影響を与 えているものと予想される。 ゲストOS(筆者の場合は主にLinuxだが、Windowsも同様に調子が悪くなる)を 再起動すれば調子は良くなるのだが、それではせっかくのLinuxサーバーがまるで Windows NT4.0のようで、精神安定上よろしくない。 とはいえ再起動すれば調子よくなってしまうため、いったいどのような現象が 起こっているのかつかめず月日は流れていった。 ■0x02.) .vmemファイルの読み込みが遅い あるときゲストOSのリジュームがいつまでたっても終わらないので、.vmemファ イルの読み込みに問題があるのでは?と見当を付けた。そこで1ヶ月以上連続稼働 しているゲストOSの.vmemファイルをddで読み込み、その読み込みの速度を測定し てみる。するとなぜか2MB/sしか速度がでない。ハードディスクには特に問題はな く、シーケンシャルの読み込みでは80MB/sくらいは出るのに、である。 なぜこんなに読み込みが遅いのだろうか?と考えた結果、このファイルがひど く断片化しているのではないかという仮説にたどり着いた。というのは、起動直 後のゲストOSをサスペンド・リジュームさせた場合、比較的スムーズにリジュー ムが完了するのに対し、長い間稼働した後のゲストOSをサスペンド・リジューム させるとひどいことになるからだ。 また、ホストOSのディスクキャッシュの状態がリジュームのパフォーマンスに 大きな影響を与えているように感じていたが、この点について、この断片化した .vmemファイルがディスクキャッシュにのっていない場合にひどくパフォーマン スが悪くなるのではないかと予想した。 ■0x03.) 1つめの解(/dev/shmに置く)に到達 そこで、ハードディスク上での断片化が問題なのだろうという予測のもとに、 .vmemファイルがメモリ上に作成されるようにしてみた。ホストOSにおいて/tmpを /dev/shmへのリンクに変更した上で、vmxファイルでmainMem.useNamedFile = "F ALSE"を記述する。すると.vmemファイルはメモリ上に隠しファイルとして作成さ れる。メモリ上でもファイルとして断片化が発生するのかどうかはわからないが、 HDDよりもランダムアクセスが圧倒的に速いため、これで状況が改善するのでは? と期待した。 結果は期待通りで、長い間稼働させてもパフォーマンスは安定し、サスペンド とリジュームもうまく動いてくれるようになった。この方法の欠点は常にホスト OSのメモリを消費するということだが、メモリをたっぷり積んでいる場合は問題 ない。手軽に実行できるのでおすすめの方法である。 この方法は/etc/vmware/configにtmpDirectory = "/dev/shm"と書き、さらにv mxファイルにmainMem.useNamedFile = "FALSE"と書くことでも実現可能である。 後に検索によってたどり着いた多くのVMware関連のフォーラムなどをのぞいた 感じでは、この手法は一定数のユーザから支持されているようだった。 ■0x04.) 断片化の度合を調べる 今回の調査では某社の気鋭のエンジニアであるINB氏に多大なる協力を頂いた。 筆者が「ファイルがどのくらい断片化しているかを調べる方法を探している」と 伝えたところ、hdparmの--fibmapオプションで可能であることを教えてくれた。 また、前項のtmpDirectoryという項目の存在を教えてくれたのも彼である。この 場を借りてお礼を申し上げる。 hdparmの--fibmapオプションは比較的新しいバージョンのhdparmに実装されて いる。筆者の環境であるCentOS5.2に入っていたhdparmではサポートされていなか ったので、最新版のソースをダウンロードしてコンパイルした(makeするだけで 無事にコンパイルすることができた)。 .vmemファイルに対して以下のように--fibmapオプションを使用する。 ----- hdparm --fibmap 'Windows XP Professional.vmem' ------ すると以下のように結果が出力される。場合によっては非常に大量の出力が発 生するので注意が必要である。 ----- Windows XP Professional.vmem: underlying filesystem begins at LBA 63; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 0 679035215 679035310 96 49152 679035319 679043510 8192 4243456 679043527 679051326 7800 8237056 679051391 679051782 392 8437760 679051791 679059982 8192 12632064 679059991 679067710 7720 (略) ----- 数ヶ月稼働させていたゲストOSの.vmemファイルを調べてみたところ永遠に出力 が止まらないw感じだったので、wc -lにパイプしてhdparmの出力の行数だけを調 べてみることにした。このゲストに割り当てていたメモリは約650MBだったので.v memファイルのサイズもそのくらいだったのだが、なんとhdparm --fibmapの出力 は140万行以上に及んだ。ddでシーケンシャルに同じくらいのサイズのファイルを 作成して調べてみたところわずか359行だった。…断片化ってレベルじゃねーぞ! (`Д´)ノゴラァ とにかくこれで「.vmemファイルがひどく断片化することがパフォーマンス劣化 の原因である」ということはほぼ確定した。そこで「vmware vmem fragmentation」 などでググってみると、案の定たくさんのウェブサイトがヒットした。このことに もっと早く気づいていれば…。 ちなみにこの検索の段階で「filefrag」というそのまんま断片化の具合を調査 するコマンドもあることを知った。手元のUbuntuではデフォルトで入っているよ うである。 ■0x05.) 断片化の理由 なぜ.vmemファイルはここまでひどく断片化するのだろうか。WB43でも書いたよ うに、.vmemファイルはスパースファイルとして生成される。そしてゲストOSを長 い時間稼働させていくにつれて、徐々に実際のサイズが大きくなっていく。 どうやらvmware-vmxプロセスは.vmemファイルを1MBずつの領域にわけてmmapを 行っているらしい。これは、/proc/PID/smapsをlessなどで見ることで確認するこ とができる(PIDはvmware-vmxプロセスのプロセスID)。該当する.vmemファイル について、Size項目が1024KBの領域が大量に見つかる。 おそらくvmware-vmxプロセスは、「しばらくアクセスされていない」等の何ら かの基準に従って、これらの1MBの領域を個別にファイルに同期させているのだろ う。全体で数Gにもなるようなスパースファイルである.vmemファイルに、ばらば らの順番で1MBずつ書き込みを行っているために断片化が発生しているのだと予想 される。 ■0x05.) 2つめの解(.vmemファイルをコピーして入れ替える)に到達 筆者と同じく.vmem問題にはまっている人たちのエントリが大量に見つかったの で適当に目を通してみると、「一度サスペンドさせ、.vmemファイルをコピーして 入れ替え、リジュームする」という作戦が見つかった。断片化が起こる前に、フ ァイル自体をきっちりHDD上に作成してしまおうという作戦である。 見た目のサイズが大きいにもかかわらず、実際には小さなスパースファイルが あるとする。このファイルをddで読み込むことで別のファイルとしてコピーする と、スパースファイルではない通常の(巨大な)ファイルが生成される。コピー の際に、スパースファイル中のまだ書き込みが行われていなかった部分は、コピ ー先のファイルではすべて0x00となる。 こんなことをして何がうれしいのかというと、コピー時に一気に大きなファイ ルを作成するので、ファイルがHDD上にほぼシーケンシャルに作成され、断片化が 非常に少ない形で.vmemファイルを作成することができるのだ。また、このファイ ルはすでに全体をディスク上に割り当てられているため、これ以上肥大化するこ とがない。つまり断片化も進まない。この後いくら長くゲストOSを稼働させ続け ようとも、まったく断片化は進行せず、安定したパフォーマンスを発揮するので ある。 筆者の手元ではcpコマンドでのコピーではスパースファイルのままコピーされ てしまうようだった。そのためddを使ったが、インターネット上で見た感じでは このあたりは環境依存があるようだ(cpコマンドでうまくいっている人もいるよ うである)。 この方法を簡単にまとめると次のようになる ・この方法は、mainMem.useNamedFile = "FALSE"を指定しない場合に使用できる 方法である。つまり、.vmemファイルが/tmp等ではなく、.vmxファイルと同じディ レクトリに作成される場合に使う方法となる ・ゲストOSを起動したら、すぐにサスペンドさせる。 ・この段階で、実際のサイズは非常に小さいが、見た目のサイズは割り当てたメ モリの量に等しい.vmemファイルが作成される(仮にサスペンドせずこのまま使用 を続けると、ひどく断片化しながら肥大することになる)。 ・ddなどを使ってこの.vmemファイルをコピーする。ここでコピー先のファイルは 実際に巨大なサイズのものになる。コピーには数十秒かかる場合もある。 ・コピーが終了したら、コピー元のスパースファイルを削除する ・コピー先のファイルをリネームし、元の.vmemファイルと同じ名前にする ・ゲストOSをリジュームする ・安定稼働(*´Д`)長期実現ポワワ この方法を使えば長期稼働させた後にも安心してサスペンド・リジュームさせ ることができる。欠点は毎回起動後にシェルから操作が必要であることと、コピ ーの時間(数十秒)が掛かることである。 ■0x06.) 3つめの解(LD_PRELOADで.vmemファイル生成) 前項で説明した方法でほぼ問題ないのだが、毎回シェルからファイルコピーな どの操作するのはメンドクチイと思ったので、もう少し踏み込んでみた。WBらしく、リ バースエンジニアリングの領域に突入である。ゲストOSの実体であるvmware-vmxプロセス の動作を一部動的にコントロールする。そして、.vmemファイルをスパースファイ ルではなく、通常のファイルとして作成させてしまうのだ。 幸いなことにWB43にてvmware-vmxプロセスをstraceで追った際に、スパースフ ァイルが作成される箇所は特定済みである。以下はstraceのログからの抜粋だ。 ----- pwrite64(106, "\0", 1, 3774873599) = 1 ----- このように、起動からまもなく、かなり癖のある引数でpwrite64が実行される。 4つめの引数(オフセット)が極端に大きいのに対し、たった1バイトしか書き込 みを行わないことで、この呼び出しがスパースファイルの生成であることが容易 に確認できる。この時点でファイルをシーケンシャルにきっちり作成してやれば、 前項で説明した「2つめの解」と同じ動きを実現できるはずだ。 Linuxではライブラリの呼び出しをLD_PRELOADを使いフックすることで、任意の 関数の内容を書き換え、アプリケーションの動作を変更することができる。ここ ではpwrite64の呼び出しをフックし、スパースファイルの作成を阻止しつつ、実 際に大きなファイルを生成するようにすればいい。ただしpwrite64はvmware-vmx の動作中で何度も使用されるため、スパースファイルの作成を行っている場合の み、挙動を書き換えるようにする。上に書いたように4番目の引数であるオフセッ トが極端に大きく、かつ1バイトしか書き込まない場合に挙動を変更する。このと きpwrite64ではなく普通にwriteを呼び出し、大きな.vmemファイルをきっちり作 成する。そうでない場合はそのまま本物のpwrite64にフォワードし、戻り値もそ のまま返すようにする。 ソースコードは以下のようになる。 ----- #include <dlfcn.h> #include <syslog.h> #include <fstream> #if defined(RTLD_NEXT) #define REAL_LIBC RTLD_NEXT #else #define REAL_LIBC ((void *) -1L) #endif using namespace std; static int flag1 = 0; // pointer to the original function static int (*original_pwrite64) (int file_descriptor, const void *buf, size_t nbyte, off64_t offset) = NULL; // for logging #define LOG(...) do { \ syslog(LOG_INFO, __VA_ARGS__); \ } while(0) #define SADDR_B(target,shift) (((target) >> (shift)) & 0x000000ff) static void __attribute__ ((constructor)) _constructor() { // for syslog openlog(NULL, LOG_CONS | LOG_NDELAY | LOG_PID, LOG_USER); //get address of the original function original_pwrite64 = (int(*)(int,const void*,size_t, off64_t)) dlsym(REAL_LIBC, "pwrite64"); } static void __attribute__ ((destructor)) _destructor() { closelog(); } ssize_t pwrite64(int fd, const void *buf, size_t nbyte, off64_t offset) { int rv; if( flag1 == 0 && offset > ( 1024 * 1024 * 200 ) //works only if offset is larger than 200MB && nbyte == 1 ) { flag1 = 1; LOG( "pwrite64 is hooked. ARGS: nbyte=%d, offset=%d\n", nbyte, (int)offset ); LOG( "creating .vmem file...\n" ); int bufsize = 1024 * 1024; char buffer[ bufsize ]; off64_t remain = offset + 1; while( remain > 0 ) { if( remain > bufsize ) { rv = write( fd, buffer, bufsize ); } else { rv = write( fd, buffer, remain ); } if( rv == -1 ) { LOG( "write failed.\n" ); return -1; } remain -= rv; } return 1; } else { rv = (*original_pwrite64)(fd, buf, nbyte, offset ); return rv; } } ----- ソースのダウンロードはhttp://www.jumperz.net/tools/nosparse.cppから、バ イナリのダウンロードはhttp://www.jumperz.net/tools/nosparse.soから行うこ とができる。 このコードはチームチドリのスーパーハカーyoggy氏が作成したhook_tcp.cppをベースに している。オリジナルのファイルはチームチドリのサイトからダウンロードできる (http://www.t-dori.net/?hook_tcp.so)。スペシャルサンクスコ!!>Yoggyさん&チドリ このコードをnosparse.cppという名前で保存し、次のようにコンパイルして共 有ライブラリ(.soファイル)を作成する。 ----- g++ -Wall -fPIC -shared -o nosparse.so nosparse.cpp -ldl ----- ここで注意したいのは、このコンパイルは32bitのLinuxマシンで行う必要があ るということだ(g++の-m32オプションを使用してもよいのかもしれないが、筆者 の環境ではさまざまなヘッダファイル等が足りずうまくいかなかった)。筆者は 最初X86_64のLinux上でコンパイルしたのだが、vmware-vmxのバイナリが32bit用 のものだったためにうまくPRELOADすることができずハマった(VMware Server 1.0 系列は32bitバイナリなのである)。 32bitのマシンでコンパイルしたnosparse.soファイルをX86_64マシンに持って くることで、問題なく動かすことができる。もちろんホストOSが32bitの場合はそ のままで問題なくうまく動くと思われる。 コンパイルがうまくできたら、以下のようにしてvmware-vmxプロセスをシェル から起動する。ここではnosparse.soは/root/vmware/に、vmware-vmxは/usr/lib /vmware/bin/に、そして起動したいゲストOSのvmxファイルは/vmware/Linux/以下 にあるものと仮定する。 ----- LD_PRELOAD=/root/vmware/nosparse.so /usr/lib/vmware/bin/vmware-vmx -x -C /vmware/Linux/Linux.vmx -@ \"\" ----- 通常はゲストOSの起動はVMware Server Consoleか行う場合がほとんどだと思う が、今回のテクニックを用いる場合にはこのようにシェルからゲストOS(vmware -vmxプロセス)を起動する。このとき、CD-ROMが存在しない等のようなエラーな どがある場合にはVMware Server Consoleに対してダイアログがポップアップする ケースがあるため、VMware Server Consoleからも接続した状態で別ウィンドウの シェルから起動する方法がおすすめである。 うまく起動した場合(上のコマンドを実行し、何もエラー等が出力されない場 合)、まずはじめに.vmemファイルがディスク上にほぼシーケンシャルな状態で作 成される。例えばゲストOSのメモリを2GB程度割り当てた場合には数十秒の時間を 要するので、じっと待つ。ここで時間がかかるのが欠点だが、起動後のパフォー マンスはすこぶる安定するのでじっと待つ価値はある。 .vmemファイルを生成する際に、syslogに(通常は/var/log/messagesに)以下 のようなログが出力される。 ----- Nov 17 18:27:06 raptor vmware-vmx[21321]: pwrite64 is hooked. ARGS: nbyte=1, offset=2017460223 Nov 17 18:27:06 raptor vmware-vmx[21321]: creating .vmem file... ----- .vmemファイルが無事生成されると、続いて通常と同じようにVMware Server C onsoleにBIOS画面が表示され、続いてゲストOSの起動が始まる。ここで試しにhd parm --fibmapしてみると、出力はわずか1000〜1500行程度に抑えられており、断 片化の防止に成功したことがわかる。 この後は普通にゲストOSを使用できる。サスペンド・リジュームを行う場合は 再度PRELOADする必要はないので(.vmemファイルはすでに完成しているので)、 コンソールから普通に操作すればOKである。 ■0x07.) まとめ 今回は、LinuxをホストOSとして使うVMware Server 1.0.x系列について、サス ペンド&リジュームや長期使用時のパフォーマンス劣化の原因が.vmemファイルの 断片化であることを特定し、またその対策として3つの案を提示した。. vmemファイルの断片化を防止すれば、VMware Serverはすこぶる良好な使用感と なり、非常に満足度の高い仮想化技術を提供してくれる。筆者はここ数年長い間 苦労してパフォーマンス劣化と戦ってきたが、ついに問題点を解決することがで き、非常に晴れ晴れとした気分である。VMwareにはESXiなどもあるのでServerの 1系列にこだわる必要はないと思うかもしれないが、筆者はホストOSとしてのLin uxの機能(iSCSI、ソフトウェアRAID、リモートから使用できる充実した管理機能 など)を必要としているのでServerにこだわっていたりする。今後もしばらくの 間は使い続けることになるだろう。 ■0x08.) おまけでQ&A なんでこのファッキンVMwareはこんなに具合悪いのマダファッカ? .vmemファイルが断片化しているから .vmemファイルの実際のサイズの確認方法は? ls -lsuhあるいはduで確認が可能 .vmemファイルはいつ作成されるの? ゲストOS起動直後 .vmemファイルはどこに作成されるの? 通常.vmxファイルと同じディレクトリだが、vmxファイルの設定でuseNamedFile をfalseにしておくと/tmp以下の隠しファイルになる。この/tmpの位置は変更可能(本 文参照) .vmemファイルはいつ書き込まれるの? vmware-vmxプロセスがマターリとメモリと同期させる。数日がかりで観察する と徐々に大きくなることが確認できる .vmemファイルはいつ読み込まれる(役に立つ)の? レジュームするとき。あるいはmemory page trimmingが有効な場合には、vmwa re-vmxプロセスが判断して随時読み込む .vmemファイルの断片化の程度はどうやって確認するの? hdparmの最近のバージョンで hdparm --fibmap *.vmem | wc -lすればどの程度 かをつかめる。あるいはfilefragコマンドを使う .vmemファイルの断片化を防ぐ方法は? 起動直後にサスペンドさせ、ddでファイルをコピーして入れ替え、リジューム するか、LD_PRELOADしてスパースファイル生成を阻止する(詳細は本文参照) .vmemファイルを使用しない方法はないの? ない .vmemファイルがなくなったみたいだけど? /tmp以下に隠しファイルとして存在している。lsofでvmware-vmxプロセスを見 ると見つけることができる サスペンドは使わない方がいい? 断片化しないように対策してあれば普通に使える memory page trimmingは使わない方がいい? ホストOSのメモリが足りなくなる可能性があるなら(かつ断片化を防止してい るなら)便利に使える。メモリに余裕があるなら使わない方がいい useNamedFile="False"の意味は? .vmemファイルを/tmp以下の隠しファイルにするという意味。理解していないと 地雷 ゲストOSが消費しているメモリ量の確認は? vmware-vmxプロセスについて、/proc/PID/statusのRSSを見る。あるいはtopで SHR項目を確認
========================================
VMwareのテンポラリはいったいどこなんだ?等を調べるときに
「du」や「ls」をしても使われている痕跡が出ない。
「df」だと出る。例えば以下のとおり。
筆者が使っているバージョンはLinux版のVMware Server 1.0系列で、 ホストOSはX86_64のCentOS5.2である。他のバージョンを使っている人には参考に ならない点が多々あるかと思うがご了承願いたい。
$ df -ahT|grep shm
tmpfs tmpfs 700M 393M 308M 57% /dev/shm
$ du -sh /dev/shm
8.0K /dev/shm
参考URL → http://www.tim.hi-ho.ne.jp/cgi-bin/user/eta2/diary/080505
============================
2012-10-24 16:38
nice!(1)
コメント(0)
サイト内 アクセス上位ページ
☆メモリ診断(テスト):定番『Memtest86+』。トラブルが出たら・・・
☆micro SD カード → xDピクチャーカード変換アダプタって無いの?
☆DVDの書き込み速度が遅いのは何故?
☆bootコード 修復(上級者用) XP 回復コンソール
☆突然 電源が落ちる (まとめ)
☆Install Shieldの自動更新ツール 止め方
☆DS Liteの修理(上液晶)
コメント 0