ტიპიური შეცდომები აპლიკაციებში, რომლებიც იწვევს bloat-ს postgresql-ში. ანდრეი სალნიკოვი

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

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

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

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

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

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

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

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

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

საშუალო პასუხის დრო სერვერზე ასევე სტაბილური და მოკლეა. ეს არის ზედა მარჯვენა გრაფიკი.

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

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

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

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

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

სად მივყავართ ასეთ რაღაცეებს?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

რა მოხდა ავარიის დროს? როგორ მოხდა ეს პროცესი იქ?

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

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

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

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

რა შედეგები შეიძლება მოჰყვეს ჩვენთვის?

• ჩემს მაგალითში ცხრილი და ინდექსი 150-ჯერ გაიზარდა. ზოგიერთ ჩვენს კლიენტს ჰქონდა უფრო ფატალური შემთხვევები, როდესაც მათ უბრალოდ დაიწყეს დისკის სივრცის ამოწურვა.
• თავად მაგიდების ზომა არასოდეს შემცირდება. ავტოვაკუუმს ზოგიერთ შემთხვევაში შეუძლია მაგიდის კუდის გაჭრა, თუ მხოლოდ მკვდარი ხაზებია. მაგრამ იმის გამო, რომ მუდმივი ბრუნვაა, ერთი მწვანე ხაზი შეიძლება გაიყინოს ბოლოს და არ განახლდეს, ხოლო ყველა დანარჩენი ჩაიწერება სადღაც ფირფიტის დასაწყისში. მაგრამ ეს ისეთი საეჭვო მოვლენაა, რომ თქვენი მაგიდა თავად შემცირდება ზომით, ასე რომ თქვენ არ უნდა გქონდეთ ამის იმედი.
• მონაცემთა ბაზას სჭირდება უსარგებლო ხაზების მთელი თაიგულის დალაგება. ჩვენ ვფლანგავთ დისკის რესურსებს, ვფლანგავთ პროცესორის რესურსებს და ელექტროენერგიას.
• და ეს პირდაპირ გავლენას ახდენს ჩვენს აპლიკაციაზე, რადგან თუ დასაწყისში ჩვენ დავხარჯეთ 10 მილიწამი მოთხოვნაზე, 10 მილიწამი ჩვენს კოდზე, მაშინ ავარიის დროს დავიწყეთ წამის დახარჯვა მოთხოვნაზე და 10 მილიწამი კოდზე, ე.ი. აპლიკაციის შესრულების სიდიდე შემცირდა. და როდესაც უბედური შემთხვევა მოგვარდა, დავიწყეთ 20 მილიწამის დახარჯვა მოთხოვნაზე, 10 მილიწამის კოდზე. ეს ნიშნავს, რომ პროდუქტიულობა ჯერ კიდევ ერთნახევარჯერ შემცირდა. და ეს ყველაფერი არის ერთი ტრანზაქციის გამო, რომელიც გაყინულია, შესაძლოა ჩვენი ბრალით.
• და კითხვა: „როგორ დავიბრუნოთ ყველაფერი?“ ისე, რომ ჩვენთან ყველაფერი კარგად იყოს და თხოვნები ისეთივე სწრაფად შემოვიდეს, როგორც ავარიამდე.

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

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

მას შემდეგ რაც იპოვით ამ ცხრილებს, თქვენ უნდა შეკუმშოთ ისინი. ამისთვის უკვე არსებობს ინსტრუმენტები. ჩვენს კომპანიაში ვიყენებთ სამ ინსტრუმენტს. პირველი არის ჩაშენებული VACUUM FULL. ის არის სასტიკი, მკაცრი და დაუნდობელი, მაგრამ ზოგჯერ ის ძალიან სასარგებლოა. Pg_repack и pgcompacttable - ეს არის მესამე მხარის უტილიტები ცხრილების შეკუმშვისთვის. და ისინი უფრო ფრთხილად ეპყრობიან მონაცემთა ბაზას.

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

