差分

このページの2つのバージョン間の差分を表示します。

--- it技術:データベース:postgresql:運用 [2021/01/21 00:12] – [work_mem] yajuadmin
+++ it技術:データベース:postgresql:運用 [2021/06/25 00:39] – [VACUUMとVACUUM FULL] yajuadmin
@@ 行 74: / 行 74: @@
 ^搭載メモリ^推奨値^
-|2GB|512MB|
+|2GB|512MB→1GB|
-|4GB|1GB|
+|4GB|1GB→2GB|
-|8GB|2GB|
+|8GB|2GB→4GB|
-|16GB|4GB|
+|16GB|4GB→8GB|
 ==== random_page_cost ====
@@ 行 133: / 行 133: @@
 pg_basebackup -U postgres -D "%bkPath%" -F t -x -z --checkpoint=fast
 </code>
+===== パフォーマンスチューニング =====
+[[https://www.fujitsu.com/jp/products/software/resources/feature-stories/postgres/article-index/tuningrule9-base/|パフォーマンスチューニング9つの技 ～「基盤」について～]]
+  - VACUUMで不要領域を再利用可能な状態にする
+  - REINDEXでインデックスの不要領域を削除する
+  - ANALYZEで統計情報を最新化する
+  - VACUUM FREEZEでトランザクションIDを凍結状態にする
 ===== データベース初期化 =====
 ==== 全てのデータベース初期化 ====
@@ 行 462: / 行 470: @@
 |約2400万件|6分|
-**VACUUM FULLを使うのではなく、pg_repackを使う。**
+**VACUUM FULLを使うのではなく、pg_repack(Windows版は非対応)を使う。**
+=== VACUUMの自動実行 ===
+デフォルトで自動的に行われる
+  * 統計情報の再計算 \\ 以下の計算式以上のレコードが更新（UPDATE/DELETE）されたテーブルは自動的に実行
+<code>
+autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * レコード数
+</code>
+  * パラメータはテーブル単位でも決定可能 \\ 大規模テーブルではテーブル単位に autovacuum_vacuum_scale_factor を 0 に \\ autovacuum_vacuum_threshold を適切な値に変更し、頻繁に VACUUM を実行することを推奨
 ==== AUTOVACUUM(自動実行) ====
@@ 行 560: / 行 577: @@
 ===== インデックスの再構築 =====
+PostgreSQL のインデックスサイズは一度大きくなると、その後小さくなるタイミングが限られています。
+  * DROP INDEX でテーブル自体を削除した場合
+  * TRUNCATE TABLE でテーブル全体を空にした場合
+  * REINDEX でインデックスを再構成した場合
+インデックスが肥大化した状況では実行計画のコスト計算に影響することがあります。これは適切な実行計画を選択する妨げとなるかもしれません。
+[[https://taityo-diary.hatenablog.jp/entry/2021/06/05/143617|PostgreSQL のインデックス肥大化と実行計画のコストへの影響]]
 ==== リインデックス ====
 reindexコマンドを使用して、インデックスの再構築する。\\
@@ 行 571: / 行 596: @@
 ==== テーブルロックなしのリインデックス ====
 reindexコマンドはテーブルロックがかかってしまうので、運用中のDBに対して使うのは難しい。\\
-ただ、PostgreSQLでは別名で全く同じインデックスの作成を行うことができる
+ただ、PostgreSQLでは別名で全く同じインデックスの作成を行うことができる。\\
+<wrap em>※PostgreSQL12からは、REINDEX CONCURRENTLY が導入され、REINDEX による重いロックなしでインデックスを再構築できます。</wrap>
   * [[http://cynipe.hateblo.jp/entry/2012/08/19/173230|PostgreSQLでテーブルロックせずにインデックスを再構築する方法]]
@@ 行 577: / 行 603: @@
   * [[https://tak-w.hatenadiary.org/entry/20111207/1323270854|index 再構築 Primary key]]
   * [[http://kashi.way-nifty.com/jalan/2014/04/postgresql-81a7.html|定期的なインデックス再作成を自動化]]
+  * [[https://qiita.com/mkyz08/items/eb66419d43c56cce566e|PostgreSQLのインデックス再編成]]
 <code bat>
@@ 行 643: / 行 670: @@
 |3|Z|マイナーバージョン番号|セキュリティバグやデータ破損の可能性のあるバグ等が修正された場合。\\ その他の軽微な修正も同時に行われる。|
-※10系から、PostgreSQL X.Zと二つの数字で表記に変更。最初がメジャーバージョン、新機能追加  最後がマイナーバージョン、バグフィックスなど
+※10系から、PostgreSQL X.Zと二つの数字で表記に変更。最初がメジャーバージョン：新機能追加、最後がマイナーバージョン：バグフィックスなど
 ==== マイナーアップデート ====
@@ 行 651: / 行 678: @@
 ==== メジャーアップデート ====
 メジャーアップデートでは、データのバックアップとリストアの作業が必要である。\\
-メジャーアップデート用ツールとして、[[https://www.postgresql.jp/document/9.6/html/pgupgrade.html|pg_upgrade]]がある。\\
+メジャーアップデート用ツールとして、[[https://www.postgresql.jp/document/9.6/html/pgupgrade.html|pg_upgrade]]がある。
-[[https://qiita.com/leon-joel/items/42eb018598052f8792af|pg_upgrade を使ったDBクラスタ移行手順 on Windows]]
+=== pg_upgrade ===
+  * [[https://qiita.com/leon-joel/items/42eb018598052f8792af|pg_upgrade を使ったDBクラスタ移行手順 on Windows]]
+  * [[https://tech-blog.rakus.co.jp/entry/20190829/postgresql|【PostgreSQL 9.4 → 11】pg_upgradeでデータベースクラスタをバージョンアップ]]
+  * [[https://www.ashisuto.co.jp/db_blog/article/201712-postgresql10-upgrade.html|PostgreSQL10へのアップグレード前に押さえておきたい3つの注意点]]
+  * [[https://se.ykysd.com/2019/06/18/pg-upgrade-96-108/|PostgreSQL9.6からPostgreSQL10にバージョンアップ]]