データベースの動作が遅い

この問題の典型的な症状は以下の通りです：

• ディスクI/O（入力/出力）またはメモリ使用率が高い
• 速度が遅い照会

最も一般的な原因は、遅いクエリが調査されていることです。 以下の手順を完了し、これが該当するかどうかを確認してください：

1. 長時間実行中のクエリを一覧表示する:

   select age(now(),query_start), pid, client_addr, state, substring(query,0,80) from pg_stat_activity where state != 'idle' order by 1 desc;
   

2. クエリのブロックを検証する:

   select pg_blocking_pids(pid), pid AS blocked_pid, state, query, age(now(),query_start) AS duration from pg_stat_activity where array_length(pg_blocking_pids(pid),1) > 0 order by 1,2;
   

3. クエリの実行プランを確認してください：

   Explain <query>;
   

4. データベース統計情報が欠落していないか確認してください。 以下のクエリを使用して検証します: アクション > 分析の実行 または、次のコマンドを実行します:

   Analyze <tablename>  select relname, n_live_tup, n_dead_tup, last_vacuum,last_autovacuum,last_analyze,last_autoanalyze, analyze_count,autoanalyze_count from pg_stat_all_tables where schemaname='public';
   

5. テーブルからインデックスが欠落していないか確認する。 PostgreSQL B-Tree、ハッシュ、 SP-GiST,GiST, GIN、BRINなどのインデックス手法を提供します。 インデックスを作成するには、以下のいずれかの方法を使用する。

6. テーブルが肥大化していないか確認する。 以下のクエリを実行して検証してください。 アクション > 掃除機をかける

   代わりに、次のステートメントを使用してください：

   SELECT
   relname AS table_name,
   pg_size_pretty(pg_relation_size(c.oid)) AS actual_size,
   pg_size_pretty(
   CASE
   WHEN c.relpages = 0 THEN 0
   ELSE (pg_relation_size(c.oid) - (c.relpages *
   (current_setting('block_size')::numeric - 24))) * 100 / pg_relation_size(c.oid)
   END
   ) AS bloat_percentage, pg_size_pretty(
   CASE
   WHEN c.relpages = 0 THEN 0
   ELSE (pg_relation_size(c.oid) - (c.relpages *
   (current_setting('block_size')::numeric - 24)))
   END
   )AS bloat_size
   FROM pg_class c
   LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
   WHERE relkind = 'r' AND n.nspname = 'public' -- Adjust schema if needed
   ORDER BY bloat_size DESC NULLS LAST;
   

7. データベースまたはオブジェクトが CREATE または INSERT pg_dump で作成された pg_restoreかどうかを検討してください。 更新するには 、アクション＞統計の更新を選択してください。

8. クエリがソート操作を完了する場合、十分な work_mem メモリが割り当てられていることを確認してください。

9. 以下の情報を調べるためにステートメント pg_stat を使用してください：

   • クエリの平均実行時間と実行回数を取得する

   • クエリごとのCPU使用率

   • クエリによるメモリ使用率

pg_stat_activity, pg_stat_bgwriter, および pg_buffercache は、データベースのパフォーマンスを監視し理解するための PostgreSQL 重要なツールです。

デプロイメント監視とデータベース負荷監視

Databases for PostgreSQL サービスとの統合を提供します。 IBM Cloud Monitoring サービスとの統合を提供し、デプロイメントのリソース使用状況を監視します。 このサービスを使用して、デプロイメント（ディスクとメモリ）とデータベース負荷を監視してください。

ダッシュボード Cloud Databases を使用して、CPU、メモリ、ディスクのIOPSしきい値に対するアラートを設定します。 ディスク使用量や IOPS など、利用可能なメトリクスの多くは、デプロイで オートスケーリン グを 設定するのに役立ちます。 オートスケーリングはデフォルトでは有効になっていないため、手動で設定する必要があります。

使用量の傾向を観察し、その傾向に対応するようにオートスケーリングを設定することで、リソースが枯渇してデータベースが不安定になる前に、パフォーマンスの問題を軽減することができます。 例えば、ディスクI/OやCPU、メモリ障害の変化がパフォーマンス問題を引き起こす場合など。

ディスク IOPS

1秒あたりの入出力操作数（IOPS）は、ストレージボリュームの種類とサイズによって制限される。 デプロイメント Databases for PostgreSQL のストレージボリュームは、10 IOPS/GBティアの Endurance Block Storage ボリューム 上でプロビジョニングされます。

運用負荷が飽和したり、IOPSの上限を超えたりすると、ストレージサブシステムが追いつくまで、データベースのリクエストと操作は遅延する。 高負荷が長期間続くと、配置がクエリを処理できなくなり、事実上利用できなくなる可能性があります。 ディスクサイズを大きくすることで、配備で利用可能な IOPS 数を増やすことができます。 たとえば、10 IOPS/GBの階層の場合、ボリュームサイズを大きくすることでIOPSを増やすことができます。

ディスク使用率が40～50%に及ぶ状態が長期間続くと、データベースのパフォーマンスに重大な悪影響を及ぼす可能性があります。 本番環境には少なくとも100GBのディスク（1,000IOPS）を割り当てます。 IOPS = 割り当てられたGB × 10（例：100 GB = 1,000 IOPS）