მას შემდეგ რაც ყველაფერი გამოვასწორეთ და დავრწმუნდით, რომ ყველაფერი კარგადაა, უნდა ვიცოდეთ როგორ ავიცილოთ თავიდან ეს სიტუაცია მომავალში:

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

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

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

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

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

მეორე ამბავი, რომელშიც ჩვენ ვანაწილებთ დატვირთვას და ვაუმჯობესებთ სერვერის რესურსებს

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

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

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

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

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

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

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

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

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

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

როგორი იქნება, თუ არ ვიცით, რაზე ვსაუბრობდი ადრე?

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

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

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

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

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

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

• არ ჩართოთ hot_standby_feedback? დიახ, არ არის რეკომენდებული მისი ჩართვა განსაკუთრებით ძლიერი მიზეზების გარეშე. რადგან ეს გადახვევა პირდაპირ გავლენას ახდენს Master სერვერზე და აჩერებს იქ ავტოვაკუუმის მუშაობას. ზოგიერთ რეპლიკაზე მისი ჩართვით და მისი დავიწყების გზით, შეგიძლიათ მოკლათ ოსტატი და მიიღოთ დიდი პრობლემები აპლიკაციასთან დაკავშირებით.
• გავზარდოთ max_standby_streaming_delay? დიახ, ანგარიშებისთვის ეს მართალია. თუ თქვენ გაქვთ სამსაათიანი ანგარიში და არ გსურთ, რომ ის ავარიული იყოს რეპლიკაციის კონფლიქტების გამო, უბრალოდ გაზარდეთ დაყოვნება. გრძელვადიანი ანგარიში არასოდეს საჭიროებს მონაცემთა ბაზაში ახლავე მოსულ მონაცემებს. თუ თქვენ გაქვთ ის სამი საათის განმავლობაში, მაშინ იყენებთ მას ძველი მონაცემების პერიოდისთვის. და თქვენთვის, სამსაათიანი დაგვიანება იქნება თუ ექვსსაათიანი შეფერხება, არავითარი მნიშვნელობა არ ექნება, მაგრამ თქვენ მიიღებთ ანგარიშებს თანმიმდევრულად და არ შეგექმნებათ პრობლემები მათი დაცემით.
• ბუნებრივია, თქვენ უნდა აკონტროლოთ ხანგრძლივი სესიები რეპლიკაზე, განსაკუთრებით თუ გადაწყვეტთ ჩართოთ hot_standby_feedback რეპლიკაზე. რადგან ყველაფერი შეიძლება მოხდეს. ჩვენ მივეცით ეს რეპლიკა დეველოპერს, რათა მან შეძლოს მოთხოვნების ტესტირება. გიჟური თხოვნა დაწერა. მან გაუშვა და წავიდა ჩაის დასალევად და ჩვენ მივიღეთ დამკვიდრებული ოსტატი. ან იქნებ არასწორ აპლიკაციაში ჩავსვით. სიტუაციები მრავალფეროვანია. რეპლიკებზე სესიების მონიტორინგი უნდა მოხდეს ისევე ყურადღებით, როგორც Master-ზე.
• და თუ თქვენ გაქვთ სწრაფი და გრძელი მოთხოვნები რეპლიკებზე, მაშინ ამ შემთხვევაში უმჯობესია მათი გაყოფა დატვირთვის გასანაწილებლად. ეს არის streaming_delay-ის ბმული. სწრაფი პირებისთვის, გქონდეთ ერთი რეპლიკა მცირე რეპლიკაციის დაგვიანებით. გრძელვადიანი ანგარიშგების მოთხოვნებისთვის, გქონდეთ ასლი, რომელიც შეიძლება დაგვიანდეს 6 საათით ან დღით. ეს სრულიად ნორმალური სიტუაციაა.

ჩვენ ვიხსნით შედეგებს იმავე გზით:

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

მეორე ამბავი აქ მთავრდება. გადავიდეთ მესამე ამბავზე.

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

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

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

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

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

