過去の桐井戸端ＢＢＳ　（桐ver.８）
20764 時々ネットワークで使えなくなるのはもしかしてoplockに原因があるのでしょうか 渡辺 2003/06/09-18:24
環境
　サーバー　 Windows2000Server(SP3)
　クライアント Windows2000Pro.(SP3)+WindowsMe+Windows98が混在
　桐V8SP6で構築したシステム
最大20台のクライアントが同時使用
　
現象
　1.あるクライアント(ここではAとします)で行訂正などレコード編集に関わる処理を実行すると一見フリーズしたようになり，
　他のユーザー(全員)も砂時計状態になる．２・３分経つとＡの画面に「他のユーザーが処理中です」とメッセージが表示され，
　その直後から他のユーザ(全員)の砂時計が消えて何事もなく使用できる．
　これが不定期に同時使用ユーザー数に拘わらず週に何度か起きる．

　2.同じく行訂正などレコード編集に関わる処理を実行中に
　「ロールバック領域があふれました」と表示され，処理ができなくなる．
　この場合は，全ユーザが(桐で構築した)システムを終了して再び開くと解決する．

昨年暮れに「ネットワークで桐を使うときのoplockの設定について」という話題がありましたが，
もしや，これらの原因はoplockに関わるのではと思って，情報を元にWindows2000ServerのCD-ROMからDSCLIENT.exeを
各クライアントにインストールしてみましたけど現象は収まりませんでした．

どうも共有管理情報ファイルのファイルアクセスで何か不具合が起きているのではないか，と睨んでいます．

なんとか問題を解決したいのですが，どなたかご教授いただければ幸いです．

20766 Re:もしかしてoplock hidetake 2003/06/09-20:51
記事番号20764へのコメント
Oplock に関しては少し前にも出ましたが，

もし，Oplock の可能性があるのならそれを無効にして見る事が第１の確認だと思います。

共有ファイルがオープンできなくなる
http://support.microsoft.com/default.aspx?scid=kb;ja;JP414348

Configuring Opportunistic Locking in Windows
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q296/2/64.ASP&NoWebContent=1


あとは取り敢えず桐の動作に関しての考察？

もし，既に何人かでテーブルを開いているのなら，
そのテーブル自体は Oplock は外れている状態だと思います。
供給管理情報に関しては，確かにファイルを操作するたびにコントロールされるものもあるようですが，
これは主に桐を起動したり，ファイルを開く瞬間(あるいは閉じる瞬間)にオープンされ閉じられるようです。
なお，Oplock 自体は特に9x系は過去を特に引きずるようですが・・・

で，ファイルが開かれた状態で共有に影響されるものは，そのテーブルファイルの .RSCファイルだと思われます。

で，面白いのは，これは確認しやすい Linuxで動きを見てみたのですが，
１台のパソコンで複数の桐を立ち上げ，ファイルを共有で開いた場合なのですが，
Windows2000(XP)ではテーブルファイルは複数開かれた状態になります。
なのにそれに対応する .RSC ファイルは１つだけ開かれた状態で，
複数の桐でデータを操作した状態でも，ず〜と Oplock がかかった状態のままです。
全く別のパソコンからアクセスがあると，.RSC ファイルのOplock は解除されます。

そして，Windows98 だと，１台のパソコンで桐を複数立ち上げて同じファイルを同時に開いても，
Linux 上では１つのテーブルが開かれた様子しか確認できません。
.RSC に関しては，2000 と一緒で開かれるのも１つで，複数で操作しても Oplock がかかったままなのも一緒です。

何か良くわからないですが，.RSC ファイルも，テーブルと同じように，
同じパソコン上であれ複数の桐でデータを捜査したら，
複数で制御されなくて良いのかとか？
Oplock は解除されなくて良いのかと疑問が残ります。

この辺は Windows でも確認すると何かの役に立つのかも？知れません。


何れにせよ問題があるのなら外してみるのが第１の確認だと思います。


20794 Re:もしかしてoplock hidetake 2003/06/10-21:53
記事番号20766へのコメント
>この辺は Windows でも確認すると何かの役
>に立つのかも？知れません。

