Meja yang sibuk tidak disedot


11

Kami menggunakan Postgres 9.2 pada Windows untuk menyimpan data rentang waktu frekuensi rendah: kami memasukkan sekitar 2000 baris per detik setiap 24 jam, 7 hari seminggu tanpa downtime. Ada DELETEyang berjalan di atas meja setiap 10 menit atau lebih untuk menjaga panjang meja ke jumlah hari yang tetap. Ini akhirnya menjadi 900 juta baris yang cukup stabil. (Bagi mereka yang tertarik, SELECT, INSERT, DELETEsemua performant).

Dengan demikian DELETE, menghapus baris sementara tidak membebaskan ruang disk. Untuk itu kita perlu VACUUMberlari.

Saya telah menanyakan pg_stat_user_tablesdan VACUUMtampaknya tidak pernah berjalan.

Apa yang saya mengerti dari berbagai dokumen ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):

  • kami tampaknya memiliki vakum otomatis, dan itu berjalan di tabel lain.
  • vakum otomatis tidak berjalan FULL, dan seharusnya tidak memerlukan kunci eksklusif di atas meja.

Apakah ada yang punya pikiran mengapa vakum otomatis tidak berjalan? Apakah ini murni karena meja terus sibuk?

Dan itu layak dijalankan VACUUMsetelah setiap DELETEdalam kasus ini (yang berjalan setiap 10 menit)?

Edit:

Permintaan menggunakan SQL dari tautan SO di bawah:

-[ RECORD 2 ]---+---------------------------
schemaname      | stats
relname         | statistic_values_by_sec
last_vacuum     |
last_autovacuum |
n_tup           |    932,315,264
dead_tup        |    940,727,818
av_threshold    |    186,463,103
expect_av       | *

dan output mentah:

-[ RECORD 3 ]-----+---------------------------
relid             | 501908
schemaname        | stats
relname           | statistic_values_by_sec
seq_scan          | 12
seq_tup_read      | 4526762064
idx_scan          | 29643
idx_tup_fetch     | 2544206912
n_tup_ins         | 1573896877
n_tup_upd         | 0
n_tup_del         | 941176496
n_tup_hot_upd     | 0
n_live_tup        | 688858417
n_dead_tup        | 940727818
last_vacuum       |
last_autovacuum   |
last_analyze      |
last_autoanalyze  | 2014-08-09 01:36:21.703+01
vacuum_count      | 0
autovacuum_count  | 0
analyze_count     | 0
autoanalyze_count | 69

4
Lihat Autovacuum Agresif di PostgreSQL . Juga akan menarik untuk memiliki select * from pg_stat_user_tablestabel ini (digunakan \xdalam psql untuk output yang diformat dengan baik)
Daniel Vérité

2
Tautan itu bermanfaat, dan mungkin menjawab pertanyaan - tabelnya terlalu sibuk agar vakum otomatis tidak berfungsi. @ DanielVérité Saya telah memperbarui pertanyaan dengan output yang Anda minta.
Barry

3
Itu banyak tupel mati! Jika memungkinkan, pertimbangkan mempartisi tabel dengan stempel waktu dan menjatuhkan partisi lama alih-alih menghapus. Peringatan utama adalah bahwa indeks unik di seluruh partisi tidak didukung.
Daniel Vérité

1
Apakah file log memiliki pesan tentang autovacuum pada tabel ini yang dibatalkan?
jjanes

@ jjanes Tidak - tidak ada indikasi dalam log bahwa autovacuum pernah dimulai.
Barry

Jawaban:


2

Saya akan melihat ke partisi . Jika dipartisi berdasarkan hari, Anda bisa menjatuhkan seluruh partisi setelah terlalu lama. Anda bahkan mungkin tidak perlu lagi menyedot debu.

Selain itu, kinerja keseluruhan dapat meningkat, karena Anda tidak memasukkan tempat Anda menghapus. Anda hanya perlu menulis kode untuk membuat partisi baru dan menghapus yang lama.

Inilah tujuan dari partisi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.