SunRay2で画面描画が遅く残像らしきものが残る

SunRay2デスクトップユニット(DTU)で、Sun Ray Connector for Windows を使いWindowsターミナルサーバに接続しています。

そこで画面の描画が遅いという問い合わせが殺到しました。

見てみたところ、特に描画負荷が高い画像等を表示するときに描画が間に合ってない感がします。しばらく待ってれば描画されるんですが、画像多めのWEBページとかをスクロールした日には昔の画面が崩れるウイルスのような感じでしたね。

まぁ全く使えないほどではないのでとりあえずユーザにはそのまま使ってもらうことに。

SunRayサーバやターミナルサーバには負荷がかかってる様子はなかったので、ちょうど先日SunRayサーバ周りのネットワーク構成を少し変えたのでそれが原因かなと思いました。

まずネットワーク障害で多いループによるブロードキャストストームを疑いました。しかし、L2スイッチ(ハブ)のLEDもそれほど激しくはなく、PCでパケットキャプチャしてもブロードキャストパケットはそれほど多くはありません。

(ブロードキャストストームについては、下記サイトが参考になります。

また、SunRay DTU からターミナルサーバではなく、直接Solarisの画面を表示してもはやり、描画が間に合っていません。

実はSunRayからWindowsターミナルサーバとの間は別ネットワークとして構築してます。

下記のような感じです。


クライアント←(192.168.0.0/24)→SunRayサーバ←(192.168.100.0/24)→Windowsターミナルサーバ

これはSunRayとWindowsターミナルサーバとの間のネットワーク負荷が高いとのクラスタ構成が関係していました。

で、この 192.168.100.0/24 のネットワークにSuRay DTUを置いてSunRayサーバのSolarisの画面表示したら遅延なく表示されました。

ということで、どうやら 192.168.0.0 のネットワークがおかしいようです。(まぁいじったのもそっちのネットワークだったので。。。)

先般実施したネットワーク構成変更ってのも、新規別サーバ増設とL2スイッチの移動だけでした。

ここで思いついたのはパケット損失です。

(このときMTUも疑いましたが、pingで調査したところ問題ありませんでした。pingによるMTUサイズの調査方法は@IT:pingでMTUサイズを調査する参照)

まず、SunRay2 がどういうプロトコルでやり取りしてるのか調べました。

結構いろんなポート・プロトコル使うんですね。。

注目したのは一番データが多そうである、ALP-RENDER と呼ばれてる画面描画プロトコルです。

UDPを使っているんですよね。。。

UDPって投げっぱなしのプロトコル。つまり、途中で破棄されたらそのままです。

どうも今回はこの可能性が高いのではないかと疑いました。

で、夜にSunRayサーバが繋がってたもともとのハブに差し替えたところ、なんと画面描画遅延が発生しなくなりました。

やはりハブが原因だったようです。

ただ、カタログ見る限りはもともとのハブは100Mbpsでネットワーク構成変更で繋ぎ換えたハブは1000Mbpsでスループットも上なんですよね。。。

カタログ表記にない何かが影響したのかどうか詳しくはわかりませんが、まぁ遅延なくなって助かりました。

もしかしたら、L2スイッチとサーバ側NICの相性問題かもしれません。

もしくはオートネゴシエーションの問題が、フロー制御かな。。。

ちなみに、SunというかOracleはSunRayの使用に300kbpsを推奨しています。

これって結構大きいのかなと思います。

ターミナルサーバやリモートデスクトップで使う RDT プロトコルは 64kbps の帯域で、メタフレームはさらにその半分の帯域で済むようですし。。

後気になったのは、このSunRayサーバに ping を飛ばすと最初の一回目が Time Out となる時があるのです。

Time Out となるのは arp キャッシュがクリアされている時のようです。

(Windows の場合 arp -d * でMACアドレスのキャッシュをクリアできます。)

やはりネットワーク負荷がかかってるんでしょうかね。。。

補足(2013/3/16)

遅延の原因が分かりました。詳しくは、SunRay2で画面描画が遅く残像らしきものが残る Part2を参考。

3流プログラマのメモ書き