მიგრაცია წარმატებული იყო, მაგრამ:

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

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

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

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

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

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

და ამავდროულად ჩვენ არ მივიღებთ შებერილობას და არ დაზარალდება შესრულების თვალსაზრისით.

აქ მთავრდება მესამე ისტორია.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

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

სანამ bloat-ს ეძებთ, უნდა დააინსტალიროთ გაფართოება pgstattuple.

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

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

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

ახლა იმის შესახებ, თუ როგორ უნდა გამოსწორდეს შეშუპება:

• თუ გვაქვს პატარა ტაბლეტი და კარგი დისკები, ანუ ტაბლეტზე გიგაბაიტამდე, სავსებით შესაძლებელია VACUUM FULL-ის გამოყენება. ის წაიღებს შენგან ექსკლუზიურ საკეტს მაგიდაზე რამდენიმე წამით და კარგი, მაგრამ ყველაფერს სწრაფად და მკაცრად გააკეთებს. რას აკეთებს VACUUM FULL? ის იღებს ექსკლუზიურ საკეტს მაგიდაზე და გადაწერს ცოცხალ რიგებს ძველი ცხრილებიდან ახალ ცხრილში. და ბოლოს ის ცვლის მათ. ის შლის ძველ ფაილებს და ცვლის ძველს ახლით. მაგრამ მისი მუშაობის ხანგრძლივობისთვის, მას სჭირდება ექსკლუზიური საკეტი მაგიდაზე. ეს ნიშნავს, რომ თქვენ ვერაფერს გააკეთებთ ამ ცხრილთან: არც დაწეროთ, არც წაიკითხოთ და არც შეცვალოთ იგი. და VACUUM FULL საჭიროებს დამატებით ადგილს დისკზე მონაცემების ჩასაწერად.
• შემდეგი ინსტრუმენტი pg_repack. თავისი პრინციპით, ის ძალიან ჰგავს VACUUM FULL-ს, რადგან ის ასევე გადაწერს მონაცემებს ძველი ფაილებიდან ახალში და ანაცვლებს მათ ცხრილში. მაგრამ ამავე დროს, ის არ იღებს ექსკლუზიურ საკეტს მაგიდაზე მუშაობის დასაწყისში, არამედ იღებს მას მხოლოდ იმ მომენტში, როდესაც მას უკვე აქვს მზა მონაცემები ფაილების ჩანაცვლების მიზნით. მისი დისკის რესურსის მოთხოვნები VACUUM FULL-ის მოთხოვნების მსგავსია. თქვენ გჭირდებათ დამატებითი ადგილი დისკზე და ეს ზოგჯერ კრიტიკულია, თუ თქვენ გაქვთ ტერაბაიტის ცხრილები. და ის საკმაოდ პროცესორისთვის მშიერია, რადგან აქტიურად მუშაობს I/O-თან.
• მესამე უტილიტა არის pgcompacttable. ის უფრო ფრთხილია რესურსებთან, რადგან მუშაობს ოდნავ განსხვავებული პრინციპების მიხედვით. pgcompacttable-ის მთავარი იდეა არის ის, რომ ის გადააქვს ყველა ცოცხალი სტრიქონი ცხრილის დასაწყისში, ცხრილის განახლებების გამოყენებით. და შემდეგ ის აწარმოებს ვაკუუმს ამ მაგიდაზე, რადგან ვიცით, რომ გვაქვს ცოცხალი რიგები დასაწყისში და მკვდარი რიგები ბოლოს. და თავად ვაკუუმი წყვეტს ამ კუდს, ანუ მას არ სჭირდება ბევრი დამატებითი ადგილი დისკზე. და ამავდროულად, რესურსების თვალსაზრისით მაინც შეიძლება მისი შეკუმშვა.

ყველაფერი ხელსაწყოებით.

