PostgreSQL მონიტორინგის საფუძვლები. ალექსეი ლესოვსკი

მე გთავაზობთ წაიკითხოთ ალექსეი ლესოვსკის მოხსენების ტრანსკრიპტი Data Egret-დან "PostgreSQL მონიტორინგის საფუძვლები"

ამ მოხსენებაში ალექსეი ლესოვსკი ისაუბრებს პოსტგრესიული სტატისტიკის ძირითად პუნქტებზე, რას გულისხმობენ ისინი და რატომ უნდა იყვნენ წარმოდგენილი მონიტორინგში; იმის შესახებ, თუ რა გრაფიკები უნდა იყოს მონიტორინგში, როგორ დავამატოთ ისინი და როგორ მოხდეს მათი ინტერპრეტაცია. ანგარიში სასარგებლო იქნება მონაცემთა ბაზის ადმინისტრატორებისთვის, სისტემის ადმინისტრატორებისთვის და დეველოპერებისთვის, რომლებიც დაინტერესებულნი არიან Postgres-ის პრობლემების მოგვარებით.

მე მქვია ალექსეი ლესოვსკი, წარმოვადგენ დათა ეგრეტის კომპანიას.

რამდენიმე სიტყვა ჩემს შესახებ. დიდი ხნის წინ დავიწყე მუშაობა, როგორც სისტემის ადმინისტრატორი.

მე ვმართავდი ყველა სახის Linux სისტემას, ვმუშაობდი Linux-თან დაკავშირებულ სხვადასხვა საკითხებზე, მაგ. ვირტუალიზაციაზე, მონიტორინგზე, ვმუშაობდი პროქსიებთან და ა.შ. მაგრამ რაღაც მომენტში დავიწყე უფრო მეტი მუშაობა მონაცემთა ბაზებთან, PostgreSQL-თან. მე ის ძალიან მომეწონა. და რაღაც მომენტში დავიწყე მუშაობა PostgreSQL-ზე ჩემი სამუშაო დროის უმეტესი ნაწილი. და ასე თანდათან გავხდი PostgreSQL DBA.

და მთელი ჩემი კარიერის განმავლობაში ყოველთვის მაინტერესებდა სტატისტიკის, მონიტორინგისა და ტელემეტრიის თემები. და როდესაც სისტემის ადმინისტრატორი ვიყავი, ძალიან მჭიდროდ ვმუშაობდი Zabbix-თან. და დავწერე სკრიპტების მცირე ნაკრები, როგორიცაა zabbix- გაფართოებები. თავის დროზე საკმაოდ პოპულარული იყო. და იქ შესაძლებელი იყო ძალიან განსხვავებული მნიშვნელოვანი ნივთების მონიტორინგი, არა მხოლოდ Linux, არამედ სხვადასხვა კომპონენტები.

ახლა ვმუშაობ PostgreSQL-ზე. მე უკვე ვწერ სხვა რამეს, რომელიც საშუალებას გაძლევთ იმუშაოთ PostgreSQL სტატისტიკასთან. მას ეძახიან pgCenter (სტატია Habré-ზე - პოსტ-გრესის სტატისტიკა ნერვებისა და დაძაბულობის გარეშე).

პატარა შესავალი შენიშვნა. რა სიტუაციები აქვთ ჩვენს მომხმარებლებს, ჩვენს კლიენტებს? არის ერთგვარი უბედური შემთხვევა, რომელიც დაკავშირებულია მონაცემთა ბაზასთან. და როდესაც მონაცემთა ბაზა უკვე აღდგენილია, მოდის განყოფილების უფროსი ან განვითარების უფროსი და ამბობს: „მეგობრებო, ჩვენ უნდა დავაკვირდეთ მონაცემთა ბაზას, რადგან რაღაც ცუდი მოხდა და ეს მომავალში არ მოხდეს“. და აქ იწყება მონიტორინგის სისტემის არჩევის ან არსებული მონიტორინგის სისტემის ადაპტაციის საინტერესო პროცესი, რათა შეძლოთ თქვენი მონაცემთა ბაზის მონიტორინგი - PostgreSQL, MySQL ან სხვა. და კოლეგები იწყებენ შეთავაზებას: ”მე გავიგე, რომ არსებობს ასეთი და ასეთი მონაცემთა ბაზა. გამოვიყენოთ“. კოლეგები იწყებენ კამათს ერთმანეთთან. და ბოლოს გამოდის, რომ ჩვენ ვირჩევთ რაიმე სახის მონაცემთა ბაზას, მაგრამ PostgreSQL მონიტორინგი მასში საკმაოდ ცუდად არის წარმოდგენილი და ყოველთვის რაღაცის დამატება გვიწევს. აიღეთ რამდენიმე საცავი GitHub-დან, მოახდინე მათი კლონირება, სკრიპტების ადაპტირება და როგორმე მათი მორგება. და ბოლოს ეს მთავრდება რაღაც სახის ხელით სამუშაოდ.

ამიტომ, ამ განხილვაში შევეცდები მოგცეთ გარკვეული ცოდნა, თუ როგორ უნდა აირჩიოთ მონიტორინგი არა მხოლოდ PostgreSQL-ისთვის, არამედ მონაცემთა ბაზისთვის. და მოგცემთ ცოდნას, რომელიც საშუალებას მოგცემთ დაასრულოთ თქვენი მონიტორინგი, რათა მიიღოთ გარკვეული სარგებელი მისგან, რათა შეძლოთ თქვენი მონაცემთა ბაზის მონიტორინგი, რათა დროულად თავიდან აიცილოთ ნებისმიერი მომავალი საგანგებო სიტუაცია, რომელიც შეიძლება წარმოიშვას.

და იდეები, რომლებიც იქნება ამ ანგარიშში, შეიძლება პირდაპირ მოერგოს ნებისმიერ მონაცემთა ბაზას, იქნება ეს DBMS თუ noSQL. აქედან გამომდინარე, არ არის მხოლოდ PostgreSQL, არამედ იქნება მრავალი რეცეპტი, თუ როგორ უნდა გავაკეთოთ ეს PostgreSQL-ში. იქნება მოთხოვნის მაგალითები, სუბიექტების მაგალითები, რომლებიც PostgreSQL-ს აქვს მონიტორინგისთვის. და თუ თქვენს DBMS-ს აქვს იგივე რაღაცეები რაც მონიტორინგში ჩასმის საშუალებას გაძლევს, შენც შეგიძლია მოარგო, დაამატო და კარგი იქნება.

მე არ ვიქნები ანგარიშში
ისაუბრეთ მეტრიკის მიწოდებისა და შენახვის შესახებ. მონაცემების შემდგომ დამუშავებაზე და მომხმარებლისთვის წარდგენაზე არაფერს ვიტყვი. და მე არაფერს ვიტყვი გაფრთხილებაზე.
მაგრამ სიუჟეტის წინსვლისას მე ვაჩვენებ არსებული მონიტორინგის სხვადასხვა სკრინშოტს და როგორმე გავაკრიტიკებ მათ. მაგრამ მიუხედავად ამისა, ვეცდები არ დავასახელო ბრენდები, რომ არ შევქმნა ამ პროდუქტების რეკლამა ან ანტირეკლამა. ამიტომ, ყველა დამთხვევა შემთხვევითია და თქვენს ფანტაზიაზეა დარჩენილი.

პირველ რიგში, მოდით გაერკვნენ, რა არის მონიტორინგი. მონიტორინგი ძალიან მნიშვნელოვანი რამ არის. ეს ყველას ესმის. მაგრამ ამავე დროს, მონიტორინგი არ ეხება ბიზნეს პროდუქტს და პირდაპირ არ მოქმედებს კომპანიის მოგებაზე, ამიტომ დრო ყოველთვის ეთმობა მონიტორინგს ნარჩენ საფუძველზე. თუ დრო გვექნება, მაშინ ვაკეთებთ მონიტორინგს; თუ დრო არ გვექნება, მაშინ კარგი, ჩავდებთ მას და ოდესღაც ამ ამოცანებს დავუბრუნდებით.

ამიტომ, ჩვენი პრაქტიკიდან გამომდინარე, როცა კლიენტებთან მივდივართ, მონიტორინგი ხშირად არასრულია და არ გააჩნია რაიმე საინტერესო, რაც დაგვეხმარება მონაცემთა ბაზის უკეთ შესრულებაში. და ამიტომ მონიტორინგი ყოველთვის უნდა დასრულდეს.

მონაცემთა ბაზები ისეთი რთული საგნებია, რომელთა მონიტორინგიც საჭიროა, რადგან მონაცემთა ბაზები ინფორმაციის საცავია. და ინფორმაცია ძალიან მნიშვნელოვანია კომპანიისთვის, მისი დაკარგვა არანაირად არ შეიძლება. მაგრამ ამავე დროს, მონაცემთა ბაზები ძალიან რთული პროგრამული უზრუნველყოფის ნაწილია. ისინი შედგება დიდი რაოდენობით კომპონენტებისგან. და ამ კომპონენტებიდან ბევრი უნდა იყოს მონიტორინგი.

