1

特定のスレッド内の特定のトランザクションのデッドロックを特定するための最良の方法を探している開発者。デッドロック エラーが発生していますが、これらは FB 2.0 では非常に一般的です

デッドロックが発生し、クライアントと DB 間の DB 接続が切断されます。

  • ライブ (1 秒に 1 回) データを DB に送信します。
  • 約 30 スレッドのスレッド プールを開き、それらを使用してデータを取り込みます (毎秒約 1 ～ 2 kB)。
  • ストリームを可能な限り最新の状態に保つためにプール内の次のスレッドを使用するほど、DB が処理できる量が限られる場合があります。

これにより、最大スレッド数に達して接続が切断されるだけでなく、デッドロックが発生する場合があります。

したがって、これが毎秒この量のデータを取り込むための最良の方法であるかどうかについて、本当に意見が必要です. これらのクライアントでは、最大 100 のクライアントが同時に DB にヒットしています。
平均的なトランザクションは、1 日あたり約 150 万から 180 万です。

4

3 に答える 3

1

特定のスレッドまたはステートメントを識別する特定の方法がわかりません。私はFBのデッドロックに何度も対処しなければなりませんでした。おそらく、あるテーブルの同じ行を更新しようとしている2つのtheadがありますが、それらは別々のトランザクションで更新しています。

私が見つけた最善の解決策は、他のスレッドが更新する可能性のある行をスレッドが更新する必要がないように設計することです。これは、共通のテーブル/行を更新するためだけに存在するスレッドを持つことを意味する場合があります。ワーカースレッドはこのスレッドにメッセージを送信します。（メッセージは別のテーブルを介して実行できます。）

トランザクション（1日あたり数百万ではない）を生成するフィールドの多くのシステムでFBを実行しており、設計が正しくなると、FBは堅実であることがわかりました。

于 2008-09-15T13:48:26.903 に答える
1

Firebird 2.1 には、テーブル、接続、およびトランザクションの新しい監視機能があります。これが役立つ可能性があります (アップグレードできる場合)。README.monitoring_tables.txt を参照してください。

例、アクティブなステートメントを取得します。

SELECT ATT.MON$USER, ATT.MON$REMOTE_ADDRESS, STMT.MON$SQL_TEXT, STMT.MON$TIMESTAMP
FROM MON$ATTACHMENTS ATT 
JOIN MON$STATEMENTS STMT ON ATT.MON$ATTACHMENT_ID = STMT.MON$ATTACHMENT_ID
WHERE ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION AND STMT.MON$STATE = 1
于 2008-09-15T14:41:41.953 に答える
-1

私の提案は、3層アプリケーションを作成し、データベースへのすべてのアクセス（挿入）を単一のスレッドにシリアル化し（他のスレッドはキューにデータを積み重ねるだけです）、組み込みのFirebirdを使用することです（TCP/ IP オーバーヘッド)。

このアプローチでは、デッドロックを回避するだけでなく、キューを監視して、システムが負荷にどのように対処できるかを確認することもできます。

于 2008-09-29T17:13:17.180 に答える