システム管理
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

メッセージキューのデッドロック?

K_Oku
時折のコントリビューター

メッセージキューのデッドロック?

各計算機とソケットインターフェースを用いて、各計算機の監視・制御を行なうシステムを開発しています。

計算機(HP-UX)内に複数のプロセスを常駐させ、それらのプロセス間をメッセージキューを用いてシステムを

構築しておりますが、現在以下の事象がまれに発生している状況です。

・メッセージキューがデッドロックしているように見える。

処理のとまっているプロセスを見てみると。同じメッセージキューを

使用してる2つのプロセスにおいて、片方はmsgsnd()で止まっており

もう片方のプロセスはmsgrcv()で止まっているように見える。

・上記の現象は、OS内に常駐させる一連のプロセス起動時に発生することが多いが。

頻度で見ると、一連のプロセス起動を1回と数えると

50回から100回に1度という頻度で発生する。

但し、プロセス起動時以外に上記事象が発生することもある。

・上記の現象が一度発生すると、かりに関連するプロセスを

落とし、問題の発生したメッセージキューをipcrmにで消した

後でも同様の現象が発生する。この状況を回復するには

現状、計算機の再起動をする以外の方法しかない状態である。

・上記事象が発生したときに、デッドロックをおこしていると思われる

メッセージキューを「ipcs -ma」にて確認すると

msgsnd()待ちを示す「S」とmsgrcv()待ちと思われる「R」が

着いている

そこで、恐縮ですが、どなたか以下の質問にご解答いただけますでしょうか?

・この事象がどのような原因で発生しているか。

->アプリケーションのバグにより発生しうるかどうか?

->上記事象を引き起こしてしまうカーネルバグなどが過去に存在したか?

・OSの再起動以外で上記事象を解消する手段があるか?

なお、OS、計算機は以下の通りです

OS:HP-UX V2.0

CPU:Itarium2

宜しくお願い申し上げます。

1 件の返信
oops
貴重なコントリビューター

メッセージキューのデッドロック?

こういった状況の場合、ほとんどがリソース不足だと思います。

msg queue を多用されているようですが、関連するチューナブルパラメータはきちんとチューニングされているでしょうか?

事象発生時に ipcs -qa で該当する msg queue の状態を確認し、メッセージが存在するかどうか確認して下さい。もしメッセージが存在しなければ、msgrcv() がブロックされるのは仕様通りに動きです(ブロックされたくなければ IPC_NOWAIT を設定する必要があります)。

msgsnd() は msg queue が msg でいっぱいの場合にブロックされるイメージしかないかもしれませんが、送信するための msg に割り当てるためのヘッダが不足している場合もブロックされます(IPC_NOWAIT がたっていない場合)。

ヘッダの不足により msgsnd() がブロックされているかどうかについては、他の msg queue に多くの msg が queuing されている場合に本事象が発生するかどうかで確認が可能です。

queing された msg がなくなるか、msg が溜まった queue を削除することで事象が解消されるのであれば、問題はヘッダ不足と言えるでしょう。

チューナブルパラメータに msgtql というのがありますので、これを大きくして事象が回避できるかどうかを確認してみて下さい。

# kctune -v msgtql

Tunable msgtql

Description Maximum number of messages queued at any time

Module sysv_msg

Current Value 1024

Value at Next Boot 1024

Value at Last Boot 1024

Default Value 1024

Constraints msgtql >= 1

msgtql >= msgmap - 2

Can Change At Next Boot Only

msgtql(5) も参考にしてみて下さい。