- Community Home
- >
- HPE Community, Japan
- >
- HP-UX
- >
- System Management
- >
- メッセージキューのデッドロック?
system management
1822398
メンバー
2865
オンライン
109642
解決策
フォーラム
カテゴリ
Company
Local Language
戻る
フォーラム
ディスカッションボード
フォーラム
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
ディスカッションボード
フォーラム
ディスカッションボード
ディスカッションボード
ディスカッションボード
フォーラム
ディスカッションボード
戻る
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
ブログ
コミュニティ言語
言語
フォーラム
ブログ
トピックオプション
- RSS フィードを購読する
- トピックを新着としてマーク
- トピックを既読としてマーク
- このトピックを現在のユーザーにフロートします
- ブックマーク
- 購読
- 印刷用ページ
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
12-26-2007 04:09 PM
12-26-2007 04:09 PM
メッセージキューのデッドロック?
各計算機とソケットインターフェースを用いて、各計算機の監視・制御を行なうシステムを開発しています。
計算機(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
宜しくお願い申し上げます。
計算機(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件の返信1
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
12-28-2007 12:33 PM
12-28-2007 12:33 PM
メッセージキューのデッドロック?
こういった状況の場合、ほとんどがリソース不足だと思います。
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) も参考にしてみて下さい。
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) も参考にしてみて下さい。
上記の意見は、Hewlett Packard Enterpriseではなく、著者の個人的な意見です。 このサイトを使用することで、利用規約と参加規約に同意したことになります 。
企業情報
© Copyright 2025 Hewlett Packard Enterprise Development LP