PostgreSQLのCPU使用率を高く管理するにはどうすればよいですか？
PostgreSQLのCPU使用率が高い問題を修正しようとしています。 PostgreSQL 8.0.9を使用しており、JBossのJEE Webアプリケーションが特定の負荷増加条件で使用されている場合、topはPostgreSQLのプロセスの増加が遅いことを示しています。問題が発生すると、約12〜15のPostgreSQLプロセスがあり、すべてプロセス情報の右端にSELECTが表示され、それぞれ約6〜7％のCPU使用率があり、その後アプリが大幅に遅くなります。
JBossバージョン：JBoss（MX MicroKernel）4.0.3
オペレーティングシステム：CentOS Linux 5.5
カーネルおよびCPU：Linux 2.6.18-194.26.1.el5 on x86_64
プロセッサー情報：2 x Intel（R）Xeon（R）CPU E5420 @ 2.50GHz、8コア
現在、私たちの考えは、より多くのハードウェアを投入することです。これを行う場合、最良のオプションは以下のオプションAまたはオプションBのようなものでしょうか？
オプションA：4つのAMD Opteron™6100シリーズプロセッサ（それぞれ12コア）
オプションB：インテル®Xeon®7500シリーズプロセッサーx 4、それぞれ8コア
CentOS Linux 5.5とPostgreSQL 8.0.9は、これだけ多くのプロセッサとコアを追加することで比例してスケーリングすると想定するのは正しいですか（例：コアがそれぞれ4つのプロセッサ）。さらに多くのハードウェアを投入することに関して、他に考慮すべきことはありますか？
質問に答えることは不可能です、私たちは何が起こっているのか分かりません。あなたは12-15接続について話している、それはほとんど何もない。ただし、非常に複雑なクエリを実行したり、不良なデータベーススキーマを使用したり、インデックスが不足したりすると、CPU使用率がいつでも上昇する可能性があります。
バージョン8.0.9は深刻な問題であり、8.0は2010年10月の時点でEOLであり、最新の修正はバージョン8.0.26（8.0.9以降の4年間のバグ修正）です。 8.0の多くのバグを修正するには、少なくともこのバージョンに更新する必要があります。
クエリのロギングを開始し、EXPLAINを使用してクエリプランを確認し、VACUUMを確認します。REINDEXも必要になる場合があります。今のところハードウェアは正常に見えますが、最初に問題の原因を見つける必要があります。
数日間、PostgreSQL dbaを雇うことを検討してください。
CPU使用率が高い場合は、クエリが遅いことが原因である可能性があります。 postmaster.confのスロークエリロギング機能を有効にし、必要以上に時間がかかるクエリをチェックすることをお勧めします。
また、ディスクが遅いとクエリのバックアップが簡単に開始されるため、I/Oバインドされている可能性もあります。 htopをインストールし、CPU待機時間の何パーセントがiowaitに起因するかを確認することをお勧めします。
それとは別に、最新バージョンにアップグレードすることを強くお勧めします。 8.0以降、パフォーマンスが大幅に改善されており、現在の安定バージョン（執筆時点では9.0.x）では、クエリをEXPLAIN VERBOSE ANALYZEingするときに詳細情報が提供されます。
一般的に言えば（そして他のすべての条件が等しい場合）、PostgreSQLはコアを追加するときに非常に適切にスケーリングします（追加のコアごとに、パフォーマンスが約96％向上します（追加のコアごとに可能な理論的な100％のパフォーマンス向上のうち））。
しかし、私の最初の直感は、ディスクが追いつくことができないということです。
私はあなたが本 PostgreSQL 9.0 High Performance から利益を得ると思います。 PDF（インスタントダウンロード）とデッドツリー形式で利用できます。
この本のアドバイスを使用して、データベースを再構築しました。私たちの新しいデータベースボックスは古いものを吹き飛ばし、それを行うために大量のお金を費やす必要はありませんでした。それぞれの質問に具体的に対処する章があります。答えはありますが、さらに良い方法もあります（ハードウェアを測定して、それがどれだけ速いかを知るにはどうすればよいですか？）
私はPostgresqlの専門家ではありませんが、ハードウェアとPostgresqlについて学んだことをお話しします。あなたのマイレージは異なる場合があります。
一般に、私が経験したデータベースの場合、CPUの数と速度以外に重要なのは次のとおりです。
- 適切なRAM。データベースはwinoが腐った飲み物のように記憶を飲みます。
- I/O帯域幅。データベースはI/Oを愛しています。
RAIDでI/O帯域幅を利用できます。 RAID10は、Postgresqlデータの大部分に適しています。ドライブが多いほど、パフォーマンスは向上します。可能であれば、xlogを別のデバイスに置きます。これはRAID1にすることができます。バッテリバックアップ式キャッシュを備えたハードウェアRAIDカードを使用すると、最高のパフォーマンスが得られます。
最近、クエリに多数の結合がある小さなデータベース（7テーブル、30 MB）で同様の問題が発生しています。マシンはVM 2GBの場合RAMで、常に160MB未満しか使用していないようです。約1Mの新しいデータを追加するまで、非常に高速に動作しました。 。その後、サーバー（8.4.5）は、1秒未満であった同じクエリで5秒から30分の間にCPUの100％にヒットし始めました。
サーバーのアップグレードによって問題を解決することができました。 8.4.9および8.4.12のテストでは、悪い動作は示されませんでした（ただし8.4.8は示されました）。
問題が発生すると、約12〜15のPostgreSQLプロセスがあり、すべてプロセス情報の右端にSELECTが表示され、それぞれ約6〜7％のCPU使用率があり、その後アプリが大幅に遅くなります。
12x6 = 72％なので、最低点でも、CPUはかなりビジーです。他のすべてのものを投入してください、そしてあなたがフラットアウトを実行している理由はかなり明らかです。 （これは、CPUを総計として見ていることを前提としています。topでプロセス時間を見るとき、1キーを使用して、個々のCPU時間をすべて表示するか、それが示す数値（すべてのCPUを組み合わせたもの）を確認します。）
現在、私たちの考えは、より多くのハードウェアを投入することです。これを行う場合、最良のオプションは以下のオプションAまたはオプションBのようなものでしょうか？
オプションA：それぞれ12コアのAMD Opteron™6100シリーズプロセッサx 4
オプションB：それぞれ8コアのIntel®Xeon®7500シリーズプロセッサーx 4
より多くのコア。 PostgreSQLはコアあたりのプロセスモデルを使用するため、多いほど良いです。私は多分2x AMD CPUをそれぞれ12で24コア合計で見て、それから残りの2 CPUを購入して、予算を組むことができます。
CentOS Linux 5.5とPostgreSQL 8.0.9は、これだけ多くのプロセッサとコアを追加することで比例してスケーリングすると想定するのは正しいですか（例：コアがそれぞれ4つのプロセッサ）。
はい。私は誤解しているかもしれませんが、古いカーネルコンパイルではCヘッダーファイルの固定数を使用して、検索するCPUの最大数を決定していました。通常、コンパイル時に上限が32でした。もしあなたが「大きな」マシンを持っているなら、あなたはその数値をより高いものにぶつけて、再コンパイルするでしょう。完全に定かではありませんが、2.6シリーズではその定数が削除されているので、問題ないはずです。
さらに多くのハードウェアを投入することに関して、他に考慮すべきことはありますか？
ソフトウェアをチューニングする前に、ハードウェアを投入する前に（またはチューニングして新しいハードウェアを入手する前に）ソフトウェアを確認することをお勧めします。
SELECTステートメントの場合、ログに記録してからEXPLAINを使用して、時間を費やしている場所を特定できますか？ PgAdminを使用して、クエリの実行とチューニングを手動で実行し、実行時間を少し短縮できます。 SELECTステートメントがプログラムを使用している場合でも、新しいインデックスを使用した場合の影響を確認できます。
どのくらいのメモリをPostgreSQLに割り当てましたか？プロセスごとにいくらですか？どのくらいの共有メモリが割り当てられていますか？これらはすべて、データベースの実行方法に悪影響を及ぼす可能性があります。
（メモリを解放するために）無効にしたり（CPU消費を減らすために）再接続したりできる他のプロセスやサービスはありますか？