Cloud SQL for PostgreSQL のリソース管理のベストプラクティス関連ドキュメントを読む
Taichi Masuyama読むもの
Taichi MasuyamaMetrics Explorer でメモリ使用率を見て、高いやついたら Query insights で計画を見てメモリ使う計画ノードがあったらそれ改善してね。
多くのメモリを使用する一般的な PostgreSQL スキャン方式には、次のものがあります。
- ビットマップ ヒープ スキャン
- クイックソート
- ハッシュ結合またはハッシュ
Gemini in Databases を使うと "メモリ不足（OOM）エラーが発生してデータベースのダウンタイムが発生する代わりに、メモリ使用量が高いクエリを実行している接続が終了し、データベースのダウンタイムを回避できます" !?
そんなことができるのか。やらない手はないレベルに嬉しくないか。
OOM されないようにコネクション数 x work_mem を意識して work_mem を設定してね。
work_mem が大きいとメモリを使った高速な計算ができる分 OOM のリスクが上がるよ(例えばクイックソートはメモリを使う)。OOM されるくらいならたまにはディスク使ってね。
セッション レベルで work_mem を設定することもできるよ。
work_mem に十分にメモリ領域確保できてないなら shared_buffers を調整してね。
キャッシュヒットが 95%~ になってるのが理想だよ。
huge_pages の話は知識不足でよくわからず (なんかデフォルトで使われててパフォーマンスよくなります的な感じらしい)
max_locks_per_transaction (同時にロックできるデータベースオブジェクトの数) は基本デフォルトの64でいいけどこれが原因で OOM 起きるなら大きくしてね。けどでかくしすぎてもだめだよ (よくわからず。この記事を見た感じ、多分めっちゃテーブル増えて問題が起きてから考えれば問題なさそう)
Taichi Masuyama
work_mem はデフォルト4MB, アイドル状態で2~3MB。
基本、shared_buffers、work_mem、max_connections を中心にメモリ使用量の計画を立てる感じ。
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server も読みたい。
https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY もワンチャン。
Taichi Masuyama全体感は十分つかんだので一旦クローズ。
細かいチューニングを実際にやるときに別スレを立てる。