SunRayで誰かが動画再生すると全体の描画が遅くなった
SunRay2を使ってるんですが、突然描画重くなったりする現象が発生してました。
サーバのCPU,メモリ負荷は問題なかったため、smokeping でSunrayサーバのネットワークの遅延を調べてみると以下のようになってました。
ちょうど描画が重かった12:40-13:00にかけて大きな遅延が発生しています。
さらにユーザの利用調査をしていると、どうやら動画再生をしているときに重くなり、Sunrayサーバへの遅延も発生しているようです。
この現象についてググると、Osamu Sayama's Weblog：sunray bandwidth limit にドンピシャな情報が載っていました。
どうやらSunRayで動画サイト等を見ると、画面遷移が多いためサーバ側はクライアント側に大量の描画パケットを送信します。
SunRayの描画パケットはSunRay2で画面描画が遅く残像らしきものが残るで書いたようにUDPを使ってます
UDPは相手の都合お構いなしにパケットを投げるので、今回の動画のように画面更新が多くて、クライアント側のネットーワークがサーバ側ネットーワークより遅い場合、描画パケットが大量過ぎて捌ききれない状態になり、他のユーザへの描画パケットや/クライアントからのマウス・キーボード操作パケットが破棄/遅延されてしまうようですね。
参考先にあるように、DTU側で帯域制限をしてやれば、そのDTUに対してサーバ側は設定された帯域以上はパケットを投げず全体への影響を抑えることができるようです。
それで、utcapture コマンドで帯域制限無しと有りでのSunRayサーバ～クライアントのパケットロスを調べてみました。
utcapture の結果の各列の意味は下記のとおりです。
TERMINALID:クライアントの MAC アドレス。
TIMESTAMP:「20041229112512」などの「年-月-日-時-分-秒」の時刻形式で表示されるロスが発生した時間。
TOTAL PACKET:サーバーからクライアントに送信された合計パケット数。
TOTAL LOSS:クライアントによって消失と報告された合計パケット数。
BYTES SENT:サーバーからクライアントに送信された合計バイト数。
PERCENT LOSS:現在と前のポーリング間隔の間に消失したパケットの割合。
LATENCY:クライアントとサーバー間の往復にかかる時間 (ミリ秒単位)
まず帯域制限をかけなかった場合です。
====帯域制限なし
bash-3.00# /opt/SUNWut/sbin/utcapture | grep aabbcc(特定のDTUのみ抽出したかったので、そのDTUのMACアドレスでgrepしてます)
TERMINALID TIMESTAMP TOTAL PACKET TOTAL LOSS BYTES SENT PERCENT LOSS LATENCY
↓通常の業務操作
002128aabbcc 20111111143745 45453 6565 51095948
002128aabbcc 20111111143815 82038 9317 96325054 7.522
002128aabbcc 20111111143830 124093 11114 150312460 4.273
002128aabbcc 20111111143845 135388 11664 164520680 4.869
↓画像ファイルを全画面で表示を繰り返したとき
002128aabbcc 20111111143915 142906 13804 171358852 28.465
002128aabbcc 20111111143930 203722 32692 227348840 31.058
002128aabbcc 20111111143945 287421 66322 293922746 40.180
002128aabbcc 20111111144015 318069 76575 321067832 33.454
002128aabbcc 20111111144031 318079 76576 321068570 10.000
画像ファイルを全画面表示するとやはりサーバから送信するパケットが増えるとと共にパケットロスと遅延が増大しています。
次に、DTU側で帯域制限を 30Mbps でかけた時です。
(帯域制限のかけ方は、DTUで Ctrl+Pause+M → Advanced → Bandwidth Limit で、bps単位で帯域を制限します)
====帯域制限あり 30Mbps
bash-3.00# /opt/SUNWut/sbin/utcapture | grep aabbcc
TERMINALID TIMESTAMP TOTAL PACKET TOTAL LOSS BYTES SENT PERCENT LOSS LATENCY
↓画像ファイルを全画面で表示を繰り返したとき
002128aabbcc 20111111144231 86999 11306 101932702 7.813
002128aabbcc 20111111144301 123778 16061 145332462 12.929
002128aabbcc 20111111144316 151922 20277 177660986 14.980
ちょっとは送信パケットが減り、同様にパケットロスと遅延も減っています。
さらに、8Mbpsで制限をかけた時です。
====帯域制限 8Mbps
bash-3.00# /opt/SUNWut/sbin/utcapture | grep aabbcc
TERMINALID TIMESTAMP TOTAL PACKET TOTAL LOSS BYTES SENT PERCENT LOSS LATENCY
↓画像ファイルを全画面で表示を繰り返したとき
002128aabbcc 20111111144446 48332 1457 61692026 2.405
002128aabbcc 20111111144531 51240 1458 65180180 0.117
002128aabbcc 20111111144546 53590 1478 68135492 0.851
002128aabbcc 20111111144616 57335 1627 72505752 3.979
002128aabbcc 20111111144731 67512 1629 84757134 0.261
002128aabbcc 20111111144847 80039 1653 99529180 1.666
↓画像ファイル全画面テスト
002128aabbcc 20111111145132 88198 1853 110024494 2.483
002128aabbcc 20111111145147 100233 2177 125551832 2.692
8Mbpsでは、画像ファイル全画面表示しても大きな遅延やパケットロスがさほど発生していません。
もちろんクライアント側では制限なしの時に比べると描画が遅く感じますが、他への影響をかけないという観点からするとやはり帯域制限は必要だと感じました。
参考：
Sun Ray Server Software 4.0 管理者マニュアル P34あたりにutcaptureの使い方が載ってます。
最近忙しすぎて全然ブログ更新できてませんでしたが、ようやく時間ができたのでボチボチアップしていこうかと思います。