თუ კონკრეტულად ვსაუბრობთ PostgreSQL-ზე, მაშინ ის შეიძლება წარმოდგენილი იყოს სქემის სახით, რომელიც შედგება დიდი რაოდენობით კომპონენტებისგან. ეს კომპონენტები ურთიერთქმედებენ ერთმანეთთან. და ამავდროულად, PostgreSQL-ს აქვს ეგრეთ წოდებული Stats Collector ქვესისტემა, რომელიც საშუალებას გაძლევთ შეაგროვოთ სტატისტიკა ამ ქვესისტემების მუშაობის შესახებ და მიაწოდოთ რაიმე სახის ინტერფეისი ადმინისტრატორს ან მომხმარებელს, რათა მან შეძლოს ამ სტატისტიკის ნახვა.

ეს სტატისტიკა წარმოდგენილია გარკვეული ფუნქციებისა და შეხედულებების სახით. მათ ასევე შეიძლება ეწოდოს ცხრილები. ანუ, ჩვეულებრივი psql კლიენტის გამოყენებით, შეგიძლიათ დაუკავშირდეთ მონაცემთა ბაზას, გააკეთოთ არჩევანი ამ ფუნქციებსა და ხედებზე და მიიღოთ რამდენიმე კონკრეტული რიცხვი PostgreSQL ქვესისტემების მუშაობის შესახებ.

თქვენ შეგიძლიათ დაამატოთ ეს რიცხვები თქვენს საყვარელ მონიტორინგის სისტემაში, დახაზოთ გრაფიკები, დაამატოთ ფუნქციები და მიიღოთ ანალიტიკა გრძელვადიან პერსპექტივაში.

მაგრამ ამ მოხსენებაში მე არ გავაშუქებ ყველა ამ ფუნქციას მთლიანად, რადგან ამას შეიძლება მთელი დღე დასჭირდეს. მე სიტყვასიტყვით მივმართავ ორ, სამ ან ოთხ საკითხს და გეტყვით, თუ როგორ ეხმარება ისინი მონიტორინგის გაუმჯობესებას.

და თუ ვსაუბრობთ მონაცემთა ბაზის მონიტორინგზე, მაშინ რისი მონიტორინგია საჭირო? უპირველეს ყოვლისა, ჩვენ უნდა ვაკონტროლოთ ხელმისაწვდომობა, რადგან მონაცემთა ბაზა არის სერვისი, რომელიც უზრუნველყოფს კლიენტებს მონაცემებზე წვდომას და ჩვენ უნდა ვაკონტროლოთ ხელმისაწვდომობა, ასევე მივაწოდოთ მისი ზოგიერთი თვისებრივი და რაოდენობრივი მახასიათებლები.

ჩვენ ასევე უნდა დავაკვირდეთ კლიენტებს, რომლებიც უკავშირდებიან ჩვენს მონაცემთა ბაზას, რადგან ისინი შეიძლება იყვნენ როგორც ჩვეულებრივი კლიენტები, ასევე მავნე კლიენტები, რომლებმაც შეიძლება ზიანი მიაყენონ მონაცემთა ბაზას. მათ ასევე სჭირდებათ მონიტორინგი და მათი საქმიანობის თვალყურის დევნება.

როდესაც კლიენტები უკავშირდებიან მონაცემთა ბაზას, აშკარაა, რომ ისინი იწყებენ მუშაობას ჩვენს მონაცემებთან, ამიტომ ჩვენ უნდა დავაკვირდეთ, თუ როგორ მუშაობენ კლიენტები მონაცემებთან: რომელ ცხრილებთან და ნაკლებად, რომელ ინდექსებთან. ანუ, ჩვენ უნდა შევაფასოთ ის დატვირთვა, რომელიც იქმნება ჩვენი კლიენტების მიერ.

მაგრამ დატვირთვა ასევე შედგება, რა თქმა უნდა, მოთხოვნებისგან. აპლიკაციები უკავშირდებიან მონაცემთა ბაზას, წვდებიან მონაცემებს შეკითხვის გამოყენებით, ამიტომ მნიშვნელოვანია შევაფასოთ რა მოთხოვნები გვაქვს მონაცემთა ბაზაში, დავაკვირდეთ მათ ადეკვატურობას, რომ ისინი არასწორად არის დაწერილი, რომ ზოგიერთი ვარიანტი უნდა გადაიწეროს და შეიქმნას ისე, რომ მათ უფრო სწრაფად იმუშაონ. და უკეთესი შესრულებით.

და რადგან ჩვენ ვსაუბრობთ მონაცემთა ბაზაზე, მონაცემთა ბაზა ყოველთვის არის ფონური პროცესები. ფონური პროცესები ხელს უწყობს მონაცემთა ბაზის მუშაობის კარგ დონეზე შენარჩუნებას, ამიტომ ისინი საჭიროებენ გარკვეულ რესურსებს საკუთარი თავის მუშაობისთვის. და ამავდროულად, მათ შეუძლიათ გადაფარონ კლიენტის მოთხოვნის რესურსებთან, ამიტომ ხარბ ფონურ პროცესებს შეუძლიათ პირდაპირ იმოქმედონ კლიენტის მოთხოვნების შესრულებაზე. ამიტომ, მათ ასევე სჭირდებათ მონიტორინგი და თვალყურის დევნება, რათა არ მოხდეს დამახინჯება ფონური პროცესების თვალსაზრისით.

და ეს ყველაფერი მონაცემთა ბაზის მონიტორინგის კუთხით რჩება სისტემის მეტრიკაში. მაგრამ იმის გათვალისწინებით, რომ ჩვენი ინფრასტრუქტურის უმეტესი ნაწილი ღრუბლებში გადადის, ინდივიდუალური ჰოსტის სისტემური მეტრიკა ყოველთვის უკანა პლანზე ქრება. მაგრამ მონაცემთა ბაზებში ისინი კვლავ აქტუალურია და, რა თქმა უნდა, ასევე აუცილებელია სისტემის მეტრიკის მონიტორინგი.

სისტემური მეტრიკასთან დაკავშირებით ყველაფერი მეტ-ნაკლებად კარგად არის, ყველა თანამედროვე მონიტორინგის სისტემა უკვე მხარს უჭერს ამ მეტრიკას, მაგრამ ზოგადად, ზოგიერთი კომპონენტი ჯერ კიდევ არ არის საკმარისი და რაღაცის დამატებაა საჭირო. მათაც შევეხები, მათ შესახებ რამდენიმე სლაიდი იქნება.

გეგმის პირველი წერტილი არის ხელმისაწვდომობა. რა არის ხელმისაწვდომობა? ხელმისაწვდომობა, ჩემი გაგებით, არის ბაზის შესაძლებლობა, მოახდინოს კავშირები, ანუ ბაზა ამაღლებულია, ის, როგორც სერვისი, იღებს კავშირებს კლიენტებისგან. და ეს ხელმისაწვდომობა შეიძლება შეფასდეს გარკვეული მახასიათებლებით. ძალიან მოსახერხებელია ამ მახასიათებლების ჩვენება დაფებზე.

ყველამ იცის რა არის დაფები. ეს ის შემთხვევაა, როცა ერთი შეხედე ეკრანს, რომელზეც შეჯამებულია საჭირო ინფორმაცია. და თქვენ შეგიძლიათ დაუყოვნებლივ განსაზღვროთ არის თუ არა პრობლემა მონაცემთა ბაზაში თუ არა.
შესაბამისად, მონაცემთა ბაზის ხელმისაწვდომობა და სხვა ძირითადი მახასიათებლები ყოველთვის უნდა იყოს ნაჩვენები დაფებზე, რათა ეს ინფორმაცია ხელთ და ყოველთვის ხელმისაწვდომი იყოს თქვენთვის. ზოგიერთი დამატებითი დეტალი, რომელიც უკვე ეხმარება ინციდენტების გამოძიებას, ზოგიერთი საგანგებო სიტუაციის გამოძიებისას, ისინი უკვე უნდა განთავსდეს მეორად დაფაზე, ან დამალული იყოს საბურთალო ბმულებში, რომლებიც მივყავართ მესამე მხარის მონიტორინგის სისტემებს.

ერთი ცნობილი მონიტორინგის სისტემის მაგალითი. ეს არის ძალიან მაგარი მონიტორინგის სისტემა. ის აგროვებს უამრავ მონაცემს, მაგრამ ჩემი გადმოსახედიდან, მას აქვს დაფების უცნაური კონცეფცია. არის ბმული "დაფის შექმნაზე". მაგრამ როდესაც თქვენ შექმნით დაფის, თქვენ ქმნით სიას ორი სვეტისგან, გრაფიკების სიაში. და როცა რაიმეს ყურება გჭირდებათ, იწყებთ მაუსის დაწკაპუნებას, გადახვევას, სასურველი დიაგრამის ძიებას. და ამას დრო სჭირდება, ანუ არ არსებობს დაფები, როგორც ასეთი. არსებობს მხოლოდ სქემების სიები.

