A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

仮想化サーバでのマイクラサーバ構築メモ

ちょっと専門書を読んでたのでメモメモ。ちなみに仮想化ソフトウェアはKVMを使ってます。 ほとんどマイクラとは関係のない話題なので、無関心な人は無視して下さい。

ちなみにマイクラプラグインの負荷を調査したいなら、/timingコマンドについて調査すると良い。

CPU Planningで使用するCPUは固定化すること。好きなCPUを選ばせるとマイクラ側がラグが強烈に発生する。(mpstatの%stealが増えるのでわかる) CPUはゲストOSで使用しない分を一つ残す方がいいらしい。つまり、CPU2個ずつ使うゲストOSを3個作った場合は、CPUの数は2×3+1(ホストOS用)が最低数。 たぶん、10人くらいログインするサーバならCPU2つで十分。Avalonは念のため4つにしてる。 CPU2つって言っても、ハイパースレッディングなので、物理コアが一つなのに注意。マイクラはかなり一つのCPUに負荷をかけるので、CPU2個(2スレッド)で回すのは微妙? やはりCPU数よりもスピード重視がいい。(マイクラは) 2.4GHzのCPUに10人くらいログインして、CPU使用率は80%/1コアくらい。 お金がないからやってないけど、物理CPUを増やすなら、1つのゲストOSのvCPUを2つの物理CPUに分けるのはやめた方がいいらしい。 マイクラサーバは一度CPU使用率が上がる、さほど上がらない傾向があるので、毎日再起動した方がよい。 メモリ 一番謎が多く、課題として取り組んでいるポイント。たぶんプラグイン毎のメモリ使用数とか分析しないとわからなさそう。 言うまでもないがホストOSに32bit OSは使わない(メモリ上限の問題) 起動時のJAVAの-serverオプションは必須なのは当然なのだが、そうすると「ほぼ」常時-Xmx分を使用する。(厳密には起動直後だけあまり使わない)。 多かろうが、少なかろうが「設定しただけ使われる」。 -Xmnは-Xmxの1/3~1/2の間くらいがちょうどいいみたい。これ以上減らすとFullGCの発生数が増えるし、増やしても変化が少なくなる。 -XX:PermSizeと-XX:MaxPermSizeは少ないと明らかに不具合が起きるが、どこまで増やしていいかは謎。256Mくらいで動かしてる。 やはり起動しっぱなしだとFullGCの時間が徐々に増えていくようなので、毎日再起動した方が安定していそう。 HugePage?→要調査 ディスク やはり、パフォーマンスはノーマルなrawやqcow2よりも、sparse化したrawが最強らしい。今のサーバはLVMでパーテーションをマルっとディスクに割り当ててるけど、遅い気がする? qcow2はスナップショットが作れるのであればあったで便利。不具合があった場合に一瞬で巻き戻しできるし。 2つのマイクラサーバを、2つのゲストOSで稼働させているが、そのファイルを1つのディスク上に展開しているのは超失敗、、、。片側のI/Oが上がると、もう片方のマイクラがラグる。気にするほどじゃないけど、ddコマンドとかでrawファイルを作ったり、dynmapでマップ生成を別ゲストで実施しても、影響が出る。 特にHDDの場合は、2ゲストを1HDD上に置くとシークタイムが増えて、パフォーマンスが激減するらしい。 ただ、単純にディスクを分ければいいのか、それともコントローラまで分けないと意味がないのかは不明。 まぁ、今の時代はSSD。 ミラーリングの必要性は疑問。マイクラサーバは(最近は安定しているけど)、OSが強制停止したりするとチャンク欠落などが高い確率で発生する。 だから、障害発生時は「巻き戻し」が必要なので、バックアップの多世代化が必要。特にサーバ異常停止→自動起動の仕組みにしている場合は、障害データのまま古いバックアップを上書き削除する場合がある。 たとえば、1時間毎10世代とかのバックアップをするなら、ディスクが壊れてデータ欠損をしたところで、1時間前のバックアップがあればそこから戻せるので、あまり問題は起きない。だから、ミラーリングにお金をかけるくらいなら、単構成にしてバックアップ世代数を増やした方が安全な気がする(当然バックアップの物理ディスクは分ける) ファイルシステムはext3より、XFSの方が性能がいいらしい。 ディスクパーテーションの論理的な開始位置と物理的な位置がずれるとパフォーマンスが落ちるらしい。Linuxは4kb単位らしいが、ゲストOSからは512kbに見える?よくわからないので調査が必要。 仮想ディスクのディスクパスはやはりvirtioにするのがパフォーマンス上よい。IDEは最悪らしい。 I/Oスケジューラはdeadlineがいいらしい。SSDの場合はnoopもいいらしいけど、技術資料には「負荷状況にもよるが、ホスト側もゲスト側もdeadlineにするとベンチマーク結果が安定する」って書いてあった。ちなみにデフォルトはCFQ また、新しめのOSでも、ホストOSのバージョンが古いとディスクパフォーマンスが低下するらしい。 IOモードががnativeの場合、ブロックサイズを大きくした方が、高速でCPU負荷が減るらしい。(32kぐらいがいい?) ネットワーク デバイスモデルはvirtioを使う。CentOSならドライバもあるから選択の余地なし。rtl8139が一番パフォーマンスが悪いらしい。 仮想化環境用クローズドネットを作った方がいいね。作って無いや…

 

I/Oスケジューラの扱い方(カーネル2.6.17以上かも) 以下の例は物理デバイスが/dev/vdaの場合。ちなみに再起動すると戻るので、bootオプションにもつけないとダメ。

確認 # cat /sys/block/vda/queue/scheduler noop anticipatory deadline [cfq] 設定 # echo deadline > /sys/block/vda/queue/scheduler 確認 # cat /sys/block/vda/queue/scheduler noop anticipatory [deadline] cfq