2

現在、100 個のテーブルを持つ Postgres データベースがあり、そのうち 20 個は 5,000,000 行を超えており、マスター DB サーバーは Debian 32MB RAM 8 プロセッサで実行されています。

マスター DB に加えて、Slony を使用して複製されたスレーブ DB があります。

私たちのアプリケーションは、SQL クエリに Java と Hibernate フレームワークを使用し、c3p0 を接続プールとして使用します。

私たちの問題は、現在、ピーク時に 30 前後、トラフィックが少ない時間に 4 前後の高負荷が予想されることです。現在、選択ステートメントのマスターとスレーブ間の負荷分散は使用していません。

Postgres マスター DB の構成は次のとおりです。

shared_buffers = 6144MB
temp_buffers = 16MB
max_prepared_transactions = 20
work_mem = 128MB
max_fsm_pages = 409800

自動バキュームがオンになっています。

c3p0 Hibernate 接続プールの構成は次のとおりです。

 <property name="c3p0.min_size">3</property>
 <property name="c3p0.max_size">200</property>
 <property name="c3p0.timeout">300</property>
 <property name="c3p0.max_statements">1000</property>
 <property name="c3p0.idle_test_period">300</property>

私たちが直面している大きな問題の 1 つは、select クエリが非常に複雑で、多数の結合や共用体さえあることです。

実際のシステムを調整、スケーリングし、高負荷を回避するためのソリューションは何ですか?

ハードウェアをアップグレードしますか? マスターとスレーブ間の負荷分散? 構成が悪い？

slony よりも優れた負荷分散レプリケーション システムに関する提案はありますか?

ソフトウェアを開発していないため、SQL ステートメントの最適化はできません。

4

2 に答える 2

2

Tuning Your PostgreSQL Serverという、調整する PostgreSQL パラメータの基本的な紹介があります。パフォーマンスに影響を与える最も重要な 2 つの要素に触れていません: 不適切な設定をするとクエリの計画が台無しになる effective_cache_size と、データベースから適切な書き込み速度を得るために値を上げなければならない checkpoint_segments です。複雑なクエリがある場合は、default_statistics_target も確認してください。また、難しいクエリをログに記録し、 Explainを使用して実行速度が遅い理由を調べることもできます。

于 2010-01-20T06:45:15.017 に答える
1

2PC を使用していない限り、max_prepared_transactions は 0 にする必要があります。

200 接続には work_mem が高すぎます。おそらく32Mb程度に落としたいと思うでしょう。これにより、スワッピングが発生し、パフォーマンスが壊滅的になる可能性があります。

とはいえ、最高のパフォーマンスを得るには、接続プールを << 200 接続に制限してください。おそらく50前後で最高のパフォーマンスが得られます。

FSMに関しては、それはアクセスパターンが何であるかに完全に依存します. 8.4 にアップグレードすると、その 1 つが自動調整されるため、それだけでもアップグレードする理由になる可能性があります (もちろん、他にもたくさんあります)。

システムについて多くのことを知らずに、それ以上のことを言うのはかなり難しい. 完全なパフォーマンス レビューを提供するために、PostgreSQL コンサルティング会社の 1 つを探すことをお勧めします。

一般に、このような小さなデータベースでは、適切にセットアップすれば、かなり優れたパフォーマンスを得ることができるはずです。

于 2010-01-19T10:33:58.970 に答える