რა უნდა დაამატოთ ამ დაფებს? თქვენ შეგიძლიათ დაიწყოთ ისეთი მახასიათებლით, როგორიცაა რეაგირების დრო. PostgreSQL-ს აქვს pg_stat_statements ხედი. ის ნაგულისხმევად გამორთულია, მაგრამ ეს არის სისტემის ერთ-ერთი მნიშვნელოვანი ხედი, რომელიც ყოველთვის უნდა იყოს ჩართული და გამოყენებული. ის ინახავს ინფორმაციას ყველა გაშვებული შეკითხვის შესახებ, რომელიც შესრულებულია მონაცემთა ბაზაში.

შესაბამისად, შეგვიძლია დავიწყოთ იქიდან, რომ შეგვიძლია ავიღოთ ყველა მოთხოვნის შესრულების მთლიანი დრო და გავყოთ იგი მოთხოვნის რაოდენობაზე ზემოაღნიშნული ველების გამოყენებით. მაგრამ ეს არის საშუალო ტემპერატურა საავადმყოფოში. შეგვიძლია დავიწყოთ სხვა ველებიდან - შეკითხვის შესრულების მინიმალური დრო, მაქსიმალური და მედიანა. და ჩვენ შეგვიძლია ავაშენოთ პროცენტები; PostgreSQL-ს აქვს შესაბამისი ფუნქციები ამისათვის. და ჩვენ შეგვიძლია მივიღოთ რამდენიმე რიცხვი, რომელიც ახასიათებს ჩვენი მონაცემთა ბაზის პასუხის დროს უკვე დასრულებულ მოთხოვნებზე, ანუ ჩვენ არ ვასრულებთ ყალბ მოთხოვნას „აირჩიეთ 1“ და ვუყურებთ პასუხის დროს, მაგრამ ვაანალიზებთ უკვე დასრულებულ მოთხოვნებს პასუხის დროს და ვხატავთ ან ცალკე ფიგურა, ან მასზე დაყრდნობით ვაშენებთ გრაფიკს.

ასევე მნიშვნელოვანია სისტემის მიერ ამჟამად წარმოქმნილი შეცდომების რაოდენობის მონიტორინგი. და ამისთვის შეგიძლიათ გამოიყენოთ pg_stat_database ხედი. ჩვენ ფოკუსირებას ვაკეთებთ xact_rollback ველზე. ეს ველი აჩვენებს არა მხოლოდ მონაცემთა ბაზაში დაბრუნების რაოდენობას, არამედ ითვალისწინებს შეცდომების რაოდენობას. შედარებით რომ ვთქვათ, ჩვენ შეგვიძლია ამ ფიგურის ჩვენება ჩვენს დაფაზე და ვნახოთ რამდენი შეცდომა გვაქვს ამჟამად. თუ ბევრი შეცდომაა, მაშინ ეს კარგი მიზეზია, რომ ჩახედოთ ჟურნალებს და ნახოთ, რა სახის შეცდომებია და რატომ ხდება ისინი, შემდეგ კი ინვესტირება და გადაჭრა.

თქვენ შეგიძლიათ დაამატოთ ისეთი რამ, როგორიცაა ტაქომეტრი. ეს არის ტრანზაქციის რაოდენობა წამში და მოთხოვნის რაოდენობა წამში. შედარებით რომ ვთქვათ, შეგიძლიათ გამოიყენოთ ეს ნომრები, როგორც თქვენი მონაცემთა ბაზის მიმდინარე შესრულება და დააკვირდეთ, არის თუ არა პიკი მოთხოვნებში, პიკი ტრანზაქციებში, ან, პირიქით, არის თუ არა მონაცემთა ბაზა დატვირთული, რადგან ზოგიერთი backend ვერ მოხერხდა. მნიშვნელოვანია, რომ ყოველთვის შევხედოთ ამ ფიგურას და გვახსოვდეს, რომ ჩვენი პროექტისთვის ასეთი შესრულება ნორმალურია, მაგრამ ზემოთ და ქვემოთ მოცემული მნიშვნელობები უკვე ერთგვარი პრობლემური და გაუგებარია, რაც ნიშნავს, რომ ჩვენ უნდა დავაკვირდეთ, რატომ არის ეს რიცხვები. იმდენად მაღალი.

ტრანზაქციების რაოდენობის შესაფასებლად, შეგვიძლია კვლავ მივმართოთ pg_stat_database ხედს. ჩვენ შეგვიძლია დავამატოთ commit-ების და rollback-ების რაოდენობა და მივიღოთ ტრანზაქციის რაოდენობა წამში.

ყველას ესმის, რომ რამდენიმე მოთხოვნა შეიძლება მოთავსდეს ერთ ტრანზაქციაში? ამიტომ TPS და QPS ოდნავ განსხვავებულია.

მოთხოვნის რაოდენობა წამში შეგიძლიათ მიიღოთ pg_stat_statements-დან და უბრალოდ გამოვთვალოთ ყველა დასრულებული მოთხოვნის ჯამი. გასაგებია, რომ მიმდინარე მნიშვნელობას ვადარებთ წინას, ვაკლებთ, ვიღებთ დელტას და ვიღებთ რაოდენობას.

სურვილის შემთხვევაში შეგიძლიათ დაამატოთ დამატებითი მეტრიკა, რაც ასევე დაგეხმარებათ შეაფასოთ ჩვენი მონაცემთა ბაზის ხელმისაწვდომობა და დააკვირდეთ იყო თუ არა რაიმე შეფერხება.

ერთ-ერთი ასეთი მეტრიკა არის მუშაობის დრო. მაგრამ PostgreSQL-ში მუშაობის დრო ცოტა რთულია. მე გეტყვით რატომ. როდესაც PostgreSQL დაიწყო, uptime იწყებს მოხსენებას. მაგრამ თუ რაღაც მომენტში, მაგალითად, რაღაც ამოცანის შესრულება ღამით, მოვიდა OOM-მკვლელი და იძულებით შეწყვიტა PostgreSQL ბავშვის პროცესი, მაშინ ამ შემთხვევაში PostgreSQL წყვეტს ყველა კლიენტის კავშირს, აღადგენს გახეხილი მეხსიერების არეალს და იწყებს აღდგენას. ბოლო საგუშაგო. და სანამ საკონტროლო პუნქტიდან ეს აღდგენა გრძელდება, მონაცემთა ბაზა არ იღებს კავშირებს, ანუ ეს სიტუაცია შეიძლება შეფასდეს, როგორც შეფერხების დრო. მაგრამ დროების მრიცხველი არ აღდგება, რადგან იგი ითვალისწინებს პოსტმასტერის გაშვების დროს პირველივე მომენტიდან. ამიტომ, ასეთი სიტუაციების გამოტოვება შესაძლებელია.

თქვენ ასევე უნდა აკონტროლოთ მტვერსასრუტების რაოდენობა. ყველამ იცის რა არის ავტოვაკუუმი PostgreSQL-ში? ეს არის საინტერესო ქვესისტემა PostgreSQL-ში. ბევრი სტატია დაიწერა მის შესახებ, გაკეთდა მრავალი მოხსენება. ბევრი დისკუსია მიმდინარეობს ვაკუუმზე და იმაზე, თუ როგორ უნდა იმუშაოს. ბევრი მას აუცილებელ ბოროტებად თვლის. მაგრამ ეს ასეა. ეს არის ნაგვის შემგროვებლის ერთგვარი ანალოგი, რომელიც ასუფთავებს მწკრივების მოძველებულ ვერსიებს, რომლებიც არ არის საჭირო რაიმე ტრანზაქციისთვის და ათავისუფლებს ადგილს ცხრილებში და ინდექსებში ახალი რიგებისთვის.

რატომ გჭირდებათ მისი მონიტორინგი? იმის გამო, რომ ვაკუუმი ზოგჯერ ძალიან მტკივა. ის მოიხმარს უამრავ რესურსს და კლიენტის მოთხოვნები იწყებს ზარალს.

და მისი მონიტორინგი უნდა მოხდეს pg_stat_activity ხედის საშუალებით, რაზეც შემდეგ ნაწილში ვისაუბრებ. ეს ხედი აჩვენებს მონაცემთა ბაზაში მიმდინარე აქტივობას. და ამ აქტივობის საშუალებით ჩვენ შეგვიძლია თვალყური ადევნოთ მტვერსასრუტების რაოდენობას, რომლებიც ამჟამად მუშაობს. ჩვენ შეგვიძლია ვაკუუმების თვალყურის დევნება და დავინახოთ, რომ თუ ჩვენ გადავაჭარბეთ ლიმიტს, მაშინ ეს არის მიზეზი, რომ გადავხედოთ PostgreSQL პარამეტრებს და როგორმე ვაკუუმის მუშაობის ოპტიმიზაცია მოვახდინოთ.

