PostgreSQL Autovacuum va blokirovka

1. Kirish

PostgreSQL ma’lumotlar bazasi ishlayotgan paytda CPU yuklanishi 100% darajasida qolib ketgan vaziyat yuzaga keldi. Sababni tekshirganimda, muammoning markazida autovacuum turganini aniqladim. Men uni avval deyarli e’tibor talab qilmaydigan oddiy fon jarayoni deb o‘ylardim, ammo ushbu hodisa orqali autovacuum qanday ishlashi va hatto nima sababdan lock contention keltirib chiqarishi mumkinligini, hech bo‘lmaganda ma’lum darajada, tushunib oldim. Avval duch kelgan muammomizni qisqacha bayon qilaman, so‘ng uni tahlil qilish va hal etish jarayonida autovacuum hamda locklar haqida o‘rganganlarimni tartibga solaman.

2. Nima yuz berdi

Trafik yuqori bo‘lgan davrlarda fon tozalash vazifalari kechikdi va ma’lum bir jadvalning xid yoshi asta-sekin yig‘ilib bordi. Oxir-oqibat, u belgilangan chegaradan oshib ketdi va PostgreSQL o‘z-o‘zidan autovacuum’ni majburan ishga tushirdi. Tasodifan, ushbu jarayon ayni paytda ma’lumotlarining bir qismida muammo bo‘lgan jadvalni qayta ishlay boshladi. Natijada u uzoq vaqt yakunlanmay, CPU’ni uzluksiz iste’mol qilgan holda qolib ketdi.

Dastlab sabab oddiygina trafikning keskin oshishi yoki samarasiz so‘rovlar deb o‘yladim, ammo tekshiruv natijasida asosiy sabab ancha fundamental ekani ma’lum bo‘ldi. Ishlayotgan so‘rovlarni tekshirganimda, CPU’ni iste’mol qilayotgan jarayon odatiy ilova so‘rovi emas, balki 'autovacuum: VACUUM ... (to prevent wraparound)' ko‘rinishidagi autovacuum ekanini aniqladim. PostgreSQL uni tranzaksiya identifikatorlarining wraparound holatiga tushishining oldini olish uchun majburan ishga tushirganini va jarayonni to‘xtatish yoki autovacuum’ni o‘chirib qo‘yish kabi oddiy usullar bilan uni to‘xtatib bo‘lmasligini bildim.

Ushbu jarayon davomida tizim holatidagi o‘zgarishlarni quyidagicha umumlashtirish mumkin.

Javob choralarimiz uchta asosiy bosqichda amalga oshirildi. Avvalo, CPU’ni iste’mol qilayotgan jarayon wraparound’ning oldini oluvchi autovacuum ekanini va yuqorida qayd etilganidek, bu rejimni oddiy usullar bilan to‘xtatib bo‘lmasligini tasdiqlagach, jarayonni bevosita to‘xtatish o‘rniga chegara sozlamasini vaqtincha oshirdik. Bu muammoli jadvalni majburiy bajarish nishonlari ro‘yxatidan chiqarishga yordam berdi. CPU yuklanishi normal darajaga tushganini tasdiqlagach, asosiy buzilish muammosini hal qilish uchun muammoli jadvalning zaxira nusxasini oldik va uni qayta ishga tushirdik. Nihoyat, vaqtincha oshirilgan sozlamani dastlabki qiymatiga qaytardik, CPU va xizmat holatini yana tekshirdik hamda javob choralarini yakunladik.

-- 1) 원인 진단: CPU를 점유 중인 프로세스 확인
SELECT pid, query FROM pg_stat_activity WHERE state = 'active';
 
-- 2) 긴급 조치: wraparound 방지 대상에서 제외되도록 임계값 임시 상향
ALTER SYSTEM SET autovacuum_freeze_max_age = 500000000;
 
-- 3) 문제 테이블 정리 후 임시 설정 원복
TRUNCATE TABLE target_table;
ALTER SYSTEM SET autovacuum_freeze_max_age = 200000000;

1-so‘rov natijalaridagi asosiy mezon — so‘rov qiymatida 'autovacuum: VACUUM ... (to prevent wraparound)' iborasi bor-yo‘qligidir. Agar bu ibora mavjud bo‘lsa, bu oddiy autovacuum emas, balki wraparound’ning oldini olish uchun majburan ishga tushirilgan rejim ekanini bildiradi. Yuqorida tushuntirilganidek, jarayonni bevosita to‘xtatish samara bermaydi. Aksincha, agar bu iborasiz faqat 'autovacuum: VACUUM ...' ko‘rinsa, bu oddiy tozalash jarayoni bo‘lib, odatda xavotirlanishga hojat yo‘q.

3. Autovacuum nima?

3.1 Autovacuum: bu jarayon nima qiladi?

