Autovacuum — PostgreSQLda VACUUM va ANALYZE ishlarini fon jarayonlari orqali avtomatik bajaradigan mexanizm. U MVCC sabab eskirgan row versionlarini qayta foydalaniladigan joyga aylantiradi, planner statistikasini yangilaydi va transaction ID wraparoundidan himoya qiladi.
MVCC va dead tuple
PostgreSQL UPDATE qilganda eski tuple’ni joyida ustidan yozmay, yangi version yaratadi. DELETE ham qatorni darhol fizik olib tashlamaydi. Eski snapshotlarga kerak bo‘lmay qolgan versionlar dead tuple hisoblanadi. Oddiy VACUUM ularning joyini shu jadval ichidagi keyingi yozuvlar uchun qayta foydalanishga tayyorlaydi.
Oddiy vacuum odatda operating systemga file hajmini to‘liq qaytarmaydi. VACUUM FULL jadvalni qayta yozib, joyni qaytarishi mumkin, lekin kuchli lock va qo‘shimcha disk talab qiladi. Autovacuum odatiy ravishda VACUUM FULL bajarmaydi.
Trigger mezoni
Table uchun vacuum threshold taxminan fixed threshold va live tuple soniga ko‘paytirilgan scale factordan hosil bo‘ladi. Katta jadvalda default scale factor juda ko‘p dead tuple kutilishiga olib kelishi mumkin. Tez yangilanadigan muhim jadvallarga per-table parametrlar beriladi.
Analyze threshold o‘zgarishlar soni bo‘yicha ishga tushadi va column statistics yangilanadi. Eskirgan statistika query optimizerning cardinality bahosini buzadi. Vacuum va analyze bir worker siklida bog‘liq bo‘lsa-da, vazifalari boshqa.
Workerlar va cost limit
Autovacuum launcher kerakli database va jadvallarni tanlaydi, workerlar ishni bajaradi. Worker soni, nap time, cost delay va cost limit disk bosimini boshqaradi. Juda agressiv vacuum foreground IO bilan raqobatlashadi; juda sekin vacuum dead tuple va wraparound xavfini oshiradi.
Autovacuumni global o‘chirish tavsiya etilmaydi. Table darajasida oddiy vacuum o‘chirilsa ham anti-wraparound vacuum baribir majburiy ishga tushishi mumkin. Bu xavfsizlik mexanizmi transaction ID’lar qayta aylanganda eski ma’lumot yangi deb ko‘rinishining oldini oladi.
Long transaction ta’siri
Uzoq ochiq transaction yoki replication slot juda eski snapshot/horizonni ushlab, vacuumga tuple’larni olib tashlashga ruxsat bermaydi. Autovacuum qayta-qayta ishlasa ham bloat kamaymaydi. idle in transaction session, prepared transaction va slotlar monitoring qilinadi.
Lock conflict ham workerning bekor bo‘lishiga olib kelishi mumkin. Autovacuum loglari, progress view va blocking sessionlar sababni ko‘rsatadi.
HOT update va index
HOT update indexed ustunlar o‘zgarmaganda va sahifada joy bo‘lganda yangi index entry yaratmasligi mumkin. Vacuum HOT chain va dead tuple’larni tozalaydi. Fillfactor sahifada update uchun bo‘sh joy qoldirib, HOT imkoniyatini oshirishi mumkin.
Indexlarda dead entry va page cleanup ham vacuum bilan bog‘liq. Bloatni faqat table size orqali baholash yetarli emas; index hajmi, scan performance va versionga xos cleanup xulqi ko‘riladi.
Kuzatuv va sozlash
Dead tuple, last autovacuum/analyze, transaction age, worker activity, table/index size va query latency kuzatiladi. Faqat “autovacuum ishladi” hodisasi yetarli emas; u dead versionlarni real olib tashlay olganmi va jadval workloadiga yetib olyaptimi tekshiriladi.
Sozlash productionga o‘xshash write rate bilan amalga oshiriladi. Katta jadvalga past scale factor, mos cost budget va tez-tez analyze kerak bo‘lishi mumkin. Emergency manual vacuum root sababni vaqtincha yengillashtiradi, lekin long transaction yoki yetarli worker bo‘lmasa muammo qaytadi.
Bog‘liq tushunchalar
PostgreSQL, MVCC, VACUUM, ANALYZE, Dead tuple, Transaction ID wraparound, HOT update, Table bloat