კიდევ ერთი რამ PostgreSQL-ის შესახებ არის ის, რომ PostgreSQL ძალიან დაავადებულია ხანგრძლივი ტრანზაქციებით. მითუმეტეს ტრანზაქციებიდან, რომლებიც დიდხანს ტრიალებენ და არაფერს აკეთებენ. ეს არის ე.წ. stat idle-in-transaction. ასეთი ტრანზაქცია ინახავს საკეტებს და ხელს უშლის ვაკუუმის მუშაობას. და შედეგად, მაგიდები შეშუპებულია და იზრდება ზომაში. და მოთხოვნები, რომლებიც მუშაობს ამ ცხრილებთან, იწყებენ მუშაობას ნელა, რადგან თქვენ უნდა ამოიღოთ მწკრივების ყველა ძველი ვერსია მეხსიერებიდან დისკამდე და უკან. ამიტომ, დროის, ყველაზე გრძელი ტრანზაქციის ხანგრძლივობის, ყველაზე გრძელი ვაკუუმის მოთხოვნების მონიტორინგიც საჭიროა. და თუ ჩვენ ვხედავთ რამდენიმე პროცესს, რომელიც მიმდინარეობს ძალიან დიდი ხნის განმავლობაში, უკვე 10-20-30 წუთზე მეტია OLTP დატვირთვისთვის, მაშინ ჩვენ უნდა მივაქციოთ მათ ყურადღება და იძულებით შევწყვიტოთ ისინი, ან გავაუმჯობესოთ აპლიკაცია ისე, რომ ისინი არ იძახიან და არ ჩამოკიდებენ ამდენ ხანს. ანალიტიკური დატვირთვისთვის 10-20-30 წუთი ნორმალურია, არის უფრო გრძელიც.

შემდეგი ჩვენ გვაქვს შესაძლებლობა დაკავშირებულ კლიენტებთან. როდესაც ჩვენ უკვე შევქმენით საინფორმაციო დაფა და გამოვაქვეყნეთ მასზე ხელმისაწვდომობის ძირითადი მეტრიკა, ჩვენ ასევე შეგვიძლია დავამატოთ დამატებითი ინფორმაცია დაკავშირებული კლიენტების შესახებ.

დაკავშირებული კლიენტების შესახებ ინფორმაცია მნიშვნელოვანია, რადგან, PostgreSQL პერსპექტივიდან, კლიენტები განსხვავებულია. არიან კარგი კლიენტები და არიან ცუდი კლიენტები.

მარტივი მაგალითი. კლიენტის მიერ მე მესმის განაცხადი. აპლიკაცია დაუკავშირდა მონაცემთა ბაზას და დაუყოვნებლივ იწყებს იქ მოთხოვნის გაგზავნას, მონაცემთა ბაზა ამუშავებს და ახორციელებს მათ და უბრუნებს შედეგებს კლიენტს. ეს კარგი და სწორი კლიენტები არიან.

არის სიტუაციები, როდესაც კლიენტი დაკავშირებულია, ის ინარჩუნებს კავშირს, მაგრამ არაფერს აკეთებს. უმოქმედო მდგომარეობაშია.

მაგრამ არის ცუდი კლიენტები. მაგალითად, იგივე კლიენტი დაუკავშირდა, გახსნა ტრანზაქცია, რაღაც გააკეთა მონაცემთა ბაზაში და შემდეგ შევიდა კოდში, მაგალითად, გარე წყაროზე წვდომისთვის ან იქ მიღებული მონაცემების დასამუშავებლად. მაგრამ მან არ დახურა გარიგება. და ტრანზაქცია დაკიდებულია მონაცემთა ბაზაში და ინახება ხაზში საკეტში. ეს ცუდი მდგომარეობაა. და თუ მოულოდნელად აპლიკაცია სადღაც შიგნით ჩაიშლება გამონაკლისის გარდა, მაშინ ტრანზაქცია შეიძლება ღია დარჩეს ძალიან დიდი ხნის განმავლობაში. და ეს პირდაპირ გავლენას ახდენს PostgreSQL შესრულებაზე. PostgreSQL უფრო ნელი იქნება. აქედან გამომდინარე, მნიშვნელოვანია ასეთი კლიენტების დროული თვალყურის დევნება და მათი მუშაობის იძულებით შეწყვეტა. და თქვენ გჭირდებათ თქვენი აპლიკაციის ოპტიმიზაცია ისე, რომ ასეთი სიტუაციები არ მოხდეს.

სხვა ცუდი კლიენტები კლიენტებს ელოდებიან. მაგრამ ისინი ცუდები ხდებიან გარემოებების გამო. მაგალითად, უბრალო უმოქმედო ტრანზაქცია: მას შეუძლია გახსნას ტრანზაქცია, აიღოს ბლოკირება ზოგიერთ ხაზზე, შემდეგ სადღაც კოდში ის ჩაიშლება და დარჩება ჩამოკიდებული ტრანზაქცია. მოვა სხვა კლიენტი და მოითხოვს იგივე მონაცემებს, მაგრამ ის წააწყდება საკეტს, რადგან ეს ჩამოკიდებული ტრანზაქცია უკვე ინახავს საკეტებს ზოგიერთ საჭირო სტრიქონზე. და მეორე ტრანზაქცია დაკიდებული იქნება პირველი ტრანზაქციის დასრულებამდე ან ადმინისტრატორის მიერ იძულებით დახურვის მოლოდინში. ამიტომ, მომლოდინე ტრანზაქციებს შეუძლია დაგროვდეს და შეავსოს მონაცემთა ბაზის კავშირის ლიმიტი. და როდესაც ლიმიტი სავსეა, აპლიკაცია ვეღარ იმუშავებს მონაცემთა ბაზასთან. ეს უკვე საგანგებო მდგომარეობაა პროექტისთვის. ამიტომ, ცუდი კლიენტების თვალყურის დევნება და დროული რეაგირება საჭიროა.

მონიტორინგის კიდევ ერთი მაგალითი. და აქ უკვე არის ღირსეული დაფა. ზემოთ არის ინფორმაცია კავშირების შესახებ. DB კავშირი - 8 ცალი. და ეს ყველაფერი. ჩვენ არ გვაქვს ინფორმაცია იმის შესახებ, თუ რომელი კლიენტები არიან აქტიური, რომელი კლიენტები არიან უსაქმურები და არაფერს აკეთებენ. არ არსებობს ინფორმაცია მომლოდინე ტრანზაქციებისა და მომლოდინე კავშირების შესახებ, ანუ ეს არის ფიგურა, რომელიც აჩვენებს კავშირების რაოდენობას და ეს არის ის. და მერე თავად გამოიცანით.

შესაბამისად, ამ ინფორმაციის მონიტორინგში დასამატებლად, თქვენ უნდა შეხვიდეთ pg_stat_activity სისტემის ხედზე. თუ დიდ დროს ატარებთ PostgreSQL-ში, მაშინ ეს არის ძალიან კარგი ხედი, რომელიც უნდა გახდეს თქვენი მეგობარი, რადგან აჩვენებს მიმდინარე აქტივობას PostgreSQL-ში, ანუ რა ხდება მასში. თითოეული პროცესისთვის არის ცალკე ხაზი, რომელიც აჩვენებს ინფორმაციას ამ პროცესის შესახებ: რომელი ჰოსტიდან განხორციელდა კავშირი, რა მომხმარებლის ქვეშ, რა სახელით, როდის დაიწყო ტრანზაქცია, რა მოთხოვნა გადის ამჟამად, რა მოთხოვნა იყო ბოლოს შესრულებული. და, შესაბამისად, ჩვენ შეგვიძლია შევაფასოთ კლიენტის მდგომარეობა stat ველის გამოყენებით. შედარებით რომ ვთქვათ, ჩვენ შეგვიძლია დავაჯგუფოთ ამ ველის მიხედვით და მივიღოთ ის სტატისტიკა, რომელიც ამჟამად არის მონაცემთა ბაზაში და კავშირების რაოდენობა, რომლებსაც აქვთ ეს სტატისტიკა მონაცემთა ბაზაში. ჩვენ შეგვიძლია უკვე მიღებული ნომრები გავაგზავნოთ ჩვენს მონიტორინგზე და მათზე დაყრდნობით დავხატოთ გრაფიკები.
ასევე მნიშვნელოვანია ტრანზაქციის ხანგრძლივობის შეფასება. მე უკვე ვთქვი, რომ მნიშვნელოვანია ვაკუუმების ხანგრძლივობის შეფასება, მაგრამ ტრანზაქციები ფასდება ანალოგიურად. არის xact_start და query_start ველები. ისინი, შედარებით რომ ვთქვათ, აჩვენებენ ტრანზაქციის დაწყების და მოთხოვნის დაწყების დროს. ვიღებთ now() ფუნქციას, რომელიც აჩვენებს მიმდინარე დროის ნიშანს, ვაკლებთ ტრანზაქციას და ვითხოვთ დროის ნიშანს. და ჩვენ ვიღებთ გარიგების ხანგრძლივობას, მოთხოვნის ხანგრძლივობას.

