情報科学屋さんを目指す人のメモ(FC2ブログ版)

何かのやり方や、問題の解決方法をどんどんメモするブログ。そんな大学院生の活動「キャッシュ」に誰かがヒットしてくれることを祈って。

ブログ内検索

スポンサーサイト このエントリーを含むはてなブックマーク

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
スポンサー広告 | 編集

SSHトンネルを介したリモートデスクトップがものすごく遅い時 このエントリーを含むはてなブックマーク

PuTTYのSSHトンネルでリモートデスクトップをしたら遅すぎた

PuTTYのSSHトンネル機能を使ってlocalhostのポートからリモートデスクトップで接続したいWindows Vista PCのリモートデスクトップ用ポート(3389)までトンネルを作成し、リモートデスクトップ接続を試みました。

ところが、こうして接続したリモートデスクトップは、ログイン自体はできるものの、あまりに遅すぎて使い物になりませんでした。さらに、putty.exeのCPU使用率が40-50%(デュアルコアCPU使用)となり、非常に高く、全体的なPCの動作速度も著しく低下しました

True Remoteを使ってみても遅かった

これはきっとリモートデスクトップの効率が悪いせいだということにして、軽量高速とはてなで盛り上がったTrue Remoteを使ってみることに。

True Remoteでは、まずリモート接続される側(サーバ側)のWindows PC上でTrue Remoteを起動させておきます。このときにポート番号も指定するので、そこで指定したポート番号に向かってSSHトンネルを作ります。

そして、リモート接続する側(クライアント側)のWindows PC上でTrue Remoteを起動し、接続を試みました。

すると、確かにパスワードによるTrue Remote自体に備わっている認証は正しく完了したようなのですが、何も表示されない。さて、これはどうしたものかと。

True RemoteをSSHポートフォワーディングを使って利用したという報告はWeb上で見つかるので、なにか私が間違っているのだろうと思いました。そこで、とりあえずTrue Remoteのことを考えるのではなく、PuTTYの設定をいろいろいじってみることにしました。

リモートデスクトップとTrue Remoteが遅かった理由

そして、いろいろ試してみた結果、PuTTYの設定のセッション>ログにあるセッションのログを「なし」に設定することで解決しました。以前、問題解決のためにログをとる設定にしたままセッションが保存されており、こんかいそのセッションをコピーして利用していたのでこのような設定になっていました。

つまり、PuTTYがログをとるのに大忙しでCPU使用率が増加するだけでなく、SSHの通信自体のスループットが大きく低下していたというのが原因でした

高速化→解決

以上の設定のおかげで、リモートデスクトップとTrue Remoteはどちらも使用に耐えるスピードで動作するようになりました。まだ外出先からの接続速度を試してみてはいないのですが、楽しみです。

結論

PuTTYのログ機能は性能を大きく損なう可能性があるので要チェックです。気をつけましょう。

スポンサーサイト
SSH | コメント:0 | トラックバック:0 | 編集

Excelの文字入力が遅い このエントリーを含むはてなブックマーク

Office 2007 の Excel で文字入力をしているとき、異様に文字入力が遅くなり、入力した文字が時間差で表示されるほどでした。

まぁ、あまり使わないので我慢しており、なんとなくATOKのせいかなと思っていました。

でも、冷静に考えてみると、遅くなるところはいつも同じ列で、 なんでその列だけ遅いんだろうと考えてみると、オートコンプリートじゃないかということに。

Excel | コメント:6 | トラックバック:0 | 編集
 | HOME | 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。