巨大なページバッファと複数の同時プロセス
-
21-09-2019 - |
質問
お客様の1人には、平均アクティブ接続が約70〜80の35 GBのデータベースがあります。データベースの一部のテーブルには、テーブルごとに1000万以上のレコードがあります。
現在、彼らは新しいサーバーを購入しました:4 * 6コア= 24コアCPU、48 GB RAM、2 RAIDコントローラー256 MBキャッシュ、それぞれ8つのSAS 15K HDDがあります。
64ビットOS。
私は疑問に思っています、最速の構成は何でしょうか:
1)FB 2.5巨大なバッファーを備えたSuperServer 8192 * 3500000ページ= 29 GB
また
2)FB 2.5 1000ページの小さなバッファー付きクラシック。
たぶん誰かがそのようなケースを以前にテストしたことがあり、私に仕事の日を節約します:)
前もって感謝します。
解決
多くのプロセッサがあるので、私はクラシックから始めます。
しかし、すべてを試してください。
おそらく、スーパークラシックの2.5はあなたにとって素晴らしいことです。
他のヒント
これを必要とする人のために古いスレッドを掘り出すためだけです。
75GB dBでFB Classic 2.5を使用しています。これは、記載されているものとほぼ同じマシンです。
SuperServerはテスト中に非効率的でした。バッファとページサイズの変更により、パフォーマンスは少し惨めになりました。
現在、Xinetdを使用してClassicを使用しています。ページサイズ= 16384、ページバッファー= 5000、
SuperServerは、1つのProcesorのみを使用します。 24のコアがあるので、最良の選択肢はClasicを使用することです。 SuperClasicは、マルチプロセッサ環境でまだ十分にスケーリングする準備ができていません。
間違いなく「クラシック」アーキテクチャの1つを使用してください。
Firebird 2.5を使用している場合、 Superclassicをご覧ください.
私は現在、同様の要件を持っているクライアントを持っています。
そのケースの最良の解決策は、FireBirdSQL 2.5 SuperClassicをインストールし、デフォルトの小さなキャッシング設定を残すことでした。なぜなら、Free Memory(RAM)がある場合、WindowsとLinuxはデータベースのキャッシングを改善し、FireBirdが発生するからです。 Firebirdのキャッシング機能はそれほど高速ではないので、OSを実行させてください。
また、使用するバックアップソフトウェアに応じて、Firebird-Databaseの完全なバックアップを頻繁に作成する場合は、データベースに強制書き込みを無効にすることができます。 (自分が何をしているのかを知っていて、強制書面を非アクティブ化することによって何が起こるかを知っている場合は、それをしてください)。