マニュアルを読み、ロックの数、ロッカー、データベースのページサイズなどを設定する方法を知っていますが、BDBの同時実行の実際の経験がある人からアドバイスをお願いします。
私のアプリケーションは非常にシンプルです。それぞれ約1KBのレコードの取得と書き込みを行います。カーソルも削除もありません。
構築しているアプリケーションの種類によって異なります。代表的なテストシナリオを作成し、ハンマーで叩き始めます。そうすれば、決定的な答えがわかります。
ユースケースに加えて、CPU、メモリ、フロントサイドバス、オペレーティングシステム、キャッシュ設定などにも依存します。
真剣に、あなた自身のシナリオをテストしてください。
いくつかの数字が必要な場合（実際にはシナリオでは何の意味もないかもしれません）：
テスト プログラムを作成し、データにアクセスする方法が、アプリケーションに期待されるパターンにできるだけ近いものであることを確認してください。アクセスパターンが異なればスループットも大きく異なるため、これは BDB では非常に重要です。
それ以外に、これらはスループットに大きな影響を与えることがわかった一般的な要因です。
アクセス方法（あなたの場合はBTREEだと思います）。
DBD を構成した永続性のレベル (たとえば、私の場合、「DB_TXN_WRITE_NOSYNC」環境フラグは書き込みパフォーマンスを桁違いに改善しましたが、永続性が損なわれます)
ワーキング セットはキャッシュに収まりますか?
読み取り数対。書いています。
アクセスがどの程度広がっているか (BTREE にはページ レベルのロックがあることを思い出してください。したがって、異なるスレッドで異なるページにアクセスすることは大きな利点です)。
アクセス パターン - スレッドが互いにロックしたり、デッドロックしたりする可能性と、デッドロック解決ポリシー (これは致命的である可能性があります) を意味します。
ハードウェア (キャッシュ用のディスクとメモリ)。
つまり、DBD に基づくソリューションをスケーリングして並行性を高めるには、2 つの主要な方法があります。デザインのロック数を最小限に抑えるか、ハードウェアを追加してください。
これは、ハードウェアやスレッド数などに依存しませんか?
簡単なテストを作成し、ハンマーで叩くスレッドの量を増やして実行し、最適と思われるものを確認します。
私の理解では、Sambaはtdbを作成して、特定のデータベースファイルに対して「複数の同時ライター」を許可しました。したがって、ワークロードに複数のライターがある場合、パフォーマンスが低下する可能性があります（たとえば、Sambaプロジェクトは、この場合のBerkeley DBのパフォーマンスに満足できなかったため、独自のシステムを作成することを選択しました）。
一方、ワークロードに多数のリーダーがある場合、問題は、オペレーティングシステムが複数のリーダーをどれだけうまく処理できるかということです。
未知のパフォーマンスのデータベースに対して作業を行ったときに行ったことは、クエリのターンアラウンド タイムを測定することでした。ターンアラウンド タイムが短くなるまでスレッド カウントを増やし続け、ターンアラウンド タイムが改善されるまでスレッド カウントを減らし続けました (まあ、それは私の環境のプロセスでした)。
移動平均やあらゆる種類の指標が関係していましたが、ここで得られた教訓は、現在の状況に適応することです。DBA がいつパフォーマンスを改善するか、ハードウェアがアップグレードされるか、実行中に別のプロセスがシステムをロードダウンするためにやってくるかはわかりません。だから適応する。
ああ、もう1つ：可能であればプロセスの切り替えを避けてください-物事をまとめてください。
はっきりさせておかなければなりませんが、これはすべて実行時に発生したものであり、開発中に発生したものではありません。