別に Windows の方でも特に異なるような状況では無く，全く同じ動きのようです。


>現象
>　1.あるクライアント(ここではAとします)で行訂正などレコード編集に関わる
>　　処理を実行すると一見フリーズしたようになり，他のユーザー(全員)も
>　　砂時計状態になる．２・３分経つとＡの画面に「他のユーザーが処理中です」
>　　とメッセージが表示され，その直後から他のユーザ(全員)の砂時計が消えて
>　　何事もなく使用できる．これが不定期に同時使用ユーザー数に拘わらず
>　　週に何度か起きる．

「コンピュータの管理」の「開いているファイル」を常時表示させておき，
このような状態が発生した時に，どのようなロック状態であるのか？
F5 を叩いて，その時の動き(変化)を確認するもの何かの参考になるかも？知れません。

20806 Re:もしかしてoplock 渡辺 2003/06/11-18:54
記事番号20794へのコメント
hidetakeさん

早速のご教授ありがとうございます．しかも２通も！

ご紹介のリンクを一通り見てみました．
この手の情報はなかなか探せませんでしたので貴重な情報源です．

>そして，Windows98 だと，１台のパソコンで
>桐を複数立ち上げて同じファイルを同時に
>開いても，Linux 上では１つのテーブルが
>開かれた様子しか確認できません。.RSC に
>関しては，2000 と一緒で開かれるのも１つ
>で，複数で操作しても Oplock がかかったま
>まなのも一緒です。

ご存知でしたらお教えいただきたいことがあります．
何台かのPCにはDsclient.exeを実行しましたが，実行時にエラーでインストール出来ないPCがあったので，
このVREDIR.VXDを上書きコピーしてみました．
Windows9xでOplock対策の最新モジュールは，
Dsclient.exeを実行するとインストールされる VREDIR.VXD(日付99-11-30)だけでよろしいのでしょうか．

それと，ご紹介の記事に
>２．Oplock の使用を無効にする
>■クライアント側で対処する場合(あまり進められない)
> ・Windows9x系
> [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VREDIR]
> "DiscardCacheOnOpen"=string:00000001

とありましたけど，どんな代償が待っているのかお教えいただければ幸いです．


>「コンピュータの管理」の「開いているファイル」を常時表示させておき，
>このような状態が発生した時に，どのようなロック状態であるのか？　F5 を
>叩いて，その時の動き(変化)を確認するもの何かの参考になるかも？知れません。

ご提案ありがとうございます．調べてみます．

ところで，「開いているファイル」を見ていて何度か気付いたのですが，
あるユーザーファイルが既に閉じているのにいくつか表示が残っていて，
そのユーザーのWindowsを再起動したら消えた事がありました．

あの「開いているファイル」ってどうも正確な情報を表示していないような気がします．
サーバー側の問題だけでなくクライアントPCのWindowsにも
関係があるのでしょうか．．


20810 Re:もしかしてoplock hidetake 2003/06/11-21:21
記事番号20806へのコメント
>出来ないPCがあったので，このVREDIR.VXDを上書きコピーしてみました．
>Windows9xでOplock対策の最新モジュールは，
>Dsclient.exeを実行するとインストールされる VREDIR.VXD(日付99-11-30)
>だけでよろしいのでしょうか．

詳しくはわからないです。でも，ディレクトリサービスを使わないのなら，
そして VREDIR.VXD だけの上書きコピーで通常の使用で問題が無いのならそれで良いと思います。
しかし，これを入れても今回の件に関係は無かった(改善されなかった)というのであれば
Oplock に対しては効果は無いのかも知れません。

Microsfot の技術情報でもリダイレクタにバグはあるようですが，
新しくすれば改善できるような記述と先のロックに関しての情報ではサーバ側で
Oplock を無効にする必要があると，情報もいろいろあって，やってみてどうなるか？
改善されるのか？と言う事は，自分の環境で見てみないと
何とも言えないような状況のような気がします。


>>２．Oplock の使用を無効にする
>>■クライアント側で対処する場合(あまり進められない)
>> ・Windows9x系
>> [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VREDIR]
>> "DiscardCacheOnOpen"=string:00000001
>
>とありましたけど，どんな代償が待っているのかお教えいただければ幸いです．

