Linux-ის დაყენება PostgreSQL მუშაობის გასაუმჯობესებლად. ილია კოსმოდემიანსკი

ილია კოსმოდემიანსკის 2015 წლის მოხსენების ტრანსკრიპტი "Linux tuning PostgreSQL-ის მუშაობის გასაუმჯობესებლად"

პასუხისმგებლობის შეზღუდვა: აღვნიშნავ, რომ ეს მოხსენება დათარიღებულია 2015 წლის ნოემბრით - გავიდა 4 წელზე მეტი და გავიდა დიდი დრო. ანგარიშში განხილული ვერსია 9.4 აღარ არის მხარდაჭერილი. ბოლო 4 წლის განმავლობაში გამოვიდა PostgreSQL-ის 5 ახალი გამოშვება და Linux-ის ბირთვის 15 ვერსია. თუ თქვენ გადაწერთ ამ პასაჟებს, თქვენ მიიღებთ სხვა მოხსენებას. მაგრამ აქ განვიხილავთ Linux-ის ფუნდამენტურ დარეგულირებას PostgreSQL-ისთვის, რომელიც დღესაც აქტუალურია.

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

რაზე ვისაუბროთ? თუ თქვენ ურთიერთობთ PostgreSQL-თან, მაშინ გარკვეულწილად უნდა იყოთ UNIX-ის ადმინი. Რას ნიშნავს? თუ შევადარებთ Oracle-ს და PostgreSQL-ს, მაშინ Oracle-ში თქვენ უნდა იყოთ 80% DBA მონაცემთა ბაზის ადმინისტრატორი და 20% Linux-ის ადმინი.

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

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

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

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

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

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

შეგიძლიათ დააკონკრეტოთ:

• ᲞᲠᲝᲪᲔᲡᲝᲠᲘ.
• მეხსიერება.
• შენახვა.
• სხვა. ამის შესახებ ბოლოს საჭმელად ვისაუბრებთ. თუნდაც, მაგალითად, ისეთი პარამეტრები, როგორიცაა ენერგიის დაზოგვის პოლიტიკა, შეუძლია გავლენა მოახდინოს შესრულებაზე ძალიან არაპროგნოზირებადი და არა ყველაზე სასიამოვნო გზით.

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

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

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

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

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

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

და ეს შეყვანა-გამომავალი ასე თუ ისე ხდება ამ საკითხის მეშვეობით.

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

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

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

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

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

და მოდით გავიაროთ თითოეული ეს წერტილი.

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

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

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

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

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

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

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

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

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

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

Რატომ არის, რომ? როგორც ჩანს, პირიქით უნდა იყოს. ეს ხდება ერთი მარტივი მიზეზის გამო: ჩვენ გვჭირდება ბევრი მეხსიერება გვერდის ქეშისთვის - ათობით, ასობით გიგაბაიტი.

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

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

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

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

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

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

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

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

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

Რატომ არის, რომ? Რა ხდება? ოპერაციული სისტემა ანაწილებს მეხსიერებას პატარა ნაჭრებად. ეს ძალიან მოსახერხებელია, ასე მოხდა ისტორიულად. და თუ დეტალურად შევისწავლით, OS-მ უნდა თარგმნოს ვირტუალური მისამართები ფიზიკურად. და ეს პროცესი არ არის უმარტივესი, ამიტომ ოპერაციული ოპერაციების შედეგს ოპერაციული სისტემა ქეშირებს Translation Lookaside Buffer-ში (TLB).

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

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

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

და როგორ შეიძლება ამის დამეგობრება PostgreSQL-თან? პირველ რიგში, უზარმაზარი გვერდები უნდა იყოს ჩართული Linux-ის ბირთვში.

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

და თუ თქვენი მთელი სერვერი ეძღვნება PostgreSQL-ს, მაშინ კარგი საწყისი წერტილია RAM-ის ან 25% გაზიარებული ბუფერების გამოყოფა, ან 75%, თუ დარწმუნებული ხართ, რომ თქვენი მონაცემთა ბაზა აუცილებლად ჯდება ამ 75%-ში. საწყისი წერტილი პირველი. და გაითვალისწინეთ, თუ თქვენ გაქვთ 256 GB ოპერატიული მეხსიერება, მაშინ, შესაბამისად, გექნებათ 64 GB დიდი ბუფერები. გამოთვალეთ დაახლოებით გარკვეული ზღვრით - რაზე უნდა იყოს მითითებული ეს მაჩვენებელი.

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

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

მაგრამ საზოგადოებამ ყურადღება მიაქცია ამ პრობლემას და 9.4-ში მათ ეს ღონისძიება ძალიან კარგად გადაამუშავეს. და 9.4-ში გამოჩნდა პარამეტრი postgresql.conf-ში, რომელშიც შეგიძლიათ ჩართოთ try, ჩართოთ ან გამორთოთ.

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

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

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

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

და ეს იქნება ძალიან უსიამოვნო მრავალი თვალსაზრისით. და მთავარი პრობლემა ის არის, რომ თანამედროვე ბირთვები ოდნავ განსხვავებულად იქცევიან Linux-ის ძველი ბირთვებისგან. და ეს საკმაოდ უსიამოვნოა გადადგმული ნაბიჯით, რადგან როდესაც ვსაუბრობთ რაიმე სახის მუშაობაზე swap-ით, ეს მთავრდება OOM-მკვლელის დროულად მოსვლით. და OOM-მკვლელი, რომელიც დროულად არ მივიდა და ჩამოაგდო PostgreSQL, უსიამოვნოა. ამის შესახებ ყველამ იცის, ანუ ბოლო მომხმარებელამდე.

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

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

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

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

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

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

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