თუ ვხედავთ გრძელ ტრანზაქციებს, ისინი უკვე უნდა დავასრულოთ. OLTP დატვირთვისთვის, ხანგრძლივი ტრანზაქციები უკვე 1-2-3 წუთზე მეტია. OLAP დატვირთვისთვის, ხანგრძლივი ტრანზაქციები ნორმალურია, მაგრამ თუ მათ დასრულებას ორ საათზე მეტი დრო სჭირდება, მაშინ ეს ასევე იმის ნიშანია, რომ სადღაც გვაქვს დახრილობა.

როგორც კი კლიენტები დაუკავშირდებიან მონაცემთა ბაზას, ისინი იწყებენ მუშაობას ჩვენს მონაცემებთან. ისინი წვდებიან ცხრილებს, წვდებიან ინდექსებს ცხრილიდან მონაცემების მისაღებად. და მნიშვნელოვანია შევაფასოთ, როგორ ურთიერთობენ კლიენტები ამ მონაცემებთან.

ეს აუცილებელია იმისათვის, რომ შევაფასოთ ჩვენი დატვირთვა და უხეშად გავიგოთ, რომელი ცხრილებია ჩვენთვის ყველაზე „ცხელი“. მაგალითად, ეს საჭიროა იმ სიტუაციებში, როდესაც ჩვენ გვინდა განვათავსოთ "ცხელი" ცხრილები რაიმე სახის სწრაფ SSD საცავზე. მაგალითად, ზოგიერთი საარქივო ცხრილი, რომელიც დიდი ხანია არ გამოგვიყენებია, შეიძლება გადავიტანოთ რაიმე სახის „ცივ“ არქივში, SATA დისკებში და იქ იცხოვრონ, მათზე წვდომა იქნება საჭიროებისამებრ.

ეს ასევე სასარგებლოა ნებისმიერი გამოშვებისა და განლაგების შემდეგ ანომალიების გამოსავლენად. ვთქვათ, პროექტმა გამოუშვა ახალი ფუნქცია. მაგალითად, დავამატეთ ახალი ფუნქციონირება მონაცემთა ბაზასთან მუშაობისთვის. და თუ ჩვენ დავსახავთ ცხრილის გამოყენების გრაფიკებს, ჩვენ შეგვიძლია ადვილად აღმოვაჩინოთ ეს ანომალიები ამ გრაფიკებზე. მაგალითად, განაახლეთ bursts ან წაშალეთ bursts. ძალიან თვალსაჩინო იქნება.

თქვენ ასევე შეგიძლიათ აღმოაჩინოთ ანომალიები "მცურავი" სტატისტიკაში. Რას ნიშნავს? PostgreSQL-ს აქვს ძალიან ძლიერი და ძალიან კარგი შეკითხვის გრაფიკი. და დეველოპერები დიდ დროს უთმობენ მის განვითარებას. როგორ მუშაობს ის? კარგი გეგმების შესასრულებლად, PostgreSQL აგროვებს სტატისტიკას ცხრილებში მონაცემების განაწილების შესახებ გარკვეული დროის ინტერვალით და გარკვეული სიხშირით. ეს არის ყველაზე გავრცელებული მნიშვნელობები: უნიკალური მნიშვნელობების რაოდენობა, ინფორმაცია NULL-ის შესახებ ცხრილში, ბევრი ინფორმაცია.

ამ სტატისტიკის საფუძველზე დამგეგმავი აყალიბებს რამდენიმე მოთხოვნას, ირჩევს ყველაზე ოპტიმალურს და იყენებს ამ შეკითხვის გეგმას თავად შეასრულოს მოთხოვნა და დააბრუნოს მონაცემები.

და ეს ხდება, რომ სტატისტიკა "ცურავს". ხარისხისა და რაოდენობის მონაცემები გარკვეულწილად შეიცვალა ცხრილში, მაგრამ სტატისტიკა არ შეგროვდა. და ჩამოყალიბებული გეგმები შეიძლება არ იყოს ოპტიმალური. და თუ ჩვენი გეგმები არაოპტიმალური აღმოჩნდება შეგროვებული მონიტორინგის, ცხრილების მიხედვით, ჩვენ შევძლებთ დავინახოთ ეს ანომალიები. მაგალითად, სადღაც მონაცემები ხარისხობრივად შეიცვალა და ინდექსის ნაცვლად დაიწყო ცხრილის თანმიმდევრული გავლის გამოყენება, ე.ი. თუ მოთხოვნას სჭირდება მხოლოდ 100 მწკრივის დაბრუნება (არსებობს 100-ის ლიმიტი), მაშინ ამ მოთხოვნის სრული ძებნა განხორციელდება. და ეს ყოველთვის ძალიან ცუდად მოქმედებს შესრულებაზე.

და ჩვენ ამას ვხედავთ მონიტორინგში. და უკვე შეხედეთ ამ შეკითხვას, გაუშვით მისი ახსნა, შეაგროვეთ სტატისტიკა, შექმენით ახალი დამატებითი ინდექსი. და უკვე უპასუხეთ ამ პრობლემას. ამიტომაც არის მნიშვნელოვანი.

მონიტორინგის კიდევ ერთი მაგალითი. ვფიქრობ, ის ბევრმა იცნო, რადგან ძალიან პოპულარულია. ვინც მას იყენებს საკუთარ პროექტებში პრომეთე? ვინ იყენებს ამ პროდუქტს პრომეთესთან ერთად? ფაქტია, რომ ამ მონიტორინგის სტანდარტულ საცავში არის დაფა PostgreSQL-თან მუშაობისთვის - პოსტგრესი_ექსპორტიორი პრომეთე. მაგრამ არის ერთი ცუდი დეტალი.

რამდენიმე გრაფიკია. და ბაიტები მითითებულია როგორც ერთიანობა, ანუ არის 5 გრაფიკი. ეს არის მონაცემების ჩასმა, მონაცემების განახლება, მონაცემების წაშლა, მონაცემების მიღება და მონაცემების დაბრუნება. ერთეულის საზომი არის ბაიტი. მაგრამ საქმე ის არის, რომ სტატისტიკა PostgreSQL-ში აბრუნებს მონაცემებს ტოტებში (სტრიქონები). და, შესაბამისად, ეს გრაფიკები ძალიან კარგი საშუალებაა თქვენი დატვირთვის რამდენჯერმე, ათჯერად შეფასების მიზნით, რადგან ტუპლი არ არის ბაიტი, ტუპლი არის სტრიქონი, ის მრავალი ბაიტია და ყოველთვის ცვლადი სიგრძისაა. ანუ, ბაიტებში დატვირთვის გამოთვლა ტუპლების გამოყენებით არარეალური ამოცანაა ან ძალიან რთული. ამიტომ, როდესაც იყენებთ დაფის ან ჩაშენებულ მონიტორინგს, ყოველთვის მნიშვნელოვანია იმის გაგება, რომ ის მუშაობს სწორად და აბრუნებს თქვენ სწორად შეფასებულ მონაცემებს.

როგორ მივიღოთ სტატისტიკა ამ ცხრილებზე? ამ მიზნით, PostgreSQL-ს აქვს შეხედულებების გარკვეული ოჯახი. და მთავარი ხედი არის pg_stat_user_tables. User_tables - ეს ნიშნავს მომხმარებლის სახელით შექმნილ ცხრილებს. ამის საპირისპიროდ, არის სისტემის ხედები, რომლებსაც თავად PostgreSQL იყენებს. და არის შემაჯამებელი ცხრილი Alltables, რომელიც მოიცავს როგორც სისტემურ, ასევე მომხმარებელს. შეგიძლიათ დაიწყოთ ნებისმიერი მათგანიდან, რომელიც ყველაზე მეტად მოგწონთ.

ზემოაღნიშნული ველების გამოყენებით შეგიძლიათ შეაფასოთ ჩანართების, განახლებების და წაშლის რაოდენობა. დაფის მაგალითი, რომელიც მე გამოვიყენე, იყენებს ამ ველებს სამუშაო დატვირთვის მახასიათებლების შესაფასებლად. ამიტომ, ჩვენც შეგვიძლია მათზე დავამყაროთ. მაგრამ უნდა გვახსოვდეს, რომ ეს არის ტოპები და არა ბაიტები, ასე რომ, ჩვენ არ შეგვიძლია ამის გაკეთება მხოლოდ ბაიტებში.

