2005年1月16日

[openoffice:6869] Re: calcが保存時に固まる

安達です。
> c) [保存]ボタンを押した直後
です。

> ア) 左端に「ドキュメントの保存」はまだ表示されていない。
> イ) 左端に「ドキュメントの保存」と表示されていて、プログレスバーの進捗度合いが 0%
> この状況がどちらなのかが、解析のヒントになりそうです。

ここは残念ながらわかりません。

> ??) ファイルとしての入れ物を作る
> ??) 中身を書き込む
> ??) 閉じて、変更日時などを書き込む
> の ?? の部分よりも前か、?? の作業を OOo が Windows に依頼し、OOo は Windows 側
> からの作業終了通知を待っている。しかし、いつまでたっても Windows 側から OOo に
> 作業終了の通知が戻ってこない。。。と、勝手な推測です。

その通りだと思います。

> はい。かなりの数のファイルを開きます。それは、順に一つのTCP/IPのコネクション
> を通して使うでしょうから、Sambaとしての同時接続数は、クライアントPCの台数を
> 少し上回ってれば、十分だと思います。

なるほど。安心しました。

>>Windowsは必要になったら接続し直すので問題ないと思っています。
> いわれてみれば、そうですね。サーバー側で TCP のコネクションを開放している「接続」
> (発IP, 着IP, 発ポート番号, 着ポート番号, プロトコル種別) に対して、Windows 側が
> 通信を試みれば、サーバー側は RST (リセット)パケットで応答しますから、Windows 側は
> 気が付き、何らかの対処(接続し直す)をするはずですね。

そういうことをやっているのは知りませんでした。
Windowsのネットワークの設計は基本的にサーバーを信頼していませんね
ピアツーピアのネットワークからスタートしたからでしょうけど。

> もしかして、無線LAN を使っていますか?

いいえ。無線LANは基本的にダムハブの世界なので(スイッチングハブ以前の意)
多数で使うのは苦しいと思っています。

> よくよく調べてみたところ、Webサーバー側が MTU 1500オクテットでパケットを送り出すと
> 途中に入っているプロバイダが PPP を使っているため、14xxオクテットと 1xxオクテット
> の二つのパケットに分割するんです。そして、二つのパケットが間髪いれずに Windows へ
> 届くのです。Windows の無線LANドライバが二つ目の小さなパケットを取りこぼすんです。
Windowsが分割された2つめのパケットを取りこぼすという話は
「SambaでWindows NT Server と同じ転送速度を確保する方法」
( http://www.dd.iij4u.or.jp/%7Eokuyamak/Documents/tuning.japanese.html )
にありますね。「一部の NIC カードを使った Windows では、なぜか
data packet を時々取りこぼす という状態が発生します。 」ということ
なので、無線LANに限らないようです。
実は今回のトラブルでもこれに基づいて設定を変えてみましたが、
calcの問題はまだあります。ログオン時のハングは少し減ったような
気もしますがどうでしょう?? 気のせいかも。

> 1. OOoのインストール先フォルダ内の program というフォルダを開きます。
> 例: C:\Program Files\OpenOffice.org1.1.3\program
> 2. 「crashrep.com」もしくは「crashrep.exe」を起動します。

機会があれば試してみます。

> 「Watch Dog Timer」(警備犬タイマーとでも訳すのかなぁ)という、ソフトウェアのアイデアが
> ありまして、簡単にいうと、
> 1. バケツに水がちょろちょろと注がれている。
> 2. プログラムが動作しているときは、何かの仕事が終わるたびに、そのバケツの水を空にする。
> 3. もしバケツの水がいっぱいになってしまったら、強制発動を行う。
> という仕掛けです。

単純なだけにちゃんと動きそうですね。

> SAMBAサーバーへのアクセスのピークと発症は、関係ないような印象ですね。
> 私もそう思います。たかだかPC数十台からのアクセスで Linux の SAMBA サーバーが
> 不安定な動作をするとは、考え難いです。

そうなんです。それでSS6.0の話を持ち出したのですが、
サーバーにインストールして40人弱で同時使用して遅いけれども
待っていればなんとか動いたという実績ですね。
今回書きながら、アクセスが多いときに問題が起こるのではなく
頻度が少ないのでたくさん動いていると問題を起こすクライアントに
出会う確率が増えるということかもしれないという思いに傾いてきました。

> 今度もし再発したら、生徒へ教えるということも兼ねて、クラッシュ・レポート
> (Error Report Tool)を使ってみてはどうでしょうか。
> 状況報告するテキストボックスにて、最初に Japanese! とでも書いていただければ、
> 本文は日本語で大丈夫です。簡単な状況説明を書いていただければ、OOo側のエンジニアが
> 解析します。もし、HTTP の Proxy サーバーを使われているのであれば、[オプション]
> ボタンを押して、その Proxy サーバーについての情報を入力してくださいね。

日本語でできるのなら気楽ですね。
インターネット接続はproxy経由で普段の授業中は
ブロックしてあるのでちょっと面倒かも。

--
安達 順一
adachi@xxxxx

--[PR]------------------------------------------------------------------
         ★☆★  「懸賞侍」見参!!  ★☆★
       侍ゲームで楽しく遊んで、豪華賞品を当てちゃおう!
            この戦国懸賞時代を制するのは君だ!
          さあ、バッサバッサと当ててしまえ!!!
      http://www.kenshosamurai.com/regist.html?aid=frml041227
------------------------------------------------------------------[PR]--
■GMO GROUP■ Global Media Online www.gmo.jp


投稿者 xml-rpc : 2005年1月16日 14:44
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/3968
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。