メモリー使用率

メモリは、データにアクセスし処理する最も高速かつ効率的な方法である。 このため、データベースはディスクからデータを読み込むよりもメモリを使用する方が、ほぼ常に高速に動作します。 キャッシュヒット数、読み取りブロック数、ヒットブロック数など、検討すべき他の指標も存在する。 メモリ使用率が100%であること自体は、それ自体で懸念すべき事由とはならない。 メモリが枯渇しスワップページが使用されると、パフォーマンスが大幅に低下する可能性があります。

Databases for PostgreSQL、 shared_buffersを 調整することで、データベースの共有バッファプール専用のメモリ量を設定することができます。 推奨される最大値は、配備の総メモリの 25%です。 共有バッファ・プールにあまりに多くのメモリを割り当てると、他の目的のためにシステムのメモリが不足したり、パフォーマンスが低下したり、場合によってはデータベースが使用不能になったりします。

データベース負荷監視

データベースの負荷を確認するには、次の2つの方法があります：

{

source logs|filter message.attr.durationMillis>=1000

}

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT username, database, queryid, query_preview, calls, total_exec_time, pct_exec_time, ROUND(SUM(pct_exec_time) OVER (ORDER BY total_exec_time DESC)) AS cum_pct_exec_time, avg_exec_time FROM ( SELECT pu.usename AS username, pd.datname AS database, pss.queryid, LEFT(pss.query, 50) AS query_preview, pss.calls, ROUND(pss.total_exec_time::numeric, 3) AS total_exec_time, ROUND((100.0 * pss.total_exec_time / SUM(pss.total_exec_time) OVER ())::numeric, 2) AS pct_exec_time, ROUND(pss.mean_exec_time::numeric, 3) AS avg_exec_time FROM pg_stat_statements pss JOIN pg_user pu ON pss.userid = pu.usesysid JOIN pg_database pd ON pss.dbid = pd.oid ) AS subquery ORDER BY total_exec_time DESC LIMIT 25;

SELECT
   username,
   database,
   queryid,
   query_preview,
   calls,
   pct_calls,
   ROUND(SUM(pct_calls) OVER (ORDER BY calls DESC)) AS cum_pct_calls,
   total_exec_time,
   avg_exec_time
FROM (
   SELECT
      pu.usename AS username,
      pd.datname AS database,
      pss.queryid,
      LEFT(pss.query, 50) AS query_preview,
      pss.calls,
      ROUND(100.0 * pss.calls / SUM(pss.calls) OVER (), 2) AS pct_calls,
      ROUND(pss.total_exec_time::numeric, 3) AS total_exec_time,
      ROUND(pss.mean_exec_time::numeric, 3) AS avg_exec_time
   FROM
      pg_stat_statements pss
      JOIN pg_user pu ON pss.userid = pu.usesysid
      JOIN pg_database pd ON pss.dbid = pd.oid
) AS subquery
ORDER BY
   calls DESC
LIMIT 25;

SELECT query, calls, total_exec_time/calls as avg_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

パフォーマンスを向上させるために追加で実行できるアクション

パフォーマンスのトラブルシューティングには、以下のアクションも検討できます：

• 遅いクエリを最適化する

  • 遅いクエリに対してEXPLAIN (ANALYZE, BUFFERS)を実行する。 これは、データベースがどのようにクエリーを実行し、どこが遅いかを示している。 以下に例を示します。

  EXPLAIN (ANALYZE, BUFFERS)
  SELECT * FROM student WHERE student_id = 12345;
  

  • 以下を探してください。

    • メモリやディスク容量を大量に消費するクエリ

    • 必要に応じてリソース IBM Cloud を追加する

    • ディスク/メモリをスケールアップして、より高いIOPSとメモリを実現する

• インデックスの欠如または非効率性は、クエリの遅延の一般的な原因です。 EXPLAINを使用してシーケンシャルスキャンを特定し、インデックスの追加を検討してください。

• データベースの健全性分析を支援するためにVACUUMを実行してください。

• Databases for PostgreSQL は、 Databases for PostgreSQL データベースへの最大接続数を 115 に設定します。 15個の接続はデータベースの状態と整合性を維持するためにスーパーユーザー用に予約され、100個の接続はあなたとあなたのアプリケーションのために利用可能です。 接続制限に達した後、新しい接続を開始しようとするとエラーになる。 接続が原因でデプロイメントが過負荷になることを防止するには、接続プーリングを使用するか、デプロイメントをスケーリングして接続制限を引き上げてください。 詳細については、 「接続プーリング PostgreSQL の管理」 を参照してください。

• バックアップやデータのバッチアップロードを実行しているレシピがないか確認してください。例： 自動バックアップは毎日実行され、30日間のシンプルな保持スケジュールで管理されます。 バックアップが停止している場合、データベースインスタンスのクラウドUIページで「 利用可能なバックアップ 」セクションを確認し、停止したバックアップを特定できます。

• メンテナンスに関する通知 IBM Cloud を確認してください。 例えば、データベースのパッチ適用。

• これがメンテナンスなどのプラットフォームの問題であると思われる場合は、データベースのCRNを添えてサポート IBM までご連絡ください。