ამ მონაცემებზე დაყრდნობით შეგვიძლია ავაშენოთ ე.წ. TopN ცხრილები. მაგალითად, ტოპ-5, ტოპ-10. და თქვენ შეგიძლიათ თვალყური ადევნოთ იმ ცხელ მაგიდებს, რომლებიც სხვებზე მეტად გადამუშავდება. მაგალითად, 5 "ცხელი" მაგიდა ჩასართავად. და ამ TopN ცხრილების გამოყენებით ჩვენ ვაფასებთ ჩვენს დატვირთვას და შეგვიძლია შევაფასოთ დატვირთვის სიხშირე ნებისმიერი გამოშვების, განახლებისა და განლაგების შემდეგ.

ასევე მნიშვნელოვანია ცხრილის ზომის შეფასება, რადგან ზოგჯერ დეველოპერები ავრცელებენ ახალ ფუნქციას და ჩვენი ცხრილები იწყებენ დიდ ზომებს, რადგან მათ გადაწყვიტეს დამატებითი რაოდენობის მონაცემების დამატება, მაგრამ არ იწინასწარმეტყველეს, როგორ იმოქმედებდა ეს. მონაცემთა ბაზის ზომა. ასეთი შემთხვევები ჩვენთვისაც მოულოდნელია.

ახლა კი ერთი პატარა კითხვა თქვენთვის. რა კითხვა ჩნდება, როდესაც შეამჩნევთ დატვირთვას თქვენს მონაცემთა ბაზის სერვერზე? რა არის შემდეგი შეკითხვა?

მაგრამ სინამდვილეში კითხვა ჩნდება შემდეგნაირად. რა მოთხოვნებს იწვევს დატვირთვა? ანუ არ არის საინტერესო იმ პროცესების ყურება, რომლებიც გამოწვეულია დატვირთვით. გასაგებია, რომ თუ მასპინძელს აქვს მონაცემთა ბაზა, მაშინ მონაცემთა ბაზა მუშაობს იქ და ცხადია, რომ იქ მხოლოდ მონაცემთა ბაზები განადგურდება. თუ გავხსნით ტოპს, იქ დავინახავთ პროცესების სიას PostgreSQL-ში, რომლებიც რაღაცას აკეთებენ. ტოპიდან არ იქნება ნათელი, რას აკეთებენ.

შესაბამისად, თქვენ უნდა იპოვოთ ის მოთხოვნები, რომლებიც იწვევენ უმაღლეს დატვირთვას, რადგან მოთხოვნების დაყენება, როგორც წესი, უფრო მეტ მოგებას იძლევა, ვიდრე PostgreSQL ან ოპერაციული სისტემის კონფიგურაციის დალაგება, ან თუნდაც აპარატურის დარეგულირება. ჩემი შეფასებით, ეს არის დაახლოებით 80-85-90%. და ეს კეთდება ბევრად უფრო სწრაფად. მოთხოვნის შესწორება უფრო სწრაფია, ვიდრე კონფიგურაციის შესწორება, გადატვირთვის დაგეგმვა, განსაკუთრებით იმ შემთხვევაში, თუ მონაცემთა ბაზის გადატვირთვა შეუძლებელია, ან აპარატურის დამატება. უფრო ადვილია შეკითხვის გადაწერა სადმე ან ინდექსის დამატება ამ მოთხოვნიდან უკეთესი შედეგის მისაღებად.

შესაბამისად, აუცილებელია მოთხოვნისა და მათი ადეკვატურობის მონიტორინგი. ავიღოთ მონიტორინგის კიდევ ერთი მაგალითი. და აქაც, როგორც ჩანს, შესანიშნავი მონიტორინგია. არის ინფორმაცია რეპლიკაციის შესახებ, არის ინფორმაცია გამტარუნარიანობის, დაბლოკვის, რესურსების გამოყენების შესახებ. ყველაფერი კარგადაა, მაგრამ მოთხოვნის შესახებ ინფორმაცია არ არის. გაურკვეველია, რა მოთხოვნები მუშაობს ჩვენს მონაცემთა ბაზაში, რამდენ ხანს მუშაობს ისინი, რამდენია ეს მოთხოვნა. ჩვენ ყოველთვის უნდა გვქონდეს ეს ინფორმაცია ჩვენს მონიტორინგში.

და ამ ინფორმაციის მისაღებად შეგვიძლია გამოვიყენოთ pg_stat_statements მოდული. მასზე დაყრდნობით, შეგიძლიათ შექმნათ სხვადასხვა გრაფიკები. მაგალითად, შეგიძლიათ მიიღოთ ინფორმაცია ყველაზე ხშირი მოთხოვნების შესახებ, ანუ იმ მოთხოვნების შესახებ, რომლებიც ყველაზე ხშირად სრულდება. დიახ, განლაგების შემდეგ ასევე ძალიან სასარგებლოა მისი ნახვა და იმის გაგება, არის თუ არა მოთხოვნის ზრდა.

შეგიძლიათ თვალყური ადევნოთ ყველაზე ხანგრძლივ მოთხოვნებს, ანუ იმ შეკითხვებს, რომელთა დასრულებას ყველაზე დიდი დრო სჭირდება. ისინი მუშაობენ პროცესორზე, მოიხმარენ I/O-ს. ამის შეფასება შეგვიძლია ასევე ველების total_time, mean_time, blk_write_time და blk_read_time გამოყენებით.

ჩვენ შეგვიძლია შევაფასოთ და დავაკვირდეთ უმძიმეს მოთხოვნებს რესურსის გამოყენების თვალსაზრისით, ის, ვინც კითხულობს დისკიდან, მუშაობს მეხსიერებასთან, ან, პირიქით, ქმნის რაიმე სახის ჩაწერის დატვირთვას.

ჩვენ შეგვიძლია შევაფასოთ ყველაზე გულუხვი მოთხოვნები. ეს არის მოთხოვნები, რომლებიც აბრუნებენ მწკრივების დიდ რაოდენობას. მაგალითად, ეს შეიძლება იყოს მოთხოვნა, სადაც მათ დაავიწყდათ ლიმიტის დაწესება. და ის უბრალოდ აბრუნებს ცხრილის ან შეკითხვის მთელ შინაარსს მოთხოვნილ ცხრილებში.

თქვენ ასევე შეგიძლიათ აკონტროლოთ მოთხოვნები, რომლებიც იყენებენ დროებით ფაილებს ან დროებით ცხრილებს.

და ჩვენ ჯერ კიდევ გვაქვს ფონური პროცესები. ფონური პროცესები, უპირველეს ყოვლისა, არის საგუშაგოები ან მათ ასევე უწოდებენ საგუშაგოებს, ეს არის ავტოვაკუუმი და რეპლიკაცია.

მონიტორინგის კიდევ ერთი მაგალითი. მარცხნივ არის Maintenance ჩანართი, გადადით მასზე და იმედი გაქვთ, რომ ნახავთ რაიმე სასარგებლოს. მაგრამ აქ მხოლოდ ვაკუუმური მუშაობის და სტატისტიკის შეგროვების დროა, მეტი არაფერი. ეს ძალიან ცუდი ინფორმაციაა, ამიტომ ყოველთვის გვჭირდება ინფორმაცია იმის შესახებ, თუ როგორ მუშაობს ფონური პროცესები ჩვენს მონაცემთა ბაზაში და არის თუ არა რაიმე პრობლემა მათ მუშაობაში.

როდესაც ჩვენ ვუყურებთ საგუშაგოებს, უნდა გვახსოვდეს, რომ გამშვები პუნქტები ასუფთავებენ ბინძურ გვერდებს გახეხილი მეხსიერების ზონიდან დისკზე და შემდეგ ქმნიან საგუშაგოს. და ეს გამშვები პუნქტი შეიძლება გამოყენებულ იქნას როგორც აღდგენის ადგილი, თუ PostgreSQL მოულოდნელად შეწყდა საგანგებო სიტუაციებში.

შესაბამისად, იმისათვის, რომ ყველა „ბინძური“ გვერდი დისკზე გადაიტანოთ, საჭიროა ჩაწეროთ გარკვეული რაოდენობა. და, როგორც წესი, დიდი რაოდენობით მეხსიერების სისტემებზე, ეს ბევრია. და თუ ჩვენ ვაკეთებთ საკონტროლო პუნქტებს ძალიან ხშირად მოკლე ინტერვალით, მაშინ დისკის შესრულება მნიშვნელოვნად შემცირდება. და კლიენტების მოთხოვნები დაზარალდება რესურსების ნაკლებობით. ისინი კონკურენციას გაუწევენ რესურსებისთვის და არ ექნებათ პროდუქტიულობა.

