キャパシティプランニングと肥大化監査
ディスクとIOPSの増加を予測し、テーブルとインデックスの肥大化を定期的に監査して、容量不足になる前にアップグレードを計画します。
「キャパシティプランニングと肥大化監査」はCoddyKit上の無料SQL Academyレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSQL Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 SQL Academyコースには全4レッスンが含まれています。
予測する対象
今後6〜12か月に向けてデータベースのサイズを決めるには、次の項目を予測する必要があります:
- ディスク使用量(データ + WAL + インデックス)
- IOPSの需要
- RAMのワーキングセット
- 接続数
ディスクの増加
最近の増加傾向を確認します:
SELECT pg_size_pretty(pg_database_size(current_database()));
SELECT pg_size_pretty(pg_total_relation_size(t.oid)) AS total,
relname
FROM pg_class t
WHERE relkind = 'r'
ORDER BY pg_total_relation_size(t.oid) DESC LIMIT 20;テーブルごとの増加を追跡する
メトリクスを記録するジョブをスケジュールし、グラフ化します:
INSERT INTO size_history (ts, tablename, size_bytes)
SELECT NOW(), relname, pg_total_relation_size(oid)
FROM pg_class WHERE relkind = 'r';IOPSの推定
読み取りI/Oが多いテーブルはpg_stat_user_tablesで確認できます:
SELECT relname, seq_tup_read, idx_tup_fetch,
seq_tup_read + idx_tup_fetch AS total_reads
FROM pg_stat_user_tables
ORDER BY total_reads DESC LIMIT 20;RAMのサイズ設定
shared_buffersはRAMの約25%です。effective_cache_sizeは約75%です(プランナーへのヒントであり、割り当てではありません)。work_memに接続数を掛けた値は、使用可能なRAMを超えないようにしてください。
Bloatの監査
dead rowが最も多いテーブルを見つけます:
SELECT relname,
n_live_tup,
n_dead_tup,
round(n_dead_tup::numeric / NULLIF(n_live_tup, 0), 2) AS dead_ratio,
last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;インデックスのBloat
pgstattupleまたは組み込みツールを使用します:
CREATE EXTENSION pgstattuple;
SELECT relname,
pg_size_pretty(pg_relation_size(indexrelid)) AS size,
(pgstatindex(indexrelid::regclass)).leaf_fragmentation
FROM pg_stat_user_indexes
ORDER BY pg_relation_size(indexrelid) DESC LIMIT 20;未使用のインデックス
見つけて削除してください。書き込みコストが発生します:
SELECT schemaname, relname, indexrelname,
pg_size_pretty(pg_relation_size(indexrelid))
FROM pg_stat_user_indexes
WHERE idx_scan = 0
AND indexrelname NOT LIKE '%_pkey'
ORDER BY pg_relation_size(indexrelid) DESC;接続の監査
接続中のクライアント数と、その状態を確認します:
SELECT datname, usename, application_name, state, COUNT(*)
FROM pg_stat_activity
GROUP BY 1,2,3,4 ORDER BY 5 DESC;長時間のトランザクション
バキュームが停滞する原因です:
SELECT pid, state, xact_start, NOW() - xact_start AS xact_age, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_age DESC NULLS LAST LIMIT 20;WALとアーカイブ
アーカイブストレージのサイズを決めるため、WALの生成速度を監視します:
SELECT pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0')) AS total_wal_generated;フェイルオーバーに備える
レプリカのディスク容量はプライマリと同じにしてください。レプリカの追随速度がプライマリの書き込み速度以上であることを確認してください。
まとめ
キャパシティプランニングとは、適切なメトリクスをグラフ化することです。
- テーブルごとのサイズ増加
- dead rowの割合
- 未使用のインデックス
- バキュームをブロックする長時間のトランザクション
- 接続数
確認問題
バキュームの計画でdead rowが最も多いテーブルを見つけるには、どのビューをクエリすればよいでしょうか。
よくある質問
「キャパシティプランニングと肥大化監査」レッスンは無料ですか?
はい。「キャパシティプランニングと肥大化監査」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、SQL Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 SQL Academyコースには全4レッスンが含まれています。
「キャパシティプランニングと肥大化監査」で何を学びますか?
ディスクとIOPSの増加を予測し、テーブルとインデックスの肥大化を定期的に監査して、容量不足になる前にアップグレードを計画します。 ブラウザで直接実行するハンズオンコードでSQL Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
SQL Academyを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのSQL Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「キャパシティプランニングと肥大化監査」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このSQL Academyレッスンでコードを書いて実行できますか?
はい。すべてのSQL Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- pg_stat_statements:上位クエリ
- ログ分析のためのpgBadger
- コネクションプーリング:PgBouncer
- キャパシティプランニングと肥大化監査