UPDATE yoki DELETE bajarilganda ham PostgreSQL mavjud satrlarni darhol o‘chirib tashlamaydi; aksincha, ularni dead tuple sifatida qoldiradi (MVCC). Autovacuum to‘planib qolgan ushbu dead tuple’larni tozalaydigan va tranzaksiya identifikatorlarini qayta ishlatish mumkin bo‘lishi uchun ularni muzlatadigan fon jarayonidir. Bir qarashda bu DBA’ning tashvishidek ko‘rinsa-da, ilovalar yaratadigan so‘rovlar andozalari va tranzaksiyalardan foydalanish usuli autovacuum yuklanishi hamda lock contention’ga bevosita ta’sir qiladi. Shu sababli dasturchilar hech bo‘lmaganda uning ishlashining asosiy tamoyillarini tushunib olishlari foydalidir.

3.2 Nima uchun va qanday qilib xid_age to‘planadi? — Wraparound’ning oldini oluvchi autovacuum

Har safar tranzaksiya sodir bo‘lganda xid_age ortib boradi va uni kamaytirishning yagona yo‘li — autovacuum jadvaldagi freeze amalini yakunlashidir. Biroq yozish trafigi yuqori bo‘lgani sababli xid_age tez to‘plansa, autovacuum esa I/O contention yoki qayta ishlashdagi kechikishlar tufayli o‘z vaqtida yakunlanmasa, to‘planish tezligi bilan tozalash tezligi o‘rtasidagi farq tobora kengayadi. Agar bu farq kamaytirilmasa va tranzaksiya identifikatorining (xid) yoshi oxir-oqibat chegaradan oshib ketsa, PostgreSQL wraparound’ning oldini olish uchun jadvalda autovacuum’ni majburan ishga tushiradi. Bu rejim ma’lumotlar izchilligini saqlashning so‘nggi himoya chizig‘i bo‘lgani sababli, jarayonni to‘xtatish yoki autovacuum’ni o‘chirib qo‘yish kabi oddiy usullar bilan uni to‘xtatib bo‘lmaydi. Ushbu hodisada ham uning muammoli jadval bilan o‘zaro ta’siri resurslarning uzoq vaqt sarflanishiga va xizmatga ta’sir ko‘rsatishiga olib keldi.

Rasm 1. Wraparound’ning oldini oluvchi autovacuum’ga olib keladigan bosqichlar

4. Autovacuum sabab yuzaga keladigan lock contention’ning yana bir holati

Bu hodisaning bevosita sababi bo‘lmagan bo‘lsa-da, autovacuum lock contention’ga sabab bo‘lishi mumkin bo‘lgan boshqa vaziyatlarni ham shu imkoniyatdan foydalanib tartibga soldim.

4.1 Oddiy autovacuum va DDL o‘rtasidagi ziddiyat

Oddiy autovacuum nisbatan yengil SHARE UPDATE EXCLUSIVE lock’dan foydalanadi, shuning uchun u odatda SELECT / INSERT / UPDATE kabi so‘rovlar bilan muammosiz birga ishlaydi. Muammo deployment vaqtida ALTER TABLE kabi ACCESS EXCLUSIVE lock’ni talab qiladigan DDL bajarilganda yuzaga keladi. Agar autovacuum jadvalni allaqachon qayta ishlayotgan bo‘lsa, DDL autovacuum yakunlanguncha kutishi kerak, undan keyin keladigan oddiy so‘rovlar ham uzoq navbatda kutib qolishi mumkin. Bu “deployment vaqtida xizmat to‘satdan to‘xtab qoldi” degan hodisaning keng tarqalgan sabablaridan biridir.

Rasm 2. Autovacuum va DDL oʻrtasidagi blokirovka ziddiyati

4.2 Uzoq davom etuvchi tranzaksiyalar sabab yuzaga keladigan muammolar

Agar ilovaning ulanish sizib chiqishi yoki disk raskadrovka vaqtida ochiq qoldirilgan tranzaksiya juda uzoq vaqt nazoratsiz qolsa, autovacuum ushbu tranzaksiya boshlanishidan oldin yaratilgan oʻlik kortejlarni tozalay olmaydi. Natijada jadvallar va indekslar zarur boʻlganidan kattaroq hajmga oʻsib, ortiqcha shishishga olib kelishi va soʻrovlar unumdorligini pasaytirishi mumkin.

5. Xulosa

Agar autovacuum oʻz-oʻzidan yaxshi ishlaydigan fon jarayoni, deb hisoblab, uni nazoratsiz qoldirsangiz, odatiy sharoitlarda hech qanday muammo yuzaga kelmasligi mumkin. Biroq trafikning ortishi, uzoq davom etuvchi tranzaksiyalar va notoʻgʻri sozlamalar kabi sharoitlar bir-biriga toʻgʻri kelganda, bu butun xizmatga taʼsir qilishi mumkin. xid_age va oʻlik kortejlar nisbati kabi koʻrsatkichlar muntazam kuzatilmagani uchun muammo jiddiy darajaga yetmaguncha uni sezmasligingiz mumkin. Ushbu koʻrsatkichlarni ham kuzatib borish majburiy ishga tushirish shartlari yuzaga kelishidan oldin vaziyatga koʻproq imkoniyat bilan javob berishga yordam beradi.

Sean