თუ მოგეჩვენებათ, რომ bloat თემა საინტერესოა შიგნით უფრო ღრმად შესწავლის თვალსაზრისით, აქ არის რამდენიმე სასარგებლო ბმული:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - ეს ჩემი კოლეგის მოხსენებაა. ზოგადია იმის შესახებ, თუ სად მიდის პოსტგრესის სივრცე მისი მუშაობისა და ცხოვრების განმავლობაში. და არის ძალიან დიდი და დეტალური ტექნიკური ნაწილი მონაცემთა ბაზის ადმინისტრატორებისთვის bloat-ის შესახებ.
• https://github.com/dataegret/pg-utils – ეს არის ბმული ჩვენს საცავთან, სადაც ჩვენ ვინახავთ სასარგებლო სკრიპტების კრებულს მონაცემთა ბაზის მდგომარეობის შესამოწმებლად. აქ შეგიძლიათ იპოვოთ სკრიპტები bloat-ის მოსაძებნად.
• მესამე и მეოთხე ბმულები ინსტრუმენტებზე, რომლებიც დაგეხმარებათ ნიშნების შემცირებაში.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - ეს ჩემი კოლეგის პოსტია. იქ ის საკმაოდ სერიოზულად და ტექნიკურად აანალიზებს აფეთქებას ადმინისტრატორებთან დაახლოებულ დონეზე.

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

კითხვები

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

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

მე ვარ ადმინისტრატორი.

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

ყოველ 5 წუთში უნდა შევიდე და ვნახო?

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

არსებობს რაიმე აშკარა მიზეზები, თუ რატომ ხდება ეს?

რამდენიმე ჩამოვთვალე. სხვა უფრო რთული მაგალითები. და შეიძლება დიდი ხნის განმავლობაში იყოს საუბარი.

გმადლობთ ანგარიშისთვის! მინდოდა დამეზუსტებინა pg_repack უტილიტას შესახებ. თუ ის არ გააკეთებს ექსკლუზიურ საკეტს, მაშინ...

ის აკეთებს ექსკლუზიურ საკეტს.

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

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

ანუ ის რეალურად აკეთებს ამას საბოლოოდ?

საბოლოო ჯამში, ის იღებს ექსკლუზიურ საკეტს ამ ფაილების გასაცვლელად.

იქნება ეს უფრო სწრაფი ვიდრე VACUUM FULL?

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

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

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

Მე მესმის. მაგრამ ეს არ არის ის, რაც კითხვაზეა. არ დავამთავრე. დავუშვათ, გვაქვს მაგიდა. მას აქვს ცვლადი ზომის ველები. და თუ რაიმე ახლის ჩასმას ვცდილობ, ის უბრალოდ ძველ უჯრედში არ ჯდება.

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

გმადლობთ ანგარიშისთვის! მისაღებია თუ არა განცხადების დროის ამოწურვის მოთხოვნების გამოყენება ხანგრძლივობის შესაზღუდად?

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

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

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

ანუ განახლებისთანავე იხურება?

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

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

სერვერზე არსებული სივრცე სათანადოდ უნდა იყოს მონიტორინგი.

მაგალითად, DBA წავიდა ჩაიზე, იყო კურორტზე და ა.შ.

როდესაც ფაილური სისტემა იქმნება, იქმნება მაინც რაიმე სახის სარეზერვო სივრცე, სადაც მონაცემები არ იწერება.

რა მოხდება, თუ ის სრულიად ნულის ქვემოთაა?

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

არის სხვა იარაღები?

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

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

მათაც ფუთავენ.

მაგრამ ვაკუუმი არ მოქმედებს ინდექსზე?

ზოგი მუშაობს ინდექსით. მაგალითად, pg_rapack, pgcompacttable. ვაკუუმი ხელახლა ქმნის ინდექსებს და გავლენას ახდენს მათზე. VACUUM FULL-ით, იდეა არის ყველაფრის გადაწერა, ანუ ის მუშაობს ყველასთან.

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

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

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

ეს არის სერვისი ოკმეტრი.

არის ეს კომერციული პროდუქტი?

დიახ. ეს არის კომერციული პროდუქტი.

წყარო: www.habr.com