Men sizga Aleksey Lesovskiyning Data Egret "PostgreSQL monitoringi asoslari" dan olingan ma'ruzasi stenogrammasini o'qishni taklif qilaman.
Ushbu hisobotda Aleksey Lesovskiy post-gress statistikasining asosiy nuqtalari, ular nimani anglatishini va nima uchun ular monitoringda ishtirok etishi kerakligi haqida gapiradi; monitoringda qanday grafiklar bo'lishi kerakligi, ularni qanday qo'shish va ularni qanday izohlash haqida. Hisobot ma'lumotlar bazasi ma'murlari, tizim ma'murlari va Postgres muammolarini bartaraf etishga qiziqqan dasturchilar uchun foydali bo'ladi.
Mening ismim Aleksey Lesovskiy, men Data Egret kompaniyasi vakiliman.
O'zim haqimda bir necha so'z. Men uzoq vaqt oldin tizim administratori sifatida ish boshlaganman.
Men har xil turdagi Linux tizimlarini boshqardim, Linux bilan bog'liq turli narsalar ustida ishladim, ya'ni virtualizatsiya, monitoring, proksi-serverlar bilan ishladim va hokazo. Lekin ma'lum bir nuqtada men ko'proq ma'lumotlar bazalari, PostgreSQL bilan ishlay boshladim. Men uni juda yoqtirardim. Va bir nuqtada men ish vaqtimning ko'p qismini PostgreSQL ustida ishlay boshladim. Va asta-sekin men PostgreSQL DBAga aylandim.
Faoliyatim davomida men har doim statistika, monitoring va telemetriya mavzulariga qiziqib kelganman. Tizim ma'muri bo'lganimda esa Zabbix bilan juda yaqin ishlaganman. Va men kabi kichik skriptlar to'plamini yozdim . U o'z davrida juda mashhur edi. Va u erda nafaqat Linuxni, balki turli xil komponentlarni ham juda muhim narsalarni kuzatish mumkin edi.
Endi men PostgreSQL ustida ishlayapman. Men allaqachon PostgreSQL statistikasi bilan ishlash imkonini beruvchi yana bir narsani yozyapman. U deyiladi (Habre haqidagi maqola - ).
Kichkina kirish yozuvi. Bizning mijozlarimiz, mijozlarimiz qanday vaziyatlarga ega? Ma'lumotlar bazasi bilan bog'liq qandaydir baxtsiz hodisa mavjud. Va ma'lumotlar bazasi allaqachon tiklanganida, bo'lim boshlig'i yoki rivojlanish bo'limi boshlig'i kelib: "Do'stlar, biz ma'lumotlar bazasini kuzatishimiz kerak, chunki biron bir yomon narsa yuz berdi va kelajakda bu sodir bo'lishining oldini olishimiz kerak" deydi. Va bu erda ma'lumotlar bazasini - PostgreSQL, MySQL yoki boshqalarni kuzatishingiz uchun monitoring tizimini tanlash yoki mavjud monitoring tizimini moslashtirishning qiziqarli jarayoni boshlanadi. Va hamkasblar taklif qila boshlaydilar: "Men falon ma'lumotlar bazasi borligini eshitdim. Keling, undan foydalanaylik." Hamkasblar bir-biri bilan bahslasha boshlaydi. Va oxirida ma'lum bo'lishicha, biz ma'lumotlar bazasini tanlaymiz, ammo PostgreSQL monitoringi unda juda yomon taqdim etilgan va biz har doim biror narsa qo'shishimiz kerak. GitHub-dan ba'zi omborlarni oling, ularni klonlang, skriptlarni moslang va qandaydir tarzda ularni sozlang. Va oxir-oqibat u qandaydir qo'l mehnati bilan tugaydi.
Shuning uchun, ushbu ma'ruzada men sizga nafaqat PostgreSQL, balki ma'lumotlar bazasi uchun ham monitoringni qanday tanlash haqida ma'lumot berishga harakat qilaman. Va yuzaga kelishi mumkin bo'lgan har qanday favqulodda vaziyatlarning oldini olish uchun ma'lumotlar bazasini foyda bilan kuzatib borish uchun sizga monitoringni yakunlash imkonini beradigan bilimlarni bering.
Va bu hisobotda bo'ladigan g'oyalar to'g'ridan-to'g'ri istalgan ma'lumotlar bazasiga moslashtirilishi mumkin, u DBMS yoki noSQL. Shuning uchun, nafaqat PostgreSQL, balki PostgreSQLda buni qanday qilish bo'yicha ko'plab retseptlar bo'ladi. PostgreSQL monitoringi uchun mavjud bo'lgan so'rovlar, ob'ektlar misollari bo'ladi. Va agar sizning DBMS ularni monitoringga qo'yishga imkon beradigan bir xil narsalarga ega bo'lsa, siz ularni moslashtirishingiz, qo'shishingiz mumkin va bu yaxshi bo'ladi.
Men hisobotda bo'lmayman
ko'rsatkichlarni qanday etkazib berish va saqlash haqida gapiring. Ma'lumotlarni qayta ishlash va foydalanuvchiga taqdim etish haqida hech narsa aytmayman. Va ogohlantirish haqida hech narsa aytmayman.
Ammo hikoya davom etar ekan, men mavjud monitoringning turli skrinshotlarini ko'rsataman va qandaydir tarzda ularni tanqid qilaman. Ammo shunga qaramay, men ushbu mahsulotlar uchun reklama yoki reklamaga qarshi reklama yaratmaslik uchun brendlarni nomlamaslikka harakat qilaman. Shuning uchun, barcha tasodiflar tasodifiy va sizning tasavvuringizga qoldiriladi.
Birinchidan, monitoring nima ekanligini aniqlaymiz. Monitoring - bu juda muhim narsa. Buni hamma tushunadi. Ammo shu bilan birga, monitoring biznes mahsulotiga taalluqli emas va kompaniyaning foydasiga bevosita ta'sir qilmaydi, shuning uchun vaqt har doim qoldiq asosida monitoringga ajratiladi. Agar vaqtimiz bo'lsa, biz monitoring qilamiz, agar vaqtimiz bo'lmasa, OK, biz uni orqaga qo'yamiz va bir kun kelib bu vazifalarga qaytamiz.
Shuning uchun, bizning amaliyotimizdan, mijozlarga kelganimizda, monitoring ko'pincha to'liq bo'lmaydi va ma'lumotlar bazasi bilan yaxshiroq ishlashimizga yordam beradigan qiziqarli narsalarga ega emas. Va shuning uchun monitoring har doim yakunlanishi kerak.
Ma'lumotlar bazalari shunday murakkab narsalarki, ularni ham kuzatib borish kerak, chunki ma'lumotlar bazalari ma'lumotlar ombori. Va ma'lumot kompaniya uchun juda muhim, uni hech qanday tarzda yo'qotib bo'lmaydi. Shu bilan birga, ma'lumotlar bazalari juda murakkab dasturiy ta'minot qismlaridir. Ular ko'p sonli tarkibiy qismlardan iborat. Va bu komponentlarning ko'pchiligi kuzatilishi kerak.
Agar biz PostgreSQL haqida alohida gapiradigan bo'lsak, u holda uni ko'p sonli komponentlardan tashkil topgan sxema ko'rinishida ko'rsatish mumkin. Ushbu komponentlar bir-biri bilan o'zaro ta'sir qiladi. Shu bilan birga, PostgreSQL-da Stats Collector quyi tizimi mavjud bo'lib, u sizga ushbu quyi tizimlarning ishlashi haqida statistik ma'lumotlarni to'plash va ma'mur yoki foydalanuvchiga ushbu statistikani ko'rishi uchun qandaydir interfeysni taqdim etish imkonini beradi.
Ushbu statistika ma'lum funktsiyalar va ko'rinishlar to'plami shaklida taqdim etiladi. Ularni jadvallar deb ham atash mumkin. Ya'ni, oddiy psql mijozidan foydalanib, siz ma'lumotlar bazasiga ulanishingiz, ushbu funktsiyalar va ko'rinishlarni tanlashingiz va PostgreSQL quyi tizimlarining ishlashi haqida ba'zi aniq raqamlarni olishingiz mumkin.
Siz ushbu raqamlarni sevimli monitoring tizimingizga qo'shishingiz, grafiklarni chizishingiz, funktsiyalarni qo'shishingiz va uzoq muddatda tahliliy ma'lumotlarni olishingiz mumkin.
Ammo bu hisobotda men bu funktsiyalarning barchasini to'liq qamrab olmayman, chunki bu butun kunni olishi mumkin. Men tom ma'noda ikkita, uch yoki to'rtta narsaga murojaat qilaman va ular monitoringni yaxshilashga qanday yordam berishini aytib beraman.
Va agar biz ma'lumotlar bazasi monitoringi haqida gapiradigan bo'lsak, unda nimani kuzatish kerak? Avvalo, biz mavjudligini kuzatishimiz kerak, chunki ma'lumotlar bazasi mijozlarga ma'lumotlarga kirishni ta'minlaydigan xizmatdir va biz mavjudligini kuzatishimiz, shuningdek, uning ayrim sifat va miqdoriy xususiyatlarini taqdim etishimiz kerak.
Shuningdek, bizning ma'lumotlar bazasiga ulanadigan mijozlarni kuzatishimiz kerak, chunki ular oddiy mijozlar va ma'lumotlar bazasiga zarar etkazishi mumkin bo'lgan zararli mijozlar bo'lishi mumkin. Shuningdek, ularni kuzatib borish va ularning faoliyatini kuzatish kerak.
Mijozlar ma'lumotlar bazasiga ulanganda, ular bizning ma'lumotlarimiz bilan ishlashni boshlashlari aniq, shuning uchun mijozlar ma'lumotlar bilan qanday ishlashini kuzatishimiz kerak: qaysi jadvallar bilan va kamroq darajada qaysi indekslar bilan. Ya'ni, biz mijozlarimiz tomonidan yaratilgan ish yukini baholashimiz kerak.
Ammo ish yuki, albatta, so'rovlardan iborat. Ilovalar ma'lumotlar bazasiga ulanadi, so'rovlar yordamida ma'lumotlarga kirishadi, shuning uchun ma'lumotlar bazasida qanday so'rovlar mavjudligini baholash, ularning etarliligini, ular egri yozilmaganligini, ba'zi variantlarni qayta yozish va tezroq ishlashi uchun qilish kerakligini kuzatish muhimdir. va yaxshiroq ishlash bilan.
Va biz ma'lumotlar bazasi haqida gapirganimiz sababli, ma'lumotlar bazasi har doim fon jarayonlaridir. Fon jarayonlari ma'lumotlar bazasi ish faoliyatini yaxshi darajada ushlab turishga yordam beradi, shuning uchun ular o'zlari ishlashi uchun ma'lum miqdordagi resurslarni talab qiladi. Va shu bilan birga, ular mijoz so'rovi resurslari bilan bir-biriga mos kelishi mumkin, shuning uchun ochko'z fon jarayonlari mijoz so'rovlarining bajarilishiga bevosita ta'sir qilishi mumkin. Shuning uchun, fon jarayonlari nuqtai nazaridan buzilishlar bo'lmasligi uchun ular ham kuzatilishi va kuzatilishi kerak.
Va bularning barchasi ma'lumotlar bazasi monitoringi nuqtai nazaridan tizim metrikasida qoladi. Ammo bizning infratuzilmamizning aksariyati bulutlarga o'tayotganini hisobga olsak, individual xostning tizim ko'rsatkichlari doimo fonga o'tadi. Ammo ma'lumotlar bazalarida ular hali ham dolzarbdir va, albatta, tizim ko'rsatkichlarini kuzatish ham kerak.
Tizim ko'rsatkichlari bilan hamma narsa ko'proq yoki kamroq yaxshi, barcha zamonaviy monitoring tizimlari allaqachon ushbu ko'rsatkichlarni qo'llab-quvvatlaydi, lekin umuman olganda, ba'zi komponentlar hali ham etarli emas va ba'zi narsalarni qo'shish kerak. Men ularga ham tegaman, ular haqida bir nechta slaydlar bo'ladi.
Rejaning birinchi nuqtasi - foydalanish imkoniyati. Foydalanish imkoniyati nima? Mening tushunishimcha, mavjudlik - bu bazaning ulanishlarga xizmat ko'rsatish qobiliyati, ya'ni baza ko'tariladi, u xizmat sifatida mijozlardan ulanishlarni qabul qiladi. Va bu mavjudlikni ma'lum xususiyatlar bilan baholash mumkin. Ushbu xususiyatlarni asboblar panelida ko'rsatish juda qulay.
Hamma asboblar paneli nima ekanligini biladi. Bu siz kerakli ma'lumotlar jamlangan ekranga bir marta qaraganingizda. Va ma'lumotlar bazasida muammo bor yoki yo'qligini darhol aniqlashingiz mumkin.
Shunga ko'ra, ma'lumotlar bazasining mavjudligi va boshqa asosiy xususiyatlar har doim asboblar panelida ko'rsatilishi kerak, shunda bu ma'lumotlar sizning qo'lingizda va har doim mavjud bo'ladi. Hodisalarni tekshirishda yordam beradigan ba'zi qo'shimcha tafsilotlar, ba'zi favqulodda vaziyatlarni o'rganayotganda, ular allaqachon ikkinchi darajali asboblar paneliga joylashtirilishi yoki uchinchi tomon monitoring tizimlariga olib keladigan burg'ulash havolalarida yashirilishi kerak.
Bitta taniqli monitoring tizimiga misol. Bu juda ajoyib monitoring tizimi. U juda ko'p ma'lumotlarni to'playdi, lekin mening nuqtai nazarimga ko'ra, u asboblar paneli haqida g'alati tushunchaga ega. "Boshqaruv panelini yaratish" uchun havola mavjud. Lekin asboblar panelini yaratganingizda, siz ikkita ustun ro'yxatini, grafiklar ro'yxatini yaratasiz. Va biror narsaga qarash kerak bo'lganda, siz sichqoncha bilan bosishni boshlaysiz, aylanasiz, kerakli diagrammani qidirasiz. Va bu vaqt talab etadi, ya'ni bunday asboblar paneli yo'q. Faqat jadvallar ro'yxati mavjud.
Ushbu asboblar paneliga nima qo'shishingiz kerak? Siz javob vaqti kabi xususiyatdan boshlashingiz mumkin. PostgreSQL pg_stat_statements ko'rinishiga ega. U sukut bo'yicha o'chirib qo'yilgan, lekin u doimo yoqilgan va ishlatilishi kerak bo'lgan muhim tizim ko'rinishlaridan biridir. U ma'lumotlar bazasida bajarilgan barcha so'rovlar haqidagi ma'lumotlarni saqlaydi.
Shunga ko'ra, biz barcha so'rovlarning umumiy bajarilish vaqtini olishimiz va uni yuqoridagi maydonlar yordamida so'rovlar soniga bo'lishimiz mumkinligidan boshlashimiz mumkin. Ammo bu shifoxonadagi o'rtacha harorat. Biz boshqa maydonlardan boshlashimiz mumkin - so'rovning minimal bajarilishi vaqti, maksimal va median. Va biz hatto foizlarni ham qurishimiz mumkin; PostgreSQL buning uchun mos keladigan funktsiyalarga ega. Va biz allaqachon tugallangan so'rovlar uchun ma'lumotlar bazasining javob berish vaqtini tavsiflovchi ba'zi raqamlarni olishimiz mumkin, ya'ni biz soxta "1-ni tanlang" so'rovini bajarmaymiz va javob vaqtiga qaraymiz, lekin biz allaqachon bajarilgan so'rovlar uchun javob vaqtini tahlil qilamiz va chizamiz. yoki alohida raqam, yoki biz uning asosida grafik tuzamiz.
Hozirgi vaqtda tizim tomonidan yaratilgan xatolar sonini kuzatish ham muhimdir. Buning uchun siz pg_stat_database ko'rinishidan foydalanishingiz mumkin. Biz xact_rollback maydoniga e'tibor qaratamiz. Bu maydon nafaqat ma'lumotlar bazasida sodir bo'lgan orqaga qaytishlar sonini ko'rsatadi, balki xatolar sonini ham hisobga oladi. Nisbatan gapiradigan bo'lsak, biz bu raqamni asboblar panelida ko'rsatishimiz va hozirda qancha xatolarimiz borligini ko'rishimiz mumkin. Agar xatolar juda ko'p bo'lsa, bu jurnallarni ko'rib chiqish va ular qanday xatolar ekanligini va nima uchun ular paydo bo'lishini ko'rish va keyin ularni investitsiya qilish va hal qilish uchun yaxshi sababdir.
Taxometr kabi narsalarni qo'shishingiz mumkin. Bular soniyada tranzaksiyalar soni va soniyada so'rovlar soni. Nisbatan gapiradigan bo'lsak, siz ushbu raqamlardan ma'lumotlar bazasining joriy ishlashi sifatida foydalanishingiz mumkin va so'rovlarda eng yuqori ko'rsatkichlar, tranzaksiyalarda cho'qqilar bor-yo'qligini yoki aksincha, ba'zi bir backend ishlamay qolganligi sababli ma'lumotlar bazasi kam yuklanganligini kuzatishingiz mumkin. Har doim ushbu raqamga qarash va shuni yodda tutish kerakki, bizning loyihamiz uchun bunday ko'rsatkichlar normaldir, ammo yuqoridagi va pastdagi qiymatlar allaqachon muammoli va tushunarsizdir, demak, bu raqamlar nima uchun ekanligini ko'rib chiqishimiz kerak. shunchalik baland.
Tranzaktsiyalar sonini hisoblash uchun yana pg_stat_database ko'rinishiga murojaat qilishimiz mumkin. Biz majburiyatlar sonini va orqaga qaytarishlar sonini qo'shishimiz va soniyada tranzaktsiyalar sonini olishimiz mumkin.
Bir nechta so'rovlar bitta tranzaksiyaga mos kelishi mumkinligini hamma tushunadimi? Shuning uchun TPS va QPS biroz farq qiladi.
Bir soniyada so'rovlar sonini pg_stat_statements dan olish mumkin va shunchaki barcha bajarilgan so'rovlar yig'indisini hisoblab chiqing. Ma'lumki, biz joriy qiymatni oldingi bilan solishtiramiz, uni ayirib, deltani olamiz va miqdorni olamiz.
Agar xohlasangiz, qo'shimcha ko'rsatkichlarni qo'shishingiz mumkin, ular bizning ma'lumotlar bazasi mavjudligini baholashga yordam beradi va biron bir to'xtab qolish vaqtlari bo'lganligini nazorat qiladi.
Ushbu ko'rsatkichlardan biri ish vaqti. Ammo PostgreSQL-da ish vaqti biroz qiyin. Sababini aytaman. PostgreSQL ishga tushirilgach, ish vaqti hisobot berishni boshlaydi. Ammo, masalan, tunda biron bir vazifa bajarilgan bo'lsa, OOM qotili kelib, PostgreSQL bola jarayonini majburan to'xtatgan bo'lsa, bu holda PostgreSQL barcha mijozlarning ulanishini to'xtatadi, parchalangan xotira maydonini tiklaydi va qayta tiklashni boshlaydi. oxirgi nazorat punkti. Va nazorat punktidan bu qutqarish davom etsa-da, ma'lumotlar bazasi ulanishlarni qabul qilmaydi, ya'ni bu holat ishlamay qolgan vaqt sifatida baholanishi mumkin. Ammo ish vaqti hisoblagichi qayta tiklanmaydi, chunki u birinchi daqiqadan boshlab postmaster ishga tushirish vaqtini hisobga oladi. Shuning uchun bunday vaziyatlarni o'tkazib yuborish mumkin.
Vakuum ishchilarining sonini ham kuzatishingiz kerak. PostgreSQL-da avtovakuum nima ekanligini hamma biladimi? Bu PostgreSQL-dagi qiziqarli quyi tizim. U haqida ko'plab maqolalar yozildi, ko'plab hisobotlar qilindi. Vakuum va uning qanday ishlashi haqida juda ko'p munozaralar mavjud. Ko'pchilik buni zaruriy yovuzlik deb biladi. Lekin bu shunday. Bu axlat yig'uvchining o'ziga xos analogi bo'lib, u har qanday tranzaksiya uchun kerak bo'lmagan qatorlarning eskirgan versiyalarini tozalaydi va yangi qatorlar uchun jadvallar va indekslarda joy bo'shatadi.
Nega buni kuzatib borish kerak? Chunki vakuum ba'zan juda og'riydi. U katta miqdordagi resurslarni iste'mol qiladi va natijada mijozning so'rovlari azoblana boshlaydi.
Va uni keyingi bo'limda gaplashadigan pg_stat_activity ko'rinishi orqali kuzatish kerak. Ushbu ko'rinish ma'lumotlar bazasidagi joriy faoliyatni ko'rsatadi. Va bu faoliyat orqali biz hozir ishlayotgan vakuumlar sonini kuzatishimiz mumkin. Biz vakuumlarni kuzatishimiz mumkin va agar biz chegaradan oshib ketgan bo'lsak, bu PostgreSQL sozlamalarini ko'rib chiqish va qandaydir tarzda vakuumning ishlashini optimallashtirish uchun sababdir.
PostgreSQL haqida yana bir narsa shundaki, PostgreSQL uzoq tranzaktsiyalardan juda kasal. Ayniqsa, uzoq vaqt davomida osilgan va hech narsa qilmaydigan operatsiyalardan. Bu tranzaksiyadagi statistik ishlamay qolish deb ataladi. Bunday tranzaktsiya qulflarni ushlab turadi va vakuumning ishlashiga to'sqinlik qiladi. Va natijada stollar shishadi va kattalashadi. Va bu jadvallar bilan ishlaydigan so'rovlar sekinroq ishlay boshlaydi, chunki siz xotiradan diskka va orqaga satrlarning barcha eski versiyalarini belkurak qilishingiz kerak. Shuning uchun, vaqtni, eng uzoq tranzaktsiyalarning davomiyligini, eng uzun vakuum so'rovlarini ham kuzatib borish kerak. Va agar biz OLTP yuklanishi uchun 10-20-30 daqiqadan ko'proq vaqtdan beri ishlayotgan ba'zi jarayonlarni ko'rsak, ularga e'tibor qaratishimiz va ularni majburan to'xtatishimiz yoki dasturni optimallashtirishimiz kerak. chaqirilmaydi va uzoq vaqt osib qo'ymang. Analitik ish yuki uchun 10-20-30 daqiqa normal hisoblanadi, undan uzoqroqlari ham bor.
Keyin bizda ulangan mijozlar bilan variant mavjud. Biz allaqachon asboblar panelini yaratganimizda va unga kalit mavjudligi ko'rsatkichlarini joylashtirganimizda, u erga ulangan mijozlar haqida qo'shimcha ma'lumotlarni ham qo'shishimiz mumkin.
Bog'langan mijozlar haqidagi ma'lumotlar juda muhim, chunki PostgreSQL nuqtai nazaridan mijozlar har xil. Yaxshi mijozlar bor, yomon mijozlar ham bor.
Oddiy misol. Mijoz tomonidan men dasturni tushunaman. Ilova ma'lumotlar bazasiga ulangan va darhol o'z so'rovlarini u erga yuborishni boshlaydi, ma'lumotlar bazasi ularni qayta ishlaydi va bajaradi va natijalarni mijozga qaytaradi. Bu yaxshi va to'g'ri mijozlar.
Mijoz ulangan bo'lsa, u ulanishni ushlab turadi, lekin hech narsa qilmaydi. U ishlamay qolgan holatda.
Ammo yomon mijozlar ham bor. Misol uchun, xuddi shu mijoz ulandi, tranzaktsiyani ochdi, ma'lumotlar bazasida biror narsa qildi va keyin kodga kirdi, masalan, tashqi manbaga kirish yoki u erda olingan ma'lumotlarni qayta ishlash. Ammo u bitimni yopmadi. Va tranzaktsiya ma'lumotlar bazasida osilib turadi va chiziqdagi qulfda saqlanadi. Bu yomon holat. Va agar to'satdan biron bir dastur istisnosiz bajarilmasa, tranzaktsiya juda uzoq vaqt davomida ochiq qolishi mumkin. Va bu PostgreSQL ishlashiga bevosita ta'sir qiladi. PostgreSQL sekinroq ishlaydi. Shuning uchun bunday mijozlarni o'z vaqtida kuzatib borish va ularning ishini majburan tugatish muhimdir. Va bunday holatlar yuzaga kelmasligi uchun ilovangizni optimallashtirishingiz kerak.
Boshqa yomon mijozlar mijozlarni kutishmoqda. Ammo ular vaziyat tufayli yomonlashadi. Masalan, oddiy bo'sh tranzaksiya: tranzaktsiyani ochishi, ba'zi satrlarda qulflarni olishi mumkin, keyin kodning biron bir joyida u muvaffaqiyatsiz bo'lib, osilgan tranzaksiyani qoldiradi. Boshqa mijoz kelib, xuddi shu ma'lumotlarni so'raydi, lekin u qulfga duch keladi, chunki bu osilgan tranzaksiya allaqachon ba'zi kerakli qatorlarda qulflarni ushlab turadi. Ikkinchi tranzaksiya esa birinchi tranzaksiya yakunlanishini yoki uni administrator tomonidan majburan yopishini kutib turadi. Shu sababli, kutilayotgan tranzaktsiyalar ma'lumotlar bazasiga ulanish chegarasini to'plashi va to'ldirishi mumkin. Limit to‘lganida esa dastur endi ma’lumotlar bazasi bilan ishlay olmaydi. Bu allaqachon loyiha uchun favqulodda holat. Shuning uchun yomon mijozlarni kuzatib borish va ularga o'z vaqtida javob berish kerak.
Monitoringning yana bir misoli. Va bu erda allaqachon munosib boshqaruv paneli mavjud. Yuqorida ulanishlar haqida ma'lumot mavjud. JB ulanishi - 8 dona. Va bu hammasi. Bizda qaysi mijozlar faol, qaysi mijozlar shunchaki ishlamaydi, hech narsa qilmayapti. Kutilayotgan tranzaktsiyalar va kutilayotgan ulanishlar haqida hech qanday ma'lumot yo'q, ya'ni bu ulanishlar sonini ko'rsatadigan raqam va tamom. Va keyin o'zingiz uchun taxmin qiling.
Shunga ko'ra, ushbu ma'lumotni monitoringga qo'shish uchun siz pg_stat_activity tizimi ko'rinishiga kirishingiz kerak. Agar siz PostgreSQL-da ko'p vaqt sarflasangiz, bu sizning do'stingiz bo'lishi kerak bo'lgan juda yaxshi ko'rinishdir, chunki u PostgreSQL-dagi joriy faoliyatni, ya'ni unda nima sodir bo'layotganini ko'rsatadi. Har bir jarayon uchun ushbu jarayon haqidagi ma'lumotlarni ko'rsatadigan alohida qator mavjud: ulanish qaysi xostdan amalga oshirilgan, qaysi foydalanuvchi ostida, qaysi nom ostida, tranzaksiya qachon boshlangan, hozirda qanday so'rov bajarilmoqda, qaysi so'rov oxirgi marta bajarilgan. Va shunga ko'ra, biz stat maydonidan foydalanib, mijozning holatini baholashimiz mumkin. Nisbatan aytganda, biz ushbu maydon bo'yicha guruhlashimiz va hozirda ma'lumotlar bazasida mavjud bo'lgan statistik ma'lumotlarni va ma'lumotlar bazasida ushbu statistikaga ega bo'lgan ulanishlar sonini olishimiz mumkin. Va biz allaqachon olingan raqamlarni monitoringimizga yuborishimiz va ular asosida grafiklarni chizishimiz mumkin.
Tranzaktsiyaning davomiyligini baholash ham muhimdir. Men allaqachon vakuumlarning davomiyligini baholash muhimligini aytdim, ammo tranzaktsiyalar xuddi shunday baholanadi. Xact_start va query_start maydonlari mavjud. Ular, nisbatan aytganda, tranzaktsiyaning boshlanish vaqtini va so'rovning boshlanish vaqtini ko'rsatadi. Joriy vaqt tamg'asini ko'rsatadigan now() funktsiyasini olamiz va tranzaksiya va so'rov vaqt tamg'asini ayiramiz. Va biz tranzaktsiyaning davomiyligini, so'rovning davomiyligini olamiz.
Agar biz uzoq muddatli operatsiyalarni ko'rsak, ularni allaqachon bajarishimiz kerak. OLTP yuklash uchun uzoq tranzaktsiyalar allaqachon 1-2-3 daqiqadan ko'proq vaqtni oladi. OLAP ish yuki uchun uzoq tranzaktsiyalar odatiy holdir, lekin agar ularni bajarish uchun ikki soatdan ko'proq vaqt kerak bo'lsa, bu ham bizda biron bir joyda egilish borligining belgisidir.
Mijozlar ma'lumotlar bazasiga ulangandan so'ng, ular bizning ma'lumotlarimiz bilan ishlashni boshlaydilar. Ular jadvallarga kirishadi, jadvaldan ma'lumotlarni olish uchun indekslarga kirishadi. Va mijozlar ushbu ma'lumotlar bilan qanday munosabatda bo'lishini baholash muhimdir.
Bu bizning ish yukimizni baholash va biz uchun qaysi jadvallar "eng issiq" ekanligini tushunish uchun kerak. Misol uchun, bu biz "issiq" jadvallarni qandaydir tezkor SSD xotirasiga joylashtirmoqchi bo'lgan holatlarda kerak bo'ladi. Misol uchun, biz uzoq vaqt davomida foydalanmayotgan ba'zi arxiv jadvallarini qandaydir "sovuq" arxivga, SATA drayverlariga ko'chirish mumkin va ular o'sha erda yashashlariga ruxsat berishlari mumkin, kerak bo'lganda ularga kirish mumkin bo'ladi.
Bu har qanday relizlar va tarqatishdan keyin anomaliyalarni aniqlash uchun ham foydalidir. Aytaylik, loyiha yangi xususiyatni chiqardi. Masalan, biz ma'lumotlar bazasi bilan ishlash uchun yangi funksiyalarni qo'shdik. Va agar jadvaldan foydalanish grafiklarini tuzadigan bo'lsak, ushbu grafiklarda bu anomaliyalarni osongina aniqlashimiz mumkin. Masalan, portlashlarni yangilash yoki portlashlarni o'chirish. Bu juda ko'rinadigan bo'ladi.
Shuningdek, siz "suzuvchi" statistikada anomaliyalarni aniqlashingiz mumkin. Bu nima degani? PostgreSQL juda kuchli va juda yaxshi so'rovlar rejalashtiruvchisiga ega. Va ishlab chiquvchilar uning rivojlanishiga ko'p vaqt ajratadilar. U qanday ishlaydi? Yaxshi rejalar tuzish uchun PostgreSQL ma'lum vaqt oralig'ida va ma'lum bir chastotada jadvallardagi ma'lumotlarni taqsimlash bo'yicha statistik ma'lumotlarni to'playdi. Bular eng keng tarqalgan qiymatlar: noyob qiymatlar soni, jadvaldagi NULL haqidagi ma'lumotlar, ko'plab ma'lumotlar.
Ushbu statistik ma'lumotlarga asoslanib, rejalashtiruvchi bir nechta so'rovlarni tuzadi, eng maqbulini tanlaydi va so'rovning o'zini bajarish va ma'lumotlarni qaytarish uchun ushbu so'rov rejasidan foydalanadi.
Va shunday bo'ladiki, statistika "suzadi". Jadvalda sifat va miqdor ma'lumotlari qandaydir tarzda o'zgargan, ammo statistika yig'ilmagan. Va tuzilgan rejalar optimal bo'lmasligi mumkin. Va agar bizning rejalarimiz to'plangan monitoring asosida, jadvallar asosida suboptimal bo'lib chiqsa, biz bu anomaliyalarni ko'rishimiz mumkin bo'ladi. Masalan, biror joyda ma'lumotlar sifat jihatidan o'zgardi va indeks o'rniga jadval orqali ketma-ket o'tish ishlatila boshlandi, ya'ni. agar so'rov faqat 100 ta satrni qaytarishi kerak bo'lsa (100 ta chegara mavjud), bu so'rov uchun to'liq qidiruv amalga oshiriladi. Va bu har doim ishlashga juda yomon ta'sir qiladi.
Biz buni monitoringda ko'rishimiz mumkin. Va allaqachon ushbu so'rovni ko'rib chiqing, buning uchun tushuntirishni bajaring, statistik ma'lumotlarni to'plang, yangi qo'shimcha indeks yarating. Va bu muammoga allaqachon javob bering. Shuning uchun bu muhim.
Monitoringning yana bir misoli. O'ylaymanki, ko'pchilik uni tanidi, chunki u juda mashhur. Kim o'z loyihalarida foydalanadi ? Ushbu mahsulotni Prometey bilan birgalikda kim ishlatadi? Gap shundaki, ushbu monitoringning standart omborida PostgreSQL bilan ishlash uchun asboblar paneli mavjud - Prometey. Ammo bitta yomon tafsilot bor.
Bir nechta grafikalar mavjud. Va baytlar birlik sifatida ko'rsatilgan, ya'ni 5 ta grafik mavjud. Bular ma'lumotlarni kiritish, ma'lumotlarni yangilash, ma'lumotlarni o'chirish, ma'lumotlarni olish va ma'lumotlarni qaytarish. O'lchov birligi baytdir. Gap shundaki, PostgreSQL-dagi statistika ma'lumotlarni kortejda (qatorlarda) qaytaradi. Va shunga ko'ra, bu grafiklar sizning ish yukingizni bir necha marta, o'nlab marta kam baholashning juda yaxshi usulidir, chunki kortej bayt emas, kortej - satr, u ko'p bayt va u har doim o'zgaruvchan uzunlikda. Ya'ni, kortejlar yordamida baytlardagi ish yukini hisoblash haqiqiy bo'lmagan vazifa yoki juda qiyin. Shuning uchun, asboblar paneli yoki o'rnatilgan monitoringdan foydalanganda, uning to'g'ri ishlashini va sizga to'g'ri baholangan ma'lumotlarni qaytarishini tushunish har doim muhimdir.
Ushbu jadvallar bo'yicha statistik ma'lumotlarni qanday olish mumkin? Shu maqsadda PostgreSQL ma'lum qarashlar oilasiga ega. Va asosiy ko'rinish . User_tables foydalanuvchi nomidan tuzilgan jadvallarni bildiradi. Bundan farqli o'laroq, PostgreSQL tomonidan ishlatiladigan tizim ko'rinishlari mavjud. Va tizim va foydalanuvchi jadvallarini o'z ichiga olgan Alltables umumiy jadvali mavjud. Ulardan o'zingizga ko'proq yoqqanidan boshlashingiz mumkin.
Yuqoridagi maydonlar yordamida siz qo'shimchalar, yangilanishlar va o'chirishlar sonini taxmin qilishingiz mumkin. Men ishlatgan asboblar paneli misolida ish yukining xususiyatlarini baholash uchun ushbu maydonlardan foydalaniladi. Shuning uchun, biz ham ular asosida qurishimiz mumkin. Ammo shuni esda tutish kerakki, bu baytlar emas, kortejlar, shuning uchun biz buni faqat baytlarda qila olmaymiz.
Ushbu ma'lumotlarga asoslanib, biz TopN deb ataladigan jadvallarni yaratishimiz mumkin. Masalan, Top-5, Top-10. Va siz boshqalarga qaraganda ko'proq qayta ishlangan issiq stollarni kuzatishingiz mumkin. Masalan, kiritish uchun 5 ta "issiq" jadval. Va ushbu TopN jadvallaridan foydalanib, biz ish yukimizni baholaymiz va har qanday relizlar, yangilanishlar va joylashtirishlardan keyin ish yukining portlashini baholashimiz mumkin.
Jadvalning o'lchamini baholash ham muhim, chunki ba'zida ishlab chiquvchilar yangi xususiyatni chiqaradilar va bizning jadvallarimiz katta o'lchamlarda shishiradi, chunki ular qo'shimcha ma'lumotlar miqdorini qo'shishga qaror qilishdi, lekin bu qanday bo'lishini oldindan aytishmadi. ma'lumotlar bazasi hajmiga ta'sir qiladi. Bunday holatlar bizni ham ajablantiradi.
Va endi sizga kichik bir savol. Ma'lumotlar bazasi serveriga yuklanishni sezganingizda qanday savol tug'iladi? Keyingi savolingiz nima?
Ammo aslida savol quyidagicha tug'iladi. Yuk qanday so'rovlarni keltirib chiqaradi? Ya'ni, yuk tufayli yuzaga keladigan jarayonlarga qarash qiziq emas. Ma'lumki, agar xostda ma'lumotlar bazasi mavjud bo'lsa, unda ma'lumotlar bazasi u erda ishlaydi va u erda faqat ma'lumotlar bazalari utilizatsiya qilinishi aniq. Agar biz Topni ochsak, u erda PostgreSQL-da nimadir qilayotgan jarayonlar ro'yxatini ko'ramiz. Ular nima qilayotgani Topdan aniq bo'lmaydi.
Shunga ko'ra, siz eng yuqori yukni keltirib chiqaradigan so'rovlarni topishingiz kerak, chunki sozlash so'rovlari, qoida tariqasida, PostgreSQL yoki operatsion tizim konfiguratsiyasini sozlashdan yoki hatto apparatni sozlashdan ko'ra ko'proq foyda keltiradi. Mening taxminlarimga ko'ra, bu taxminan 80-85-90% ni tashkil qiladi. Va bu juda tez amalga oshiriladi. So'rovni tuzatish konfiguratsiyani tuzatish, qayta ishga tushirishni rejalashtirish, ayniqsa ma'lumotlar bazasini qayta ishga tushirish yoki apparat qo'shishdan ko'ra tezroq. Bu so'rovdan yaxshiroq natijaga erishish uchun so'rovni biror joyda qayta yozish yoki indeks qo'shish osonroq.
Shunga ko'ra, so'rovlar va ularning etarliligini nazorat qilish kerak. Monitoringning yana bir misolini olaylik. Va bu erda ham ajoyib monitoring borga o'xshaydi. Replikatsiya haqida ma'lumot mavjud, o'tkazish qobiliyati, blokirovka qilish, resurslardan foydalanish haqida ma'lumot mavjud. Hammasi yaxshi, lekin so'rovlar haqida hech qanday ma'lumot yo'q. Bizning ma'lumotlar bazamizda qanday so'rovlar ishlayotgani, ular qancha davom etayotgani, bu so'rovlarning qanchasi aniq emas. Biz har doim monitoringimizda ushbu ma'lumotga ega bo'lishimiz kerak.
Va bu ma'lumotni olish uchun pg_stat_statements modulidan foydalanishimiz mumkin. Unga asoslanib, siz turli xil grafikalar yaratishingiz mumkin. Masalan, siz eng tez-tez uchraydigan so'rovlar, ya'ni tez-tez bajariladigan so'rovlar haqida ma'lumot olishingiz mumkin. Ha, joylashtirishdan so'ng, uni ko'rib chiqish va so'rovlar ko'payganligini tushunish juda foydali.
Siz eng uzun so'rovlarni, ya'ni bajarish uchun eng uzoq vaqt talab qiladigan so'rovlarni kuzatishingiz mumkin. Ular protsessorda ishlaydi, kiritish/chiqarishni iste'mol qiladi. Buni total_time, mean_time, blk_write_time va blk_read_time maydonlari yordamida ham baholashimiz mumkin.
Biz resurslardan foydalanish nuqtai nazaridan eng og'ir so'rovlarni, diskdan o'qiydigan, xotira bilan ishlaydigan yoki aksincha, qandaydir yozish yukini yaratadigan so'rovlarni baholashimiz va kuzatishimiz mumkin.
Biz eng saxiy so'rovlarni baholashimiz mumkin. Bular ko'p sonli qatorlarni qaytaradigan so'rovlardir. Misol uchun, bu chegara o'rnatishni unutgan ba'zi so'rov bo'lishi mumkin. Va u shunchaki jadvalning butun mazmunini yoki so'ralgan jadvallar bo'ylab so'rovni qaytaradi.
Shuningdek, siz vaqtinchalik fayllar yoki vaqtinchalik jadvallardan foydalanadigan so'rovlarni kuzatishingiz mumkin.
Va bizda hali ham fon jarayonlari mavjud. Fon jarayonlari birinchi navbatda nazorat punktlari yoki ular nazorat punktlari deb ham ataladi, bular avtovakuum va replikatsiya.
Monitoringning yana bir misoli. Chap tomonda Xizmat ko'rsatish yorlig'i mavjud, unga o'ting va foydali narsalarni ko'rishga umid qiling. Ammo bu erda faqat vakuum operatsiyasi va statistika yig'ish vaqti, boshqa hech narsa yo'q. Bu juda yomon ma'lumot, shuning uchun biz doimo ma'lumotlar bazamizda fon jarayonlari qanday ishlashi va ularning ishida muammolar bor-yo'qligi haqida ma'lumotga ega bo'lishimiz kerak.
Tekshirish punktlarini ko'rib chiqsak, tekshirish punktlari iflos sahifalarni parchalangan xotira maydonidan diskka olib tashlashini, keyin esa nazorat nuqtasini yaratishini yodda tutishimiz kerak. Va agar PostgreSQL favqulodda vaziyatda to'satdan to'xtatilgan bo'lsa, ushbu nazorat punkti tiklanish joyi sifatida ishlatilishi mumkin.
Shunga ko'ra, barcha "iflos" sahifalarni diskka tushirish uchun siz ma'lum miqdorda yozishingiz kerak. Va, qoida tariqasida, katta hajmdagi xotiraga ega tizimlarda bu juda ko'p. Va agar biz qisqa vaqt oralig'ida nazorat punktlarini tez-tez bajarsak, unda diskning ishlashi juda sezilarli darajada pasayadi. Mijozlarning so'rovlari esa resurslar etishmasligidan aziyat chekadi. Ular resurslar uchun raqobatlashadilar va unumdorlikdan mahrum bo'lishadi.
Shunga ko'ra, ko'rsatilgan maydonlar yordamida pg_stat_bgwriter orqali biz sodir bo'lgan nazorat nuqtalari sonini kuzatishimiz mumkin. Va agar bizda ma'lum bir vaqt ichida (10-15-20 daqiqada, yarim soat ichida) ko'plab nazorat punktlari bo'lsa, masalan, 3-4-5, bu allaqachon muammo bo'lishi mumkin. Va siz allaqachon ma'lumotlar bazasiga qarashingiz, konfiguratsiyaga qarashingiz kerak, bunday nazorat punktlarining ko'pligiga nima sabab bo'ladi. Ehtimol, qandaydir katta yozuvlar ketayotgandir. Biz allaqachon ish yukini baholashimiz mumkin, chunki biz allaqachon ish yuki grafiklarini qo'shdik. Biz allaqachon nazorat nuqtasi parametrlarini o'zgartirishimiz va ular so'rovlar ishlashiga katta ta'sir qilmasligiga ishonch hosil qilishimiz mumkin.
Men yana avtovakuumga qaytyapman, chunki bu, aytganimdek, disk va so'rovlar unumdorligini osongina qo'shishi mumkin, shuning uchun avtovakuum miqdorini hisoblash har doim muhim.
Ma'lumotlar bazasida avtovakuum ishchilari soni cheklangan. Odatiy bo'lib, ularning uchtasi bor, shuning uchun bizda har doim ma'lumotlar bazasida uchta ishchi ishlayotgan bo'lsa, bu bizning avtovakuumimiz noto'g'ri sozlanganligini anglatadi, biz cheklovlarni oshirishimiz, avtovakuum sozlamalarini qayta ko'rib chiqishimiz va konfiguratsiyaga kirishimiz kerak.
Bizda qaysi vakuum ishchilari borligini baholash muhimdir. Yoki u foydalanuvchidan ishga tushirildi, DBA keldi va qo'lda qandaydir vakuumni ishga tushirdi va bu yukni yaratdi. Bizda qandaydir muammo bor. Yoki bu tranzaksiya hisoblagichini ochadigan vakuumlar soni. PostgreSQL ning ba'zi versiyalari uchun bu juda og'ir vakuumlar. Va ular ishlashni osongina qo'shishlari mumkin, chunki ular butun jadvalni o'qiydilar, ushbu jadvaldagi barcha bloklarni skanerlaydilar.
Va, albatta, vakuumlarning davomiyligi. Agar bizda juda uzoq vaqt ishlaydigan uzoq muddatli vakuumlar bo'lsa, bu biz yana vakuum konfiguratsiyasiga e'tibor berishimiz va ehtimol uning sozlamalarini qayta ko'rib chiqishimiz kerakligini anglatadi. Vakuum stolda uzoq vaqt (3-4 soat) ishlaganda vaziyat yuzaga kelishi mumkinligi sababli, vakuum ishlagan vaqt ichida stolda yana ko'p miqdorda o'lik qatorlar to'planishiga muvaffaq bo'ldi. Va vakuum tugashi bilan u yana bu stolni changyutkichdan tozalashi kerak. Va biz bir vaziyatga keldik - cheksiz vakuum. Va bu holda, vakuum o'z ishiga dosh berolmaydi va jadvallar asta-sekin kattalasha boshlaydi, garchi undagi foydali ma'lumotlar hajmi bir xil bo'lib qoladi. Shuning uchun, uzoq vaqt changyutgichlar paytida biz har doim konfiguratsiyani ko'rib chiqamiz va uni optimallashtirishga harakat qilamiz, lekin shu bilan birga mijoz so'rovlarining bajarilishi zarar ko'rmaydi.
Hozirgi vaqtda oqimli replikatsiyaga ega bo'lmagan PostgreSQL o'rnatish deyarli yo'q. Replikatsiya - bu ma'lumotlarni masterdan replikaga o'tkazish jarayoni.
PostgreSQL-da replikatsiya tranzaksiya jurnali orqali amalga oshiriladi. Sehrgar tranzaksiya jurnalini yaratadi. Tranzaktsiyalar jurnali tarmoq ulanishi orqali replikaga o'tadi va keyin u replikada qayta ishlab chiqariladi. Hammasi oddiy.
Shunga ko'ra, pg_stat_replication ko'rinishi replikatsiya kechikishini kuzatish uchun ishlatiladi. Ammo u bilan hamma narsa oddiy emas. 10-versiyada ko'rinish bir nechta o'zgarishlarga duch keldi. Birinchidan, ba'zi maydonlar nomi o'zgartirildi. Va ba'zi maydonlar qo'shildi. 10-versiyada takrorlashning kechikishini soniyalarda baholashga imkon beruvchi maydonlar paydo bo'ldi. Bu juda qulay. 10-versiyadan oldin replikatsiya kechikishini baytlarda baholash mumkin edi. Ushbu parametr 10-versiyada qoladi, ya'ni siz o'zingiz uchun qulayroq bo'lgan narsani tanlashingiz mumkin - kechikishni baytlarda baholang yoki kechikishni soniyalarda baholang. Ko'pchilik ikkalasini ham qiladi.
Ammo shunga qaramay, replikatsiya kechikishini baholash uchun siz tranzaktsiyadagi jurnalning o'rnini bilishingiz kerak. Va bu tranzaktsiyalar jurnali pozitsiyalari aynan pg_stat_replication ko'rinishida. Nisbatan aytganda, biz pg_xlog_location_diff() funksiyasidan foydalangan holda tranzaktsiyalar jurnalida ikkita nuqtani olishimiz mumkin. Ularning orasidagi deltani hisoblang va replikatsiya kechikishini baytlarda oling. Bu juda qulay va sodda.
10-versiyada bu funksiya pg_wal_lsn_diff() ga o‘zgartirildi. Umuman olganda, "xlog" so'zi paydo bo'lgan barcha funktsiyalar, ko'rinishlar va yordamchi dasturlarda u "wal" qiymati bilan almashtirildi. Bu ikkala ko'rinishga ham, funksiyalarga ham tegishli. Bu shunday yangilik.
Bundan tashqari, 10-versiyada, ayniqsa, kechikishni ko'rsatadigan chiziqlar qo'shildi. Bular yozish kechikishi, flush lag, takroriy lag. Ya'ni, bu narsalarni kuzatib borish muhimdir. Agar bizda replikatsiya kechikishi borligini ko'rsak, u nima uchun paydo bo'lganini, qaerdan kelganini o'rganishimiz va muammoni hal qilishimiz kerak.
Tizim ko'rsatkichlari bilan deyarli hamma narsa tartibda. Har qanday monitoring boshlanganda, u tizim ko'rsatkichlaridan boshlanadi. Bu protsessorlarni, xotirani, almashtirishni, tarmoqni va diskni tasarruf etishdir. Biroq, ko'pgina parametrlar sukut bo'yicha mavjud emas.
Agar qayta ishlash jarayonida hamma narsa tartibda bo'lsa, unda diskni qayta ishlash bilan bog'liq muammolar mavjud. Qoida tariqasida, monitoring ishlab chiquvchilari o'tkazish qobiliyati haqida ma'lumot qo'shadilar. U iops yoki baytlarda bo'lishi mumkin. Ammo ular kechikish va disk qurilmalaridan foydalanishni unutishadi. Bu bizning disklarimiz qanchalik yuklanganligini va qanchalik sekinligini baholashga imkon beruvchi muhimroq parametrlardir. Agar bizda yuqori kechikish bo'lsa, bu disklarda ba'zi muammolar mavjudligini anglatadi. Agar bizda yuqori darajada foydalanish bo'lsa, bu disklar bardosh bera olmasligini anglatadi. Bu o'tkazish qobiliyatiga qaraganda yaxshiroq xususiyatlar.
Bundan tashqari, ushbu statistikani qayta ishlash protsessorlari uchun bo'lgani kabi /proc fayl tizimidan ham olish mumkin. Nima uchun bu ma'lumot monitoringga qo'shilmaganini bilmayman. Ammo shunga qaramay, bu sizning monitoringingizda bo'lishi muhimdir.
Xuddi shu narsa tarmoq interfeyslari uchun ham amal qiladi. Paketlarda, baytlarda tarmoq o'tkazuvchanligi haqida ma'lumot mavjud, ammo shunga qaramay, kechikish haqida ma'lumot va foydalanish haqida ma'lumot yo'q, garchi bu ham foydali ma'lumotdir.
Har qanday monitoringning kamchiliklari bor. Va qanday monitoring o'tkazmasligingizdan qat'i nazar, u har doim ham ba'zi mezonlarga javob bermaydi. Ammo shunga qaramay, ular rivojlanmoqda, yangi xususiyatlar va yangi narsalar qo'shilmoqda, shuning uchun biror narsani tanlang va uni tugating.
Va tugatish uchun siz har doim taqdim etilgan statistik ma'lumotlar nimani anglatishini va ularni muammolarni hal qilish uchun qanday ishlatishingiz haqida tasavvurga ega bo'lishingiz kerak.
Va bir nechta asosiy fikrlar:
- Ma'lumotlar bazasi bilan hamma narsa tartibda ekanligini tezda baholashingiz uchun siz doimo mavjudligini kuzatib borishingiz va asboblar paneliga ega bo'lishingiz kerak.
- Yomon mijozlarni yo'q qilish va ularni yo'q qilish uchun har doim ma'lumotlar bazasi bilan qanday mijozlar ishlayotgani haqida tasavvurga ega bo'lishingiz kerak.
- Ushbu mijozlar ma'lumotlar bilan qanday ishlashini baholash muhimdir. Sizning ish yukingiz haqida tasavvurga ega bo'lishingiz kerak.
- Bu ish yuki qanday shakllanganligini, qanday so'rovlar yordamida baholash muhimdir. Siz so'rovlarni baholashingiz, ularni optimallashtirishingiz, qayta ishlashingiz, ular uchun indekslar yaratishingiz mumkin. Bu juda muhim.
- Orqa fon jarayonlari mijozlar so'rovlariga salbiy ta'sir ko'rsatishi mumkin, shuning uchun ular juda ko'p resurslardan foydalanmayotganini kuzatish muhimdir.
- Tizim ko'rsatkichlari sizning serverlaringiz hajmini kengaytirish va oshirish rejalarini tuzishga imkon beradi, shuning uchun ularni kuzatish va baholash ham muhimdir.
Agar siz ushbu mavzuga qiziqsangiz, ushbu havolalarga o'tishingiz mumkin.
- bu statistika yig'uvchining rasmiy hujjatlari. Barcha statistik ko'rinishlarning tavsifi va barcha sohalarning tavsifi mavjud. Siz ularni o'qishingiz, tushunishingiz va tahlil qilishingiz mumkin. Va ularga asoslanib, grafiklaringizni yarating va ularni monitoringingizga qo'shing.
So'rov misollari:
Bu bizning korporativ omborimiz va meniki. Ular misol so'rovlarini o'z ichiga oladi. U yerda seriyadan tanlash* dan soʻrovlar yoʻq. Xom raqamlarni o'qilishi mumkin bo'lgan, qulay qiymatlarga aylantirish imkonini beruvchi qiziqarli funktsiyalardan foydalangan holda birlashma bilan allaqachon tayyor so'rovlar mavjud, ya'ni bu baytlar, vaqt. Siz ularni tanlashingiz, ko'rishingiz, tahlil qilishingiz, monitoringingizga qo'shishingiz va ularga asoslangan holda monitoringingizni qurishingiz mumkin.
Sizning savollaringiz
Savol: Siz brendlarni reklama qilmasligingizni aytdingiz, lekin men hali ham qiziqaman - loyihalaringizda qanday asboblar panelidan foydalanasiz?
Javob: Bu farq qiladi. Biz mijozga kelamiz va u allaqachon o'z monitoringiga ega. Va biz mijozga ularning monitoringiga nima qo'shilishi kerakligi haqida maslahat beramiz. Eng yomon vaziyat Zabbix bilan bog'liq. Chunki u TopN grafiklarini yaratish qobiliyatiga ega emas. Biz o'zimiz foydalanamiz , chunki biz bu bolalar bilan monitoring bo'yicha maslahatlashgan edik. Ular bizning texnik xususiyatlarimiz asosida PostgreSQLni kuzatib borishdi. Men Prometey orqali ma'lumotlarni to'playdigan va uni taqdim etadigan o'z uy hayvonlari loyihasini yozyapman . Mening vazifam Prometeyda o'z eksporterimni yaratish va keyin hamma narsani Grafana'da ko'rsatishdir.
Savol: AWR hisobotlarining analoglari yoki ... yig'ish bormi? Siz shunga o'xshash narsa haqida bilasizmi?
Javob: Ha, men AWR nima ekanligini bilaman, bu ajoyib narsa. Hozirgi vaqtda taxminan quyidagi modelni amalga oshiradigan turli xil velosipedlar mavjud. Ba'zi bir vaqt oralig'ida, ba'zi bir asosiy chiziqlar bir xil PostgreSQL yoki alohida xotiraga yoziladi. Siz ularni Internetda google qilishingiz mumkin, ular o'sha erda. Bunday narsani ishlab chiquvchilardan biri PostgreSQL mavzusidagi sql.ru forumida o'tiradi. Siz uni o'sha erda qo'lga olishingiz mumkin. Ha, shunday narsalar bor, ulardan foydalanish mumkin. Bundan tashqari, uning ichida Men ham xuddi shu narsani qilishga imkon beradigan narsani yozyapman.
P.S.1 Agar siz postgres_exporter dan foydalansangiz, qaysi asboblar panelidan foydalanasiz? Ulardan bir nechtasi bor. Ular allaqachon eskirgan. Balki jamiyat yangilangan shablonni yaratadi?
P.S.2 Pganalyze olib tashlandi, chunki u ishlash monitoringi va avtomatlashtirilgan sozlash takliflariga qaratilgan xususiy SaaS taklifidir.
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Qaysi mustaqil postgresql monitoringi (boshqaruv paneli bilan) siz eng yaxshi deb hisoblaysiz?
-
30,0%Zabbix + Aleksey Lesovskiy yoki zabbix 4.4 yoki libzbxpgsql + zabbix libzbxpgsql + zabbix3 qo'shimchalari
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%pganalyze - bu xususiy SaaS - men uni o'chira olmayman1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
10 foydalanuvchi ovoz berdi. 26 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com