შესაბამისად, pg_stat_bgwriter-ის მეშვეობით მითითებული ველების გამოყენებით ჩვენ შეგვიძლია დავაკვირდეთ გაჩენილი საგუშაგოების რაოდენობას. და თუ ჩვენ გვაქვს ბევრი საგუშაგო გარკვეული პერიოდის განმავლობაში (10-15-20 წუთში, ნახევარ საათში), მაგალითად, 3-4-5, მაშინ ეს უკვე შეიძლება იყოს პრობლემა. და თქვენ უკვე გჭირდებათ მონაცემთა ბაზაში ჩახედვა, კონფიგურაციაში ჩახედვა, რა იწვევს გამშვები პუნქტების ასეთ სიმრავლეს. შესაძლოა, რაღაც დიდი ჩანაწერი მიმდინარეობს. ჩვენ უკვე შეგვიძლია შევაფასოთ დატვირთვა, რადგან უკვე დავამატეთ დატვირთვის გრაფიკები. ჩვენ უკვე შეგვიძლია შევცვალოთ საგუშაგოს პარამეტრები და დავრწმუნდეთ, რომ ისინი დიდად არ იმოქმედებენ შეკითხვის შესრულებაზე.

მე ისევ ვუბრუნდები ავტოვაკუუმს, რადგან ეს არის ისეთი რამ, როგორც ვთქვი, რომ ადვილად შეუძლია დაამატოს როგორც დისკის, ასევე შეკითხვის შესრულება, ამიტომ ყოველთვის მნიშვნელოვანია ავტოვაკუუმის ოდენობის შეფასება.

მონაცემთა ბაზაში ავტოვაკუუმის მუშაკთა რაოდენობა შეზღუდულია. ნაგულისხმევად, სამი მათგანია, ასე რომ, თუ ჩვენ ყოველთვის გვყავს სამი თანამშრომელი, რომელიც მუშაობს მონაცემთა ბაზაში, ეს ნიშნავს, რომ ჩვენი ავტოვაკუუმი არ არის კონფიგურირებული, ჩვენ უნდა გავზარდოთ ლიმიტები, გადავხედოთ ავტოვაკუუმის პარამეტრებს და შევიდეთ კონფიგურაციაში.
მნიშვნელოვანია შევაფასოთ, თუ რომელი ვაკუუმი გვყავს. ან მომხმარებლისგან იყო გაშვებული, მოვიდა DBA და ხელით გაუშვა რაიმე სახის ვაკუუმი და ამან შექმნა დატვირთვა. რაღაც პრობლემა გვაქვს. ან ეს არის მტვერსასრუტების რაოდენობა, რომელიც ხსნის ტრანზაქციის მრიცხველს. PostgreSQL-ის ზოგიერთი ვერსიისთვის ეს ძალიან მძიმე მტვერსასრუტებია. და მათ შეუძლიათ მარტივად დაამატონ შესრულება, რადგან ისინი კითხულობენ მთელ ცხრილს, სკანირებენ ამ ცხრილის ყველა ბლოკს.

და, რა თქმა უნდა, ვაკუუმების ხანგრძლივობა. თუ ჩვენ გვაქვს გრძელვადიანი მტვერსასრუტები, რომლებიც მუშაობენ ძალიან დიდი ხნის განმავლობაში, მაშინ ეს ნიშნავს, რომ ჩვენ კვლავ უნდა მივაქციოთ ყურადღება ვაკუუმის კონფიგურაციას და, შესაძლოა, გადახედოთ მის პარამეტრებს. იმის გამო, რომ შეიძლება შეიქმნას სიტუაცია, როდესაც ვაკუუმი მუშაობს მაგიდაზე დიდი ხნის განმავლობაში (3-4 საათი), მაგრამ ვაკუუმის მუშაობის დროს, დიდი რაოდენობით მკვდარი რიგები კვლავ მოახერხა მაგიდაში დაგროვება. და როგორც კი ვაკუუმი დასრულდება, მას ეს ცხრილი ისევ მტვერსასრუტი სჭირდება. და მივდივართ სიტუაციამდე - გაუთავებელ ვაკუუმამდე. და ამ შემთხვევაში, ვაკუუმი არ უმკლავდება თავის მუშაობას და ცხრილები თანდათანობით იწყებენ ზომით შეშუპებას, თუმცა მასში სასარგებლო მონაცემების მოცულობა იგივე რჩება. ამიტომ, ხანგრძლივი ვაკუუმების დროს, ჩვენ ყოველთვის ვუყურებთ კონფიგურაციას და ვცდილობთ მის ოპტიმიზაციას, მაგრამ ამავე დროს ისე, რომ კლიენტის მოთხოვნების შესრულება არ დაზარალდეს.

დღესდღეობით პრაქტიკულად არ არსებობს PostgreSQL ინსტალაცია, რომელსაც არ ჰქონდეს ნაკადის რეპლიკაცია. რეპლიკაცია არის მონაცემთა გადატანის პროცესი მასტერიდან რეპლიკაზე.

PostgreSQL-ში რეპლიკაცია ხდება ტრანზაქციის ჟურნალის მეშვეობით. ოსტატი წარმოქმნის ტრანზაქციის ჟურნალს. ტრანზაქციის ჟურნალი გადადის ქსელის კავშირზე რეპლიკასთან და შემდეგ ის მრავლდება რეპლიკაზე. Ეს მარტივია.

შესაბამისად, pg_stat_replication ხედი გამოიყენება რეპლიკაციის ჩამორჩენის მონიტორინგისთვის. მაგრამ მასთან ყველაფერი მარტივი არ არის. მე-10 ვერსიაში ხედმა განიცადა რამდენიმე ცვლილება. პირველ რიგში, ზოგიერთ ველს სახელი გადაერქვა. და დაემატა რამდენიმე ველი. მე-10 ვერსიაში გამოჩნდა ველები, რომლებიც საშუალებას გაძლევთ შეაფასოთ რეპლიკაციის შეფერხება წამებში. ძალიან კომფორტულია. მე-10 ვერსიამდე შესაძლებელი იყო რეპლიკაციის შეფერხების შეფასება ბაიტებში. ეს ვარიანტი რჩება მე-10 ვერსიაში, ანუ თქვენ შეგიძლიათ აირჩიოთ ის, რაც უფრო მოსახერხებელია თქვენთვის - შეაფასეთ ჩამორჩენა ბაიტებში ან შეაფასეთ ჩამორჩენა წამებში. ბევრი ადამიანი ორივეს აკეთებს.

მაგრამ მიუხედავად ამისა, რეპლიკაციის ჩამორჩენის შესაფასებლად, თქვენ უნდა იცოდეთ ჟურნალის პოზიცია გარიგებაში. და ეს ტრანზაქციის ჟურნალის პოზიციები ზუსტად არის pg_stat_replication ხედში. შედარებით რომ ვთქვათ, ჩვენ შეგვიძლია ავიღოთ ორი წერტილი ტრანზაქციის ჟურნალში pg_xlog_location_diff() ფუნქციის გამოყენებით. გამოთვალეთ დელტა მათ შორის და მიიღეთ რეპლიკაციის ჩამორჩენა ბაიტებში. ეს არის ძალიან მოსახერხებელი და მარტივი.

მე-10 ვერსიაში ამ ფუნქციას ეწოდა pg_wal_lsn_diff(). ზოგადად, ყველა ფუნქციაში, ხედსა და კომუნალურ პროგრამაში, სადაც სიტყვა "xlog" გამოჩნდა, იგი შეიცვალა მნიშვნელობით "wal". ეს ეხება როგორც ხედებს, ასევე ფუნქციებს. ეს არის ასეთი ინოვაცია.

გარდა ამისა, მე-10 ვერსიაში დაემატა ხაზები, რომლებიც კონკრეტულად აჩვენებს ჩამორჩენას. ეს არის ჩაწერის ჩამორჩენა, ფლეშის ჩამორჩენა, გამეორების ჩამორჩენა. ანუ, მნიშვნელოვანია ამ ნივთების მონიტორინგი. თუ დავინახავთ, რომ გვაქვს რეპლიკაციის ჩამორჩენა, მაშინ უნდა გამოვიკვლიოთ რატომ გაჩნდა, საიდან გაჩნდა და გამოვასწოროთ პრობლემა.

სისტემური მეტრიკის მიხედვით თითქმის ყველაფერი წესრიგშია. როდესაც ნებისმიერი მონიტორინგი იწყება, ის იწყება სისტემის მეტრიკებით. ეს არის პროცესორების, მეხსიერების, სვოპის, ქსელის და დისკის განკარგვა. თუმცა, ბევრი პარამეტრი ნაგულისხმევად არ არის.

