goodgames
20-01
最終更新：
goodgames
-
view
嫌な噂
(怒)
もう一回調べて来ます。
もう一回調べて来ます。
間違いないから続行。
題名と本文冒頭が微妙に異なりましたが最後で話が繋がるのでこのままで。
繋がると言うより繋げると言った方が正しいような...
繋がると言うより繋げると言った方が正しいような...
さて本題。
最近、管理者の方々とのコミュニケーションにてどうも印象にずれが生じていたのがGSラグの問題。
個人的にはかなり改善している印象でした。また同様に感じられている方がいらっしゃるのも事実です。
しかし、BF3開始以来最悪レベルとの主張もあり、どの意見が本当なのか測りかねていたのが実情です。
しかし、BF3開始以来最悪レベルとの主張もあり、どの意見が本当なのか測りかねていたのが実情です。
そのため、一つの考察としてi3Dとのスロット数を以前に比較するなど、色々と原因を探っておりました。
この種の話には根本的な問題があり「ラグ」なるものは明確に定義されておらず、
一般的には体感的な指標なので単純比較が出来ないところが困りものです。
一般的には体感的な指標なので単純比較が出来ないところが困りものです。
そこで、まずはラグを数値化することにしました。
ところがここで誤算が。
これは私の日程計画上の問題ですが、ウチのGS機が契約期間満了となり使えなくなりました。
これは私の日程計画上の問題ですが、ウチのGS機が契約期間満了となり使えなくなりました。
期間の終盤ではほとんど困るようなラグを感じることもなく、
最近のGS機は比較的性能改善しているかと考えていたところですが...
最近のGS機は比較的性能改善しているかと考えていたところですが...
しかし、サーバ側から数値化する必要はないので、
もっとわかりやすくクライアント側から数値化する実験を開始いたしました。
もっとわかりやすくクライアント側から数値化する実験を開始いたしました。
他の方のGS機に御邪魔したところ、とんでもないラグ。
歩行不能です。
歩行不能です。
待ち行列に並んで接続されたので私がラウンド内に入った時点でほぼ満員でしたが、
チャットはLAAAAAGやWTFの連発状態。
チャットはLAAAAAGやWTFの連発状態。
冗談ではなく3歩前進2歩後退と言った感じで、
BFBC2時代の最悪期を彷彿とさせるものがありました。
BFBC2時代の最悪期を彷彿とさせるものがありました。
ラウンド終了と同時に一気に15人程度までプレイヤー数が減少してしまいました。
プレイヤー数減少による負荷低下もあり、次のラウンドは快調にスタートしましたが...
プレイヤー数減少による負荷低下もあり、次のラウンドは快調にスタートしましたが...
数分後、40～42名に達したところで
ラバーバンドとかゴムラグとか言われるような状態がぽつぽつと発生。
ラバーバンドとかゴムラグとか言われるような状態がぽつぽつと発生。
46名で歩行困難。
50名前後で戦車がワープ連発。
50名前後で戦車がワープ連発。
ウチで使用していたGS機は大きな問題は無く、
他にも問題を感じていない管理者の方がいらっしゃいましたが、
意見が一致しない理由が良くわかりました。
他にも問題を感じていない管理者の方がいらっしゃいましたが、
意見が一致しない理由が良くわかりました。
アタリとハズレの差が大き過ぎる
自分は比較的アタリを使っており、
しかも解約後ですから直接的な不満はありませんが
これだけサービスに差があるってどうなんでしょうね。
しかも解約後ですから直接的な不満はありませんが
これだけサービスに差があるってどうなんでしょうね。
どうなんでしょうと聞くまでも無く良いわけないのですが...
と、これで終わったら単なる愚痴にもならないので原因を調査したところまた驚きの連発。
前述のラグを数値化計画で詳細を記載するつもりでしたが、
極々簡単にゲームサーバの裏側を御説明させて頂きます。
極々簡単にゲームサーバの裏側を御説明させて頂きます。
Battlefield3用のレンタルサーバはWindowsServer2008R2が導入され、
その上でMicrosoft謹製のハイパーバイザーであるHYPER-Vが稼働しています。
その上でMicrosoft謹製のハイパーバイザーであるHYPER-Vが稼働しています。
ハイパーバイザーって何だ?
と思われる方が多いのは当然のことで一般的にこれに触ることはまず無いでしょう。
と思われる方が多いのは当然のことで一般的にこれに触ることはまず無いでしょう。
「仮想化」と言う言葉を耳にされたことのある方は多いと思います。
近日中に簡単な絵で説明いたしますが、簡単に言ってしまえば「OSの上でOSを稼働させる技術」です。
近日中に簡単な絵で説明いたしますが、簡単に言ってしまえば「OSの上でOSを稼働させる技術」です。
本物のOSの上にアプリケーションの如く別のOSをインストールと、
両方のOSがお互い干渉することなく同時に稼働する。
しかもアプリケーションの如くインストールされるOSは
ハードウェア資源が尽きるまで何本でもインストール可能であり、
多数インストールされたOSが同時に稼働する。
両方のOSがお互い干渉することなく同時に稼働する。
しかもアプリケーションの如くインストールされるOSは
ハードウェア資源が尽きるまで何本でもインストール可能であり、
多数インストールされたOSが同時に稼働する。
これを実現してくれるソフトウェアがハイパーバイザーになります。
(ここ極めて重要なので実際にイメージしてみて下さい)
イメージ的にはWindows7のデスクトップ上に2つのウインドウが存在し、
それぞれのウインドウ内にはWindowsXPとWindowsVistaのデスクトップが存在する感じです。
それぞれのウインドウ内にはWindowsXPとWindowsVistaのデスクトップが存在する感じです。
もちろんデスクトップの壁紙が表示されているだけでなく、
デスクトップ上のアプリケーションは本当にリアルタイムに稼働します。
デスクトップ上のアプリケーションは本当にリアルタイムに稼働します。
(参考)Youtube
Installing Windows XP in Windows 7 Using VMware Workstation 7
HYPER-VではありませんがWindows7上にWindowsXPをインストールして起動するデモ映像です。
Installing Windows XP in Windows 7 Using VMware Workstation 7
HYPER-VではありませんがWindows7上にWindowsXPをインストールして起動するデモ映像です。
この参考映像や上の例では比較的馴染みのOSであるWindows7やWindowsXPを使用していますが、
実際にはWindows2008Server R2の上に同じOSであるWindows2008Server R2がインストールされています。
(ライセンスコストの問題でこの構成に限定されている)
実際にはWindows2008Server R2の上に同じOSであるWindows2008Server R2がインストールされています。
(ライセンスコストの問題でこの構成に限定されている)
そして我々管理者はハイパーバイザーの上に存在する
WindowsServerのうちの一つを借りていることになります。
WindowsServerのうちの一つを借りていることになります。
御存知の方や感の良い方はもうピンと来ているはず。
ハイパーバイザーの上でいくつWindowsServerが稼働しているかは、
物理的な意味でのサーバによって大きく異なっています。
ここはあくまでも一般論になりますが、
提供者側の立場で考えると管理上の理由により、
あまりサーバの機種を増やしたく無いのが本音のはずです。
提供者側の立場で考えると管理上の理由により、
あまりサーバの機種を増やしたく無いのが本音のはずです。
従って、原則的にはサーバの機種は一種類(つまり性能は平等)と考えられるため、
多くのWindowsServerが稼働しているサーバを借りている方は相対的にラグが悪化します。
管理者同士で限りあるサーバ資源を奪い合っている状態です。
さて核心に近付いて参りました。
この不平等がどの程度の差になるのかが問題です。
この不平等がどの程度の差になるのかが問題です。
また、サーバ負荷はスロット数にほぼ正比例すると考えられるため、
稼働中のWindowsServerの数よりも合計スロット数を比較する方が負荷が正確に予想可能です。
稼働中のWindowsServerの数よりも合計スロット数を比較する方が負荷が正確に予想可能です。
では、結論に。
2013/09/20 22:00現在、GS東京DCではBF3用サーバが35台前後稼働しています。
各サーバ内で稼働している総スロット数は...
最低はなんとゼロ。
最大はなんとなんと640スロット。
そしてウチが先日まで借りていたサーバがゼロスロットのサーバに該当しています。
つまり、ウチが借りていた頃はウチだけ、つまり64スロットのみが稼働していたと考えられるため、
640スロット稼働しているサーバが当時から640スロットで稼働していたとするならば、
なんと処理負荷は10倍にも達していることになります。
つまり、ウチが借りていた頃はウチだけ、つまり64スロットのみが稼働していたと考えられるため、
640スロット稼働しているサーバが当時から640スロットで稼働していたとするならば、
なんと処理負荷は10倍にも達していることになります。
ちなみに前述の歩行不能サーバの総スロット数は416スロットでした。
長くなってきたので、このページの結論と言うか件名のお話。
一週間程前だったと思いますが前回のBattlelogメンテナンスで何が変わったか御存知でしょうか?
恐らく、何カ所も変更されていると思いますが、理由の良くわからない修正が行われていました。
恐らく、何カ所も変更されていると思いますが、理由の良くわからない修正が行われていました。
(参考画像)
偶然昔撮影したBattleLog
偶然昔撮影したBattleLog
この画像はi3Dでサーバのpingが表示されない不具合を説明するために用意したものですが、
画像の右下にIPアドレスが表記されています。
画像の右下にIPアドレスが表記されています。
しかし、先日のメンテナンスでIPアドレスが表示されなくなりました。
なぜこのような改修が行われたのかは定かではありませんが、
「物理的な意味での1台のサーバが何スロット処理しているかを計算されたくない」
のではないかと予想された方がいらっしゃいました。
「物理的な意味での1台のサーバが何スロット処理しているかを計算されたくない」
のではないかと予想された方がいらっしゃいました。
さすがに深読みし過ぎかとその場では思いましたが、
GSの現状を見ると予想は当たっているのかもしれません。
GSの現状を見ると予想は当たっているのかもしれません。
説明が後になりましたが、同じIPアドレスのゲームサーバ
は特別な事情が無い限り物理的な意味で同じ1台のサーバ内で稼働しています。
は特別な事情が無い限り物理的な意味で同じ1台のサーバ内で稼働しています。
そのため同じIPアドレスのサーバが少ない程、快適と考えて良いでしょう。
ちなみにIPアドレスはBattlelogの裏側にコッソリ隠してあり、
StatsNow!!のデータ収集部がせっせと持ち帰ってくるため、
個人的には隠されていても丸見えです。
StatsNow!!のデータ収集部がせっせと持ち帰ってくるため、
個人的には隠されていても丸見えです。
( - )
