0

Javaで書かれたアプリケーションのパフォーマンスに関連する一連の問題を研究しています。これは、 1 日あたり約100,000 のヒットがあり、カーディナリティが 2 つのプリンシパル データベース テーブル (均等に分割) で平均 5 ～ 10 回の読み取り/書き込みが行われます。100万から300万のレコードの両方に対して（休止状態を介してDBにアクセスします）。

私の 2 つのメイン テーブルには、ユーザー情報 (varchar、integer、timestamptz 型の約 60 列) と、表示されるデータにリンクされた別のテーブル (主に varchar、integer、timestamptz の約 30 列) が格納されます。

私が遭遇した主な問題は、サイトのパフォーマンスが低下した可能性があります (データベースのパフォーマンスだけに依存しない5 秒以上の時間負荷について話しましょう)、現在デフォルト値の 100であるFillFactorの使用です(データが変更されていない場合は常に使用されます..)。

明らかにフィルファクターはインデックス上で同じです（タイプbtreeの2つのテーブルごとに10あります）

現在、私が作成しているメインテーブルに

  • 40% 選択操作
  • 30% の更新操作
  • 20% 操作挿入
  • 10% の削除操作。

私のデータベースは、重要度の低い他の 40 のテーブルで構成されています (ユーザーのカーディナリティが同じ 3 つだけです)。

私の質問は次のとおりです。

  • 設定するフィルファクターの正しい値をどのように見つけますか?
  • この種のデータベースのパフォーマンスを改善するためにチェックすべきタスクのチェックリストはどれですか?

データベースはサーバー専用 (16 GB RAM、8 コア) にあり、ストレージは SSD ディスクにあります (データは終日バックアップされ、別のストレージに移動されます)

4

1 に答える 1

0

You have likely hit the "knee" of your memory usage where the entire index of the heavily used tables no longer fits in shared memory, so disk I/O is slowing it down. Confirm by checking if disk I/O is higher than normal. If so, try increasing shared memory (shared_buffers), or if that's already maxed, adjust the system shared memory size or add more system memory so you can bump it higher. You'll also probably have to start adjusting temp buffers, work memory and maintenance memory, and WAL parameters like checkpoint_segments, etc.

There are some perf tuning hints on PostgreSQL.org, and Google is your friend.

Edit: (to address the first comment) The first symptom of not-enough-memory is a big drop in performance, everything else being the same. Changing the table fill factor is not going to make a difference if you hit a knee in memory usage, if anything it will make it worse w.r.t. load times (which I assume means "db reads") because row information will be expanded across more pages on disk with blank space in each page thus more disk I/O is needed for table scans. But fill factor less than 100% can help with UPDATE operations, but I've found adjusting WAL parameters can compensate most of the time when using indexes (unless you've already optimized those). Bottom line, you need to profile all the heavy queries using EXPLAIN to see what will help. But at first glance, I'm pretty certain this is a memory issue even with the database on an SSD. We're talking a lot of random reads and random writes and a lot of SSDs actually get worse than HDDs after a lot of random small writes.

于 2014-02-15T10:44:28.573 に答える