თუ ყველაფერი რიგზეა გადამუშავების პროცესში, მაშინ პრობლემებია დისკის გადამუშავებასთან დაკავშირებით. როგორც წესი, მონიტორინგის დეველოპერები ამატებენ ინფორმაციას გამტარუნარიანობის შესახებ. ეს შეიძლება იყოს iops ან ბაიტი. მაგრამ მათ ავიწყდებათ ლატენტურობა და დისკის მოწყობილობების გამოყენება. ეს უფრო მნიშვნელოვანი პარამეტრებია, რომლებიც საშუალებას გვაძლევს შევაფასოთ რამდენად დატვირთულია ჩვენი დისკები და რამდენად ნელია ისინი. თუ გვაქვს მაღალი შეყოვნება, მაშინ ეს ნიშნავს, რომ დისკებთან არის გარკვეული პრობლემები. თუ ჩვენ გვაქვს მაღალი უტილიზაცია, ეს ნიშნავს, რომ დისკები არ უმკლავდებიან. ეს უკეთესი მახასიათებლებია ვიდრე გამტარუნარიანობა.

უფრო მეტიც, ამ სტატისტიკის მიღება ასევე შესაძლებელია /proc ფაილური სისტემიდან, როგორც ეს ხდება გადამუშავების პროცესორებისთვის. არ ვიცი, რატომ არ ემატება ეს ინფორმაცია მონიტორინგს. მაგრამ, მიუხედავად ამისა, მნიშვნელოვანია, რომ ეს იყოს თქვენს მონიტორინგში.

იგივე ეხება ქსელის ინტერფეისებს. არსებობს ინფორმაცია ქსელის გამტარუნარიანობის შესახებ პაკეტებში, ბაიტებში, მაგრამ მიუხედავად ამისა, არ არის ინფორმაცია შეყოვნების შესახებ და არ არის ინფორმაცია გამოყენების შესახებ, თუმცა ეს ასევე სასარგებლო ინფორმაციაა.

ნებისმიერ მონიტორინგს აქვს ნაკლოვანებები. და არ აქვს მნიშვნელობა რა სახის მონიტორინგს ახორციელებთ, ის ყოველთვის არ აკმაყოფილებს გარკვეულ კრიტერიუმებს. მაგრამ მიუხედავად ამისა, ისინი ვითარდებიან, ემატება ახალი ფუნქციები და ახალი ნივთები, ასე რომ აირჩიეთ რამე და დაასრულეთ.

და იმისათვის, რომ დაასრულოთ, ყოველთვის უნდა გქონდეთ წარმოდგენა იმაზე, თუ რას ნიშნავს მოწოდებული სტატისტიკა და როგორ შეგიძლიათ გამოიყენოთ ისინი პრობლემების გადასაჭრელად.

და რამდენიმე საკვანძო პუნქტი:

• თქვენ ყოველთვის უნდა აკონტროლოთ ხელმისაწვდომობა და გქონდეთ დაფები, რათა სწრაფად შეაფასოთ, რომ ყველაფერი წესრიგშია მონაცემთა ბაზაში.
• თქვენ ყოველთვის უნდა გქონდეთ წარმოდგენა იმის შესახებ, თუ რა კლიენტები მუშაობენ თქვენს მონაცემთა ბაზასთან, რათა თავიდან აიცილოთ ცუდი კლიენტები და ჩამოაგდოთ ისინი.
• მნიშვნელოვანია იმის შეფასება, თუ როგორ მუშაობენ ეს კლიენტები მონაცემებთან. თქვენ უნდა გქონდეთ წარმოდგენა თქვენი დატვირთვის შესახებ.
• მნიშვნელოვანია იმის შეფასება, თუ როგორ ყალიბდება ეს დატვირთვა, რა მოთხოვნების დახმარებით. თქვენ შეგიძლიათ შეაფასოთ მოთხოვნები, შეგიძლიათ მათი ოპტიმიზაცია, მათი რეფაქტორირება, მათთვის ინდექსების შექმნა. Ეს ძალიან მნიშვნელოვანია.
• ფონური პროცესები შეიძლება უარყოფითად იმოქმედოს კლიენტის მოთხოვნებზე, ამიტომ მნიშვნელოვანია იმის მონიტორინგი, რომ ისინი არ იყენებენ ძალიან ბევრ რესურსს.
• სისტემის მეტრიკა საშუალებას გაძლევთ შეადგინოთ გეგმები თქვენი სერვერების სკალირებისა და ტევადობის გაზრდისთვის, ამიტომ მნიშვნელოვანია მათი თვალყურის დევნება და შეფასებაც.

თუ თქვენ დაინტერესებული ხართ ამ თემით, შეგიძლიათ მიჰყევით ამ ბმულებს.
http://bit.do/stats_collector - ეს არის სტატისტიკის შემგროვებლის ოფიციალური დოკუმენტაცია. არსებობს ყველა სტატისტიკური ხედვის აღწერა და ყველა ველის აღწერა. შეგიძლიათ მათი წაკითხვა, გაგება და ანალიზი. და მათზე დაყრდნობით შექმენით თქვენი გრაფიკები და დაამატეთ ისინი თქვენს მონიტორინგს.

მოითხოვეთ მაგალითები:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

ეს არის ჩვენი კორპორატიული საცავი და ჩემი საკუთარი. ისინი შეიცავს მაგალითებს. არ არის შეკითხვები სერიებიდან სელექციიდან. უკვე არის მზა მოთხოვნები შეერთებით, საინტერესო ფუნქციების გამოყენებით, რაც საშუალებას გაძლევთ გადააქციოთ დაუმუშავებელი რიცხვები წასაკითხად, მოსახერხებელ მნიშვნელობებად, ანუ ეს არის ბაიტები, დრო. თქვენ შეგიძლიათ აირჩიოთ ისინი, შეხედოთ მათ, გააანალიზოთ ისინი, დაამატოთ ისინი თქვენს მონიტორინგში, ააწყოთ თქვენი მონიტორინგი მათზე დაყრდნობით.

კითხვები

კითხვა: თქვენ თქვით, რომ არ გააკეთებთ ბრენდების რეკლამას, მაგრამ მე მაინც მაინტერესებს - რა სახის დაფებს იყენებთ თქვენს პროექტებში?
პასუხი: განსხვავდება. ხდება ისე, რომ მივდივართ მომხმარებელთან და მას უკვე აქვს საკუთარი მონიტორინგი. და ჩვენ ვურჩევთ მომხმარებელს, თუ რა უნდა დაემატოს მათ მონიტორინგს. ყველაზე ცუდი სიტუაციაა Zabbix-თან. რადგან მას არ აქვს TopN გრაფიკების აგების შესაძლებლობა. ჩვენ თვითონ ვიყენებთ ოკმეტრი, რადგან ჩვენ ამ ბიჭებთან კონსულტაციებს ვაწარმოებდით მონიტორინგზე. ისინი აკონტროლებდნენ PostgreSQL-ს ჩვენი ტექნიკური მახასიათებლების საფუძველზე. მე ვწერ ჩემს საკუთარ ცხოველურ პროექტს, რომელიც აგროვებს მონაცემებს პრომეთეს მეშვეობით და ასახავს მას გრაფანა. ჩემი ამოცანაა შევქმნა ჩემი ექსპორტიორი პრომეთეში და შემდეგ ყველაფერი გავაფორმო გრაფანაში.

კითხვა: არის თუ არა AWR ანგარიშების ან... აგრეგაციის ანალოგი? იცით მსგავსი რამ?
პასუხი: კი, ვიცი რა არის AWR, მაგარი რამეა. ამ დროისთვის არსებობს სხვადასხვა სახის ველოსიპედები, რომლებიც ახორციელებენ დაახლოებით შემდეგ მოდელს. დროის გარკვეულ ინტერვალში, ზოგიერთი საბაზისო ხაზი იწერება იმავე PostgreSQL-ში ან ცალკე საცავში. შეგიძლიათ ინტერნეტში მოძებნოთ ისინი გუგლში, ისინი იქ არიან. ასეთი რამის ერთ-ერთი შემქმნელი ზის sql.ru ფორუმზე PostgreSQL თემაში. შეგიძლიათ იქ დაიჭიროთ. დიახ, არის ასეთი რამ, მათი გამოყენება შესაძლებელია. პლუს თავის pgCenter მე ასევე ვწერ რაღაცას, რომელიც გაძლევს იგივეს გაკეთების საშუალებას.

PS1 თუ იყენებთ postgres_exporter-ს, რა დაფას იყენებთ? რამდენიმე მათგანია. ისინი უკვე მოძველებულია. იქნებ საზოგადოებამ შექმნას განახლებული შაბლონი?

PS2 წაშლილია pganalyze, რადგან ეს არის საკუთრების SaaS შეთავაზება, რომელიც ფოკუსირებულია შესრულების მონიტორინგზე და ავტომატური დარეგულირების წინადადებებზე.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

რომელ თვითმასპინძელ postgresql მონიტორინგს მიგაჩნიათ საუკეთესოდ?

• 30,0%Zabbix + დამატებები ალექსეი ლესოვსკისგან ან zabbix 4.4 ან libzbxpgsql + zabbix libzbxpgsql + zabbix3

• 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 არის საკუთრების SaaS - მე არ შემიძლია მისი წაშლა1

• 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 მომხმარებელმა. 26-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com