აქ მე მაქვს ორი სურათი. ახლა აგიხსნით რა არის. ეს არის ორი დროში დაკავშირებული გრაფიკი. პირველი გრაფიკი არის დისკის გამოყენება. აქ ის თითქმის 90%-ს აღწევს დროის ამ მომენტში. თუ თქვენ გაქვთ მონაცემთა ბაზის უკმარისობა ფიზიკურ დისკებთან, RAID კონტროლერის გამოყენების 90%-ით, მაშინ ეს ცუდი ამბავია. ეს ნიშნავს, რომ ცოტა მეტი და მიაღწევს 100-ს და I/O შეჩერდება.

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

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

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

თუ ლინუქსის კუთხით შეხედავთ, თუ აიღეთ კარგი აპარატურა, სწორად დააკონფიგურირეთ, ნორმალურად დააკონფიგურირეთ PostgreSQL ისე, რომ ეს გამშვები პუნქტები ნაკლებად ხშირად გახადოს, დროთა განმავლობაში გაავრცელოთ ისინი ერთმანეთში, შემდეგ გადადიხართ Debian-ის ნაგულისხმევ პარამეტრებში. Linux-ის დისტრიბუციების უმეტესობისთვის ეს არის სურათი: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Რას ნიშნავს? ერთი ჩაწითლებული დემონი გამოჩნდა ბირთვიდან 2.6. Pdglush, იმისდა მიხედვით, თუ ვინ რომელს იყენებს, რომელიც ეწევა ბირთვის ბუფერიდან ჭუჭყიანი გვერდების ფონური გადაგდებას და გადაგდებას, როცა აუცილებელია ბინძური გვერდების გაუქმება, რაც არ უნდა მოხდეს, როცა ფონური გადაგდება არ უწყობს ხელს.

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

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

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

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

წარმოიდგინეთ, რომ გაქვთ 128 GB ოპერატიული მეხსიერება. 12,8 GB შემოდის თქვენს დისკის სისტემაში. და რაც არ უნდა ქეში გქონდეს იქ, არ აქვს მნიშვნელობა რა მასივი გქონდეს იქ, ისინი დიდხანს არ გაგრძელდება.

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

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

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

აქ არის კიდევ ორი ​​მნიშვნელოვანი პუნქტი, რომელიც სცილდება ამ მოხსენების ფარგლებს. ეს პარამეტრები უნდა შეესაბამებოდეს postgresql.conf-ის პარამეტრებს, ანუ საგუშაგოების პარამეტრებს. და თქვენი დისკის სისტემა ადეკვატურად უნდა იყოს კონფიგურირებული. თუ თქვენ გაქვთ ქეში RAID-ზე, მაშინ მას უნდა ჰქონდეს ბატარეა. ხალხი ყიდულობს RAID-ს კარგი ქეშით ბატარეის გარეშე. თუ თქვენ გაქვთ SSD-ები RAID-ში, მაშინ ისინი უნდა იყოს სერვერული, იქ უნდა იყოს კონდენსატორები. აქ არის დეტალური ჩამონათვალი. ეს ბმული შეიცავს ჩემს ანგარიშს იმის შესახებ, თუ როგორ უნდა დააკონფიგურიროთ შესრულების დისკი PostgreSQL-ში. იქ არის ყველა ეს ჩამონათვალი.

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

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

და როგორ ანგრევენ შენს ცხოვრებას? რა არის sched_migration_cost? Linux-ზე, განრიგს შეუძლია პროცესის მიგრაცია ერთი CPU-დან მეორეზე. და PostgreSQL-სთვის, რომელიც ახორციელებს შეკითხვებს, სხვა CPU-ზე მიგრაცია სრულიად გაუგებარია. ოპერაციული სისტემის თვალსაზრისით, როდესაც ფანჯრებს ცვლით openoffice-სა და ტერმინალს შორის, ეს შეიძლება კარგი იყოს, მაგრამ მონაცემთა ბაზისთვის ეს ძალიან ცუდია. ამიტომ, გონივრული პოლიტიკაა მიგრაციის_ღირებულების დაყენება რაიმე დიდ მნიშვნელობაზე, მინიმუმ რამდენიმე ათასი ნანოწამში.

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

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

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

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

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

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

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

და, შესაბამისად, გუბერნატორი მხოლოდ შესრულებაა. Ondemand, powersave და ყველაფერი სხვა შენზე არ არის.

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

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

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

კითხვები:

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

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

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

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

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

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

მაქვს შეკითხვა Amazon AWS-თან დაკავშირებით. მათ აქვთ წინასწარ კონფიგურირებული სურათები. ერთ-ერთ მათგანს Amazon RDS ჰქვია. არის რაიმე მორგებული პარამეტრები მათი ოპერაციული სისტემისთვის?

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

რატომ არ აქვს ეფექტი გამჭვირვალე უზარმაზარ გვერდებს უზარმაზარ TLB-თან შედარებით?

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

წყარო: www.habr.com