これは全部のクライアントに全て設定する必要があるだろうし，
他のパソコンがこの対策を取らねば，いくら対策した
(Oplockを使わないように設定した)パソコンがあっても，
他からの Oplock の要求にうまくタイミング良く，
みんなが調整してくれるかという課題は残るだろうと思います。

サーバ側で設定すれば１発で済むものを，
わざわざ面倒な事にクライアントパソコン１台１台にしていく事も無いと思います。

それから Oplock を無効にすると言う事は，ネットワークのパフォーマンスは落ちると言う事もありますよね！


>ところで，「開いているファイル」を見ていて何度か気付いたのですが，
>あるユーザーファイルが既に閉じているのにいくつか表示が残っていて，
>そのユーザーのWindowsを再起動したら消えた事がありました．
>
>あの「開いているファイル」ってどうも正確な情報を表示していないような気がします．
>サーバー側の問題だけでなくクライアントPCのWindowsにも
>関係があるのでしょうか．．

詳しくはネットワークモニタで観察すべきものだと思います。
ただ，前にも書いたように 98系と NT系ではその動作が異なり，
98系はクライアントのアプリケーションがファイルを閉じてもリダイレクタは
Oplock をかけたままの状態が維持されるようです。
NT系は数秒で解除されます。
あるいはアプリケーションによっては Oplock を積極的に
制御しているものもあるようで，ファイルを閉じると同時に
Oplock を解除してくれるもアプリもあります。(Access等)


桐の場合は，ファイルが細かく独立しており，更に共有管理情報も
いくつものファイルに分かれ，そして更にファイルを開くにあたって，
多くの作業ファイルを作成します。

タダでさえ多くのファイルがあり，それが開け閉めされるのに，
それに加えて作業ファイルもいくつも別れ，それらのロックも行われるのですから，
もし Oplock系に問題があったり？
ネットワークが不安定であったりすると，これらの問題が発生しやすいのかも知れません。


桐自体に問題があるのか無いのまではわかりませんが，
もしOplock 等の障害を引き起こしやすいのなら，
桐側でも Oplockを積極的に制御して，これらの障害が出にくくしたり，
あるいは，障害の判定をしやすくするために Oplock を無効にするような？
デバッグオプションでも組み込んで貰った方が良いのかも知れません。


なお，これらに関しては私の推測ばかりですので，
実際に不具合が発生されている方で検証をお願いいたします。



20811 Re:もしかしてoplock hidetake 2003/06/11-22:05
記事番号20810へのコメント
>>>２．Oplock の使用を無効にする
>>>■クライアント側で対処する場合(あまり進められない)
>>> ・Windows9x系
>>> [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VREDIR]
>>> "DiscardCacheOnOpen"=string:00000001
>>
>>とありましたけど，どんな代償が待っているのかお教えいただければ幸いです．
>
>サーバ側で設定すれば１発で済むものを，わざわざ面倒な
>事にクライアントパソコン１台１台にしていく事も無いと
>思います。
>

現状では，あくまでも「もしかしてoplock」？な状態あるのでしょうから
最初に書いたとおり，Server 側で Oplock を無効にして，一定期間様子を見る事が第１だと私は思います。

もし，それで同じような現象が出るのでしたら Oplock の問題では無いでしょうし，
上のようなクライアント側で設定したところで何の効果も無い事になります。

もし，今まで週に１度は出ていたものが，ひと月も出なかったら，
おそらくOplock の絡みの問題であるのでしょう！
そうであるならば，チューニングを行い Server 側で，この現象の出にくい設定があるのかどうかを探り，
クライアント OS の問題も関わってくるようなら，
個別に 98系だけを Oplock を無効にしていく事も対策の１つとして考えられると思います。


関係ないかも知れないですけど，NIC のドライバ周りも疑ったり，
最新のものに更新してみたりする事も必要ではあると思います。


21228 ありがとうございました 渡辺 2003/07/02-14:24
記事番号20811へのコメント
出張などが続いてお返事がおくれて済みません．

hidetake様，ご教授いただきありがとうございました．

戻る