私はマニュアルを読んで、ロックの数を設定する方法を知って、ロッカー、データベースのページサイズなどが、私はちょうどBDBの並行処理で、実世界での経験を持っている人からのいくつかのアドバイスたいと思いました。BerkeleyDB同時実行
私のアプリケーションはかなりシンプルですが、私は約1KBのレコードを取得して配置します。カーソルも削除もありません。
これはハードウェアやスレッド数などに依存しませんか？
私は簡単なテストを行い、スレッドハンマーの量を増やして実行し、最もよく見えるものを見ます。
これは、作成するアプリケーションの種類によって異なります。代表的なテストシナリオを作成し、ハンマーを叩き始める。それであなたは決定的な答えを知るでしょう。
CPU、メモリ、フロントサイドバス、オペレーティングシステム、キャッシュ設定などにも依存します。
あなた自身のシナリオを真剣にテストしてください。
あなたには、いくつかの数字（実際には、あなたのシナリオでは何も意味しないこと）が必要な場合：不明なパフォーマンスのデータベースに対して作業することにしたときに私が何をしたか
をクエリのターンアラウンドタイムを測定します。私はターンアラウンドタイムが落ちるまでスレッドカウントを上げ続け、ターンアラウンドタイムが改善するまでスレッドカウントを落としました（まあ、私の環境ではプロセスでしたが）。
移動平均とあらゆる種類の指標が含まれていましたが、離陸の教訓は、現時点での状況の変化に適応しています。 DBAがパフォーマンスを向上させるか、ハードウェアがアップグレードされるかはわかりません。また、実行中に別のプロセスがシステムをロードすることもあります。だから適応する。
もう1つ：プロセススイッチを避けることができれば、バッチ処理が可能です。
ああ、私はこれを明確にする必要があります。これは、すべての実行時ではなく、開発中に起こりました。
私が物事を理解する方法として、Sambaはtdbを作成して、特定のデータベースファイルに対して "複数の同時投稿者"を許可しました。したがって、あなたのワークロードが複数のライターを持っている場合、パフォーマンスは悪くなるかもしれません（この場合、Sambaプロジェクトは独自のシステムを作成することを選択しました。
一方、作業負荷に多数の読者がある場合は、オペレーティングシステムが複数の読者をどれくらいうまく処理できるかが問題です。
私はDaanの点に強く同意します。テストプログラムを作成し、アプリケーションが期待するパターンに可能な限り近い形でデータにアクセスする方法を確認します。異なるアクセスパターンが非常に異なるスループットをもたらすため、これはBDBにとって非常に重要です。それ以外
、これらは私がスループットに大きな影響のあることが判明し、一般的な要因である：（あなたのケースで、私はBTREEですね）
アクセス方法。あなたはDBDを構成していると持続性の
レベル（例えば、私の場合には「DB_TXN_WRITE_NOSYNC」環境フラグは、大きさの順に書き込み性能を改善したが、それは持続性が損なわれる）
がワーキングセットにフィットしていキャッシュに？
読み取り回数書きます。
どのようにアクセスが広がっているのですか（BTREEにはページレベルのロックが設定されているため、異なるスレッドで異なるページにアクセスすることが大きな利点です）。
アクセスパターン - スレッドが互いにロックする可能性があり、デッドロックされる可能性があり、デッドロック解決ポリシー（これはキラーかもしれません）は何ですか？
ハードウェア（キャッシュ用メモリ&メモリ）。
これは、次の点にのぼる： が、それは大きな並行性を提供していますように、DBDに基づくソリューションをスケーリングそれについて行くの二つの重要な方法があります。デザインのロック数を最小限に抑えるか、ハードウェアを追加してください。
後者の論文では、並行性の影響はテストされていないことも明示されています。 – nponeccop