Nikolay Samoxvalovun “PostgreSQL-i tənzimləməyə sənaye yanaşması: verilənlər bazası üzərində təcrübələr” adlı məruzəsinin stenoqramını oxumağı təklif edirəm.
Shared_buffers = 25% - bu çoxdur, yoxsa az? Yoxsa düzdür? Bu, çox köhnəlmiş tövsiyənin sizin xüsusi işinizə uyğun olub olmadığını necə bilirsiniz?
Postgresql.conf parametrlərinin "böyüklər kimi" seçilməsi məsələsinə yanaşmağın vaxtıdır. Kor "avtomatik tənzimləyicilərin" və ya məqalə və bloqların köhnəlmiş məsləhətlərinin köməyi ilə deyil, aşağıdakılara əsaslanır:
- avtomatik olaraq, böyük miqdarda və "döyüş" üçün mümkün qədər yaxın şəraitdə aparılan verilənlər bazası üzərində ciddi şəkildə yoxlanılmış təcrübələr;
- DBMS və ƏS-nin xüsusiyyətlərini dərindən başa düşmək.
Nancy CLI istifadə edərək (), biz müxtəlif vəziyyətlərdə, müxtəlif layihələrdə xüsusi bir nümunəyə - bədnam paylaşılan_buferlərə baxacağıq və infrastrukturumuz, verilənlər bazamız və yükləməmiz üçün optimal parametrləri necə seçəcəyimizi anlamağa çalışacağıq.
Verilənlər bazası ilə təcrübələr haqqında danışacağıq. Bu, altı aydan bir qədər çox davam edən bir hekayədir.
Bir az mənim haqqımda. Postgres ilə 14 ildən artıq təcrübə. Bir sıra sosial şəbəkə şirkətləri yaradılıb. Postgres hər yerdə istifadə olunurdu və istifadə olunur.
Həmçinin Meetup-da RuPostgres qrupu, dünyada 2-ci yer. Yavaş-yavaş 2 nəfərə yaxınlaşırıq. RuPostgres.org.
Müxtəlif konfransların kompüterlərində, o cümlədən Highload, mən verilənlər bazası, xüsusən Postgres üçün əvvəldən cavabdehəm.
Və son bir neçə ildə mən Postgres konsaltinq təcrübəmi buradan 11 saat qurşağına yenidən başladım.
Bir neçə il əvvəl bunu edəndə Postgres ilə aktiv əl işində bir qədər fasilə verdim, yəqin ki, 2010-cu ildən. DBA-nın iş rejiminin nə qədər az dəyişdiyinə və hələ də nə qədər əl əməyindən istifadə edilməli olduğuna təəccübləndim. Və dərhal düşündüm ki, burada bir şey səhvdir, hər şeyi daha çox avtomatlaşdırmalıyam.
Və hər şey uzaqda olduğundan, müştərilərin çoxu buludlarda idi. Və çox şey artıq avtomatlaşdırılıb. Bu haqda daha sonra. Yəni, bütün bunlar belə bir fikirlə nəticələndi ki, bir sıra alətlər, yəni çoxlu sayda verilənlər bazasını idarə etmək üçün demək olar ki, bütün DBA hərəkətlərini avtomatlaşdıracaq bir növ platforma olmalıdır.
Bu hesabata aşağıdakılar daxil edilməyəcək:
- "Gümüş güllələr" və kimi ifadələr - 8 GB və ya 25% paylaşılan_buferlər təyin edin və yaxşı olacaqsınız. Paylaşılan_buferlər haqqında çox şey olmayacaq.
- Sərt "daxili".
Nə olacaq?
- Tətbiq etdiyimiz və inkişaf etdirdiyimiz optimallaşdırma prinsipləri olacaq. Yol boyu ortaya çıxan hər cür ideyalar və bizim çox hissəsi üçün Açıq Mənbədə yaratdığımız müxtəlif alətlər olacaq, yəni biz Open Source-da əsas yaradırıq. Üstəlik, biletlərimiz var, bütün rabitə praktiki olaraq Açıq Mənbədir. İndi nə etdiyimizi, növbəti buraxılışda nələrin olacağını və s. görə bilərsiniz.
- Bu prinsiplərin, bu alətlərin bir sıra şirkətlərdə istifadəsi ilə bağlı müəyyən təcrübə də olacaq: kiçik startaplardan tutmuş böyük şirkətlərə qədər.
Bütün bunlar necə inkişaf edir?
Birincisi, DBA-nın əsas vəzifəsi nümunələrin yaradılmasını, ehtiyat nüsxələrin yerləşdirilməsini və s. təmin etməklə yanaşı, darboğazları tapmaq və performansı optimallaşdırmaqdır.
İndi belə qurulub. Monitorinqlərə baxırıq, nəsə görürük, amma bəzi detallar çatışmır. Biz daha diqqətlə qazmağa başlayırıq, adətən əllərimizlə və bu və ya digər şəkildə bununla nə edəcəyimizi başa düşürük.
Və iki yanaşma var. Pg_stat_statements yavaş sorğuları müəyyən etmək üçün standart həlldir. Və pgBadger istifadə edərək Postgres qeydlərinin təhlili.
Hər bir yanaşmanın ciddi çatışmazlıqları var. Birinci yanaşmada biz bütün parametrləri atdıq. Və əgər biz SELECT * FROM cədvəlini görürüksə, burada sütun "?" və ya Postgres 10-dan bəri “$”. Bunun indeks taraması və ya ardıcıl skan olduğunu bilmirik. Parametrdən çox asılıdır. Orada nadir hallarda rast gəlinən dəyəri əvəz etsəniz, bu, indeks taraması olacaq. Orada cədvəlin 90%-ni tutan dəyəri əvəz etsəniz, ardıcıllıq skanı aydın olacaq, çünki Postgres statistikanı bilir. Və bu, pg_stat_statements-in böyük çatışmazlığıdır, baxmayaraq ki, bəzi işlər gedir.
Log analizinin ən böyük çatışmazlığı odur ki, bir qayda olaraq "log_min_duration_statement = 0" dəyərini ödəyə bilməzsiniz. Və bu barədə də danışacağıq. Müvafiq olaraq, siz bütün mənzərəni görmürsünüz. Və çox sürətli olan bəzi sorğular böyük miqdarda resurs istehlak edə bilər, lakin siz onu görməyəcəksiniz, çünki o, həddən aşağıdır.
DBA-lar tapdıqları problemləri necə həll edirlər?
Məsələn, bir problem tapdıq. Adətən nə edilir? Əgər siz inkişaf etdiricisinizsə, o zaman eyni ölçüdə olmayan bir nümunədə bir şey edəcəksiniz. Əgər siz DBAsınızsa, deməli səhnələşdirməniz var. Və yalnız bir ola bilər. Və altı ay geridə qaldı. Və elə bilirsən ki, istehsala gedəcəksən. Və hətta təcrübəli DBA-lar daha sonra istehsalda, replikada yoxlanılır. Və elə olur ki, onlar müvəqqəti indeks yaradırlar, kömək etdiyinə əmin olurlar, onu buraxırlar və tərtibatçılara verirlər ki, miqrasiya fayllarına yerləşdirsinlər. İndi baş verən belə cəfəngiyatdır. Və bu problemdir.
- Konfiqurasiyaları tənzimləyin.
- İndekslər dəstini optimallaşdırın.
- SQL sorğusunun özünü dəyişdirin (bu, ən çətin üsuldur).
- Tutum əlavə edin (əksər hallarda ən asan yol).
Bu işlərlə bağlı çox şey var. Postgres-də çoxlu tutacaqlar var. Bilmək üçün çox şey var. Postgres-də çoxlu indekslər var, bu konfransın təşkilatçılarına da təşəkkürlər. Və bütün bunları bilmək lazımdır və bu, qeyri-DBA-lara DBA-ların qara sehrlə məşğul olduqlarını hiss etdirir. Yəni bütün bunları normal anlamağa başlamaq üçün 10 il oxumaq lazımdır.
Mən isə bu qara sehrə qarşı mübarizə aparıram. Mən hər şeyi etmək istəyirəm ki, texnologiya olsun və bütün bunlarda intuisiya olmasın.
Real həyat nümunələri
Bunu ən azı iki layihədə, o cümlədən öz layihəmdə müşahidə etmişəm. Başqa bir blog yazısı bizə default_statistict_target üçün 1 dəyərinin yaxşı olduğunu deyir. Yaxşı, istehsalda sınayaq.
Və burada, iki il sonra alətimizdən istifadə edərək, bu gün haqqında danışdığımız verilənlər bazası üzərində aparılan təcrübələrin köməyi ilə nə olub, nə olub, müqayisə edə bilərik.
Və bunun üçün bir təcrübə yaratmalıyıq. Dörd hissədən ibarətdir.
- Birincisi ətraf mühitdir. Bizə bir hardware parçası lazımdır. Mən hansısa şirkətə gəlib müqavilə bağlayanda deyirəm ki, istehsalda olan avadanlıqları mənə versinlər. Sizin hər bir Magistriniz üçün mənə ən azı belə bir aparat lazımdır. Ya bu Amazon və ya Google-da virtual maşın nümunəsidir, ya da mənə tam olaraq eyni aparat parçası lazımdır. Yəni mühiti yenidən yaratmaq istəyirəm. Və ətraf mühit anlayışına Postgresin əsas versiyasını daxil edirik.
- İkinci hissə tədqiqatımızın obyektidir. Bu verilənlər bazasıdır. Bir neçə yolla yaradıla bilər. Mən sizə necə göstərəcəyəm.
- Üçüncü hissə yükdür. Bu, ən çətin anıdır.
- Dördüncü hissə isə nəyi yoxladığımız, yəni nə ilə müqayisə edəcəyimizdir. Tutaq ki, konfiqurasiyada bir və ya bir neçə parametri dəyişə bilərik və ya indeks yarada bilərik və s.
Eksperimentə başlayırıq. Budur pg_stat_statements. Solda baş verənlər var. Sağda - nə oldu.
Solda default_statistics_target = 100, sağda =1. Bunun bizə kömək etdiyini görürük. Ümumilikdə hər şey 000% yaxşılaşıb.
Amma biz aşağı diyirləsək, pgBadger və ya pg_stat_statements-dən sorğu qrupları olacaq. İki variant var. Bəzi sorğuların 88% azaldığını görəcəyik. Və burada mühəndislik yanaşması gəlir. İçərisini daha da qaza bilərik, çünki onun niyə batdığını düşünürük. Statistikaya görə nə baş verdiyini başa düşməlisiniz. Niyə statistikada daha çox vedrə daha pis nəticələrə gətirib çıxarır.
Yoxsa biz qaza bilmirik, amma “CƏDVƏL DEĞİŞTİR... SÜTUNU DEĞİŞTİR” edin və bu sütunun statistikasına 100 vedrə qaytarın. Və sonra başqa bir təcrübə ilə bu yamağın kömək etdiyinə əmin ola bilərik. Hamısı. Bu, bizə böyük mənzərəni görməyə və intuisiyaya deyil, məlumatlara əsaslanaraq qərarlar qəbul etməyə kömək edən mühəndislik yanaşmasıdır.
Digər sahələrdən bir neçə nümunə. Uzun illər sınaqlarda CI testləri var. Və ağlı başında olan heç bir layihə avtomatlaşdırılmış testlər olmadan yaşaya bilməz.
Digər sahələrdə: aviasiyada, avtomobil sənayesində, aerodinamikanı sınaqdan keçirəndə bizim də təcrübələr aparmaq imkanımız olur. Biz rəsmdən nəyisə birbaşa kosmosa buraxmayacağıq və ya dərhal bir avtomobili trasa çıxarmayacağıq. Məsələn, külək tuneli var.
Digər sənaye sahələrinin müşahidələrindən nəticə çıxara bilərik.
Birincisi, bizim xüsusi mühitimiz var. İstehsala yaxındır, amma yaxın deyil. Onun əsas xüsusiyyəti ondan ibarətdir ki, o, ucuz, təkrarlanan və mümkün qədər avtomatlaşdırılmış olmalıdır. Həm də ətraflı təhlil aparmaq üçün xüsusi vasitələr olmalıdır.
Çox güman ki, biz bir təyyarəni işə salıb uçduqda qanad səthinin hər millimetrini öyrənmək imkanımız külək tunelində olduğundan daha az olur. Daha çox diaqnostik alətlərimiz var. Biz havada təyyarəyə mindirə bilməyəcəyimiz daha ağır əşyaları daşıya bilərik. Postgres ilə eyni. Biz, bəzi hallarda, təcrübələr zamanı tam sorğu qeydini aktivləşdirə bilərik. Və biz bunu istehsalda etmək istəmirik. Hətta auto_explain istifadə edərək bunu aktiv etməyi planlaşdıra bilərik.
Və dediyim kimi, yüksək səviyyəli avtomatlaşdırma o deməkdir ki, biz düyməni sıxırıq və təkrar edirik. Bu belə olmalıdır ki, eksperimentlər çox olsun, axın olsun.
Nensi CLI - "verilənlər bazası laboratoriyasının" təməli
Və biz bu işi etdik. Yəni, mən bu fikirləri iyun ayında, demək olar ki, bir il əvvəl danışmışdım. Və bizdə artıq Açıq Mənbədə Nensi CLI adlanan sistem var. Bu verilənlər bazası laboratoriyasının qurulması üçün əsasdır.
- Açıq mənbədə, Gitlab-da. Deyə bilərsiniz, cəhd edə bilərsiniz. Slaydlarda link verdim. Bunun üzərinə klikləyə bilərsiniz və o, orada olacaq hər cəhətdən.
Təbii ki, hələ inkişafda olan çox şey var. Orada çoxlu fikirlər var. Ancaq bu, demək olar ki, hər gün istifadə etdiyimiz bir şeydir. Və bir fikrimiz olduqda - niyə biz 40 sətri siləndə hamısı IO-ya düşür, onda biz bir eksperiment keçirə və nə baş verdiyini anlamaq üçün daha ətraflı baxa və sonra onu tez bir zamanda düzəltməyə çalışa bilərik. Yəni biz təcrübə aparırıq. Məsələn, biz bir şeyi düzəldirik və sonunda nə olacağını görürük. Biz bunu istehsalatda etmirik. İdeyanın mahiyyəti bundan ibarətdir.
Bu harada işləyə bilər? Bu, yerli olaraq işləyə bilər, yəni siz bunu istənilən yerdə edə bilərsiniz, hətta MacBook-da da işlədə bilərsiniz. Bizə doker lazımdır, gedək. Hamısı budur. Siz onu bəzi hallarda bir aparatda və ya virtual maşında istənilən yerdə işlədə bilərsiniz.
Həm də Amazonda EC2 Instance-da, spotlarda uzaqdan işləmək imkanı da var. Və bu çox gözəl fürsətdir. Məsələn, dünən biz i500 instansiyasında ən gəncindən başlayaraq i3-3-xlarge ilə bitən 16-dən çox təcrübə keçirdik. Və 500 təcrübə bizə 64 dollara başa gəldi. Hər biri 15 dəqiqə davam etdi. Yəni orada ləkələrdən istifadə olunduğuna görə çox ucuzdur - 70% endirim, Amazon-un saniyəlik hesabı. Siz çox şey edə bilərsiniz. Siz real araşdırma edə bilərsiniz.
Postgres-in üç əsas versiyası dəstəklənir. Bəzi köhnələri və yeni 12-ci versiyanı bitirmək o qədər də çətin deyil.
Bir obyekti üç şəkildə təyin edə bilərik. Bu:
- Dump/sql faylı.
- Əsas yol PGDATA kataloqunu klonlaşdırmaqdır. Bir qayda olaraq, o, ehtiyat serverdən götürülür. Normal ikili ehtiyat nüsxələriniz varsa, oradan klonlar yarada bilərsiniz. Əgər buludlarınız varsa, Amazon və Google kimi bir bulud ofisi bunu sizin üçün edəcək. Bu, real istehsalın klonlanmasının ən vacib yoludur. Biz belə açırıq.
- Postgres-də bir şeyin necə işlədiyini anlamaq istədiyiniz zaman sonuncu üsul tədqiqat üçün uyğundur. Bu pgbench-dir. Siz pgbench istifadə edərək yarada bilərsiniz. Bu, yalnız bir "db-pgbench" seçimidir. Siz ona hansı miqyasda deyin. Və hər şey deyildiyi kimi buludda yaradılacaq.
Və yükləyin:
- Yükü bir SQL mövzusunda icra edə bilərik. Bu, ən primitiv yoldur.
- Və biz yükü təqlid edə bilərik. Və biz onu ilk növbədə aşağıdakı şəkildə təqlid edə bilərik. Bütün logları toplamaq lazımdır. Və ağrılıdır. Səbəbini sizə göstərəcəyəm. Və pgreplay istifadə edərək biz Nensidə qurulmuş oynayırıq.
- Və ya başqa variant. Müəyyən bir səylə etdiyimiz sözdə sənətkarlıq yükü. Döyüş sistemindəki cari yükümüzü təhlil edərək, ən yüksək sorğu qruplarını çıxarırıq. Və pgbench istifadə edərək, laboratoriyada bu yükü təqlid edə bilərik.
- Ya bir növ SQL yerinə yetirməliyik, yəni hansısa miqrasiyanı yoxlayırıq, orada indeks yaradaq, orada ANALAZE icra etməliyik. Biz isə vakuumdan əvvəl və vakuumdan sonra baş verənlərə baxırıq. Ümumiyyətlə, hər hansı bir SQL.
- Ya konfiqurasiyada bir və ya bir neçə parametri dəyişdiririk. Bizə deyə bilərik ki, məsələn, Amazon-da terabayt verilənlər bazamız üçün 100 dəyəri yoxlayın. Və bir neçə saatdan sonra nəticə əldə edəcəksiniz. Bir qayda olaraq, terabayt verilənlər bazasını yerləşdirmək sizə bir neçə saat çəkəcək. Ancaq inkişafda bir yamaq var, bizdə mümkün bir sıra var, yəni eyni serverdə ardıcıl olaraq eyni pgdata istifadə edə və yoxlaya bilərsiniz. Postgres yenidən başlayacaq və keşlər sıfırlanacaq. Və yükü idarə edə bilərsiniz.
- Kataloq pg snapshotlarından başlayaraq bir çox müxtəlif fayllarla gəlirstat***. Ən maraqlısı isə pg_stat_statements, pg_stat_kcacke. Bunlar sorğuları təhlil edən iki uzantıdır. Və pg_stat_bgwriter yalnız pgwriter statistikasını deyil, həm də yoxlama nöqtəsi və arxa uçların çirkli buferləri necə yerindən çıxardığını ehtiva edir. Və hər şeyi görmək maraqlıdır. Məsələn, biz shared_buffers qurarkən, hər kəsin nə qədər əvəz etdiyini görmək çox maraqlıdır.
- Postgres jurnalları da gəlir. İki qeyd – bir hazırlıq jurnalı və yük oxutma jurnalı.
- Nisbətən yeni bir xüsusiyyət FlameGraphs-dır.
- Ayrıca, yükü oynamaq üçün pgreplay və ya pgbench seçimlərindən istifadə etsəniz, onların çıxışı yerli olacaqdır. Və gecikmə və TPS görəcəksiniz. Bunu necə gördüklərini anlamaq mümkün olacaq.
- Sistem məlumatları.
- Əsas CPU və IO yoxlamaları. Bu, Amazondakı EC2 nümunəsi üçün daha çox, bir mövzuda 100 eyni nümunəni işə salmaq və orada 100 fərqli qaçış həyata keçirmək istədiyiniz zaman 10 təcrübəniz olacaq. Və əmin olmalısınız ki, onsuz da kimsə tərəfindən əzilən qüsurlu bir nümunə ilə qarşılaşmamalısınız. Digərləri bu aparatda aktivdir və sizin çox az resursunuz qalıb. Belə nəticələrdən imtina etmək daha yaxşıdır. Alexey Kopytov-dan sysbench-in köməyi ilə biz gələcək və başqaları ilə müqayisə edilə bilən bir neçə qısa yoxlama aparırıq, yəni CPU-nun necə davrandığını və IO-nun necə davrandığını başa düşəcəksiniz.
Müxtəlif şirkətlərin nümunəsinə əsaslanan texniki çətinliklər hansılardır?
Tutaq ki, loglardan istifadə edərək real yükü təkrarlamaq istəyirik. Open Source pgreplay-da yazılıbsa, əla fikirdir. Biz istifadə edirik. Ancaq bunun yaxşı işləməsi üçün parametrlər və vaxtla tam sorğu qeydini aktivləşdirməlisiniz.
Müddət və vaxt damğası ilə bağlı bəzi çətinliklər var. Bütün bu mətbəxi boşaltacağıq. Əsas sual budur ki, siz bunu ödəyə bilirsiniz, ya yox?
Problem ondadır ki, o, mövcud olmaya bilər. Hər şeydən əvvəl loga hansı axının yazılacağını başa düşməlisiniz. Əgər sizdə pg_stat_statements varsa, saniyədə təxminən neçə bayt yazılacağını anlamaq üçün bu sorğudan (link slaydlarda mövcud olacaq) istifadə edə bilərsiniz.
Biz sorğunun uzunluğuna baxırıq. Parametrlərin olmaması faktına laqeyd yanaşırıq, lakin sorğunun uzunluğunu bilirik və onun saniyədə neçə dəfə icra edildiyini bilirik. Bu yolla təxminən saniyədə neçə baytı təxmin edə bilərik. Biz iki qat daha çox səhv edə bilərik, amma sifarişi bu şəkildə mütləq başa düşəcəyik.
Bu sorğunun saniyədə 802 dəfə yerinə yetirildiyini görə bilərik. Və görürük ki, bayt_san - 300 kB/s artı və ya mənfi yazılacaq. Və, bir qayda olaraq, belə bir axını ödəyə bilərik.
Amma! Fakt budur ki, müxtəlif giriş sistemləri var. Və insanların defolt adətən "syslog" olur.
Əgər syslogunuz varsa, belə bir şəkiliniz ola bilər. Biz pgbench-i götürəcəyik, sorğu qeydini aktivləşdirəcəyik və nə baş verdiyini görəcəyik.
Giriş etmədən - bu soldakı sütundur. 161 TPS əldə etdik. Syslog ilə - bu Amazon-da Ubuntu 000-dədir, biz 16.04 TPS alırıq. Və əgər başqa iki giriş metoduna keçsək, vəziyyət daha yaxşı olar. Yəni aşağı düşəcəyini gözləyirdik, amma eyni dərəcədə yox.
Jurnalın da iştirak etdiyi, logları asan axtarış üçün ikili formata çevirən CentOS 7-də və s., onda bu, kabusdur, TPS-də 44 dəfə düşürük.
Və insanlar bununla yaşayır. Və çox vaxt şirkətlərdə, xüsusən də böyük şirkətlərdə bunu dəyişdirmək çox çətindir. Əgər syslog-dan uzaqlaşa bilirsinizsə, lütfən ondan uzaqlaşın.
- IOPS-i qiymətləndirin və axını yazın.
- Giriş sisteminizi yoxlayın.
- Proqnozlaşdırılan yük həddindən artıq böyükdürsə, nümunə götürməyi düşünün.
Bizdə pg_stat_statements var. Dediyim kimi, orada olmalıdır. Və biz hər bir sorğu qrupunu xüsusi bir şəkildə faylda götürüb təsvir edə bilərik. Və sonra pgbench-də çox rahat bir xüsusiyyətdən istifadə edə bilərik - bu "-f" seçimindən istifadə edərək bir neçə fayl daxil etmək imkanıdır.
Çox "-f" hərfini başa düşür. Və sonunda “@” işarəsi ilə hər bir faylın hansı paylaşıma sahib olması lazım olduğunu deyə bilərsiniz. Yəni 10% hallarda bunu, 20% isə bunu deyə bilərik. Bu isə bizi istehsalda gördüklərimizə yaxınlaşdıracaq.
İstehsalda nə olduğumuzu necə başa düşəcəyik? Hansı paylaşım və necə? Bu bir az kənara çəkilir. Daha bir məhsulumuz var . Həmçinin Açıq Mənbədə əsasdır. İndi biz onu fəal şəkildə inkişaf etdiririk.
O, bir az fərqli səbəblərdən doğulub. Monitorinqin kifayət etmədiyi səbəblərdən. Yəni, gəl, bazaya bax, mövcud problemlərə bax. Və, bir qayda olaraq, sağlamlıq_yoxlanışı edirsiniz. Əgər siz təcrübəli DBAsınızsa, sağlamlıq_yoxlanışı edirsiniz. Biz indekslərin istifadəsinə baxdıq və s. Əgər sizdə OKmeter varsa, əladır. Bu Postgres üçün əla monitorinqdir. OKmeter.io – lütfən onu quraşdırın, orada hər şey çox yaxşı edilib. Ödənişlidir.
Əgər sizdə yoxdursa, deməli, adətən çox da yoxdur. Monitorinqdə adətən CPU, IO və sonra rezervasiyalar var və hamısı budur. Və daha çox ehtiyacımız var. Avtovakuumun necə işlədiyini, yoxlama məntəqəsinin necə işlədiyini görməliyik, io-da yoxlama nöqtəsini bgwriter və arxa hissələrdən ayırmalıyıq və s.
Problem ondadır ki, siz böyük bir şirkətə kömək edəndə onlar nəyisə tez həyata keçirə bilmirlər. Tez OKmeter ala bilmirlər. Ola bilsin ki, altı aydan sonra alsınlar. Bəzi paketləri tez çatdıra bilmirlər.
Və belə bir fikrə gəldik ki, bizə heç bir şey quraşdırmağı tələb etməyən xüsusi alət lazımdır, yəni istehsalda ümumiyyətlə heç bir şey quraşdırmaq lazım deyil. Onu laptopunuza və ya onu işlədəcəyiniz yerdən müşahidə serverinə quraşdırın. Və o, bir çox şeyi təhlil edəcək: əməliyyat sistemi, fayl sistemi və Postgresin özü, birbaşa istehsala göndərilə bilən bəzi yüngül sorğular edir və heç bir şey uğursuz olmayacaq.
Biz bunu Postgres-checkup adlandırdıq. Tibbi dildə desək, bu müntəzəm sağlamlıq müayinəsidir. Əgər avtomobil mövzusundadırsa, deməli texniki xidmət kimidir. Markadan asılı olaraq avtomobilinizə altı aydan bir və ya ildə bir texniki qulluq edirsiniz. Bazanıza texniki qulluq edirsiniz? Yəni mütəmadi olaraq dərin araşdırma aparırsınız? Bunu etmək lazımdır. Əgər ehtiyat nüsxələrini çıxarırsınızsa, yoxlayın, bu daha az vacib deyil.
Və belə bir alətimiz var. Yalnız üç ay əvvəl aktiv şəkildə ortaya çıxmağa başladı. Hələ gəncdir, amma orada çox şey var.
Ən "nüfuzlu" sorğu qruplarının toplanması - Postgres-checkup-da K003 hesabatı
Və bir qrup hesabat var K. İndiyə qədər üç hesabat. Və belə bir hesabat var K003. Ümumi_zamana görə sıralanmış pg_stat_statements-dən yuxarı var.
Sorğu qruplarını total_zamana görə çeşidlədikdə, yuxarıda sistemimizi ən çox yükləyən, yəni daha çox resurs istehlak edən qrupu görürük. Sorğu qruplarını niyə adlandırıram? Çünki biz parametrləri atdıq. Bunlar artıq sorğular deyil, sorğu qruplarıdır, yəni mücərrəddir.
Və yuxarıdan aşağıya optimallaşdırsaq, resurslarımızı yüngülləşdirəcəyik və təkmilləşdirməyə ehtiyac duyduğumuz anı gecikdirəcəyik. Bu pula qənaət etməyin çox yaxşı yoludur.
Bəlkə də bu, istifadəçilərin qayğısına qalmaq üçün çox yaxşı bir yol deyil, çünki bir insanın 15 saniyə gözlədiyi nadir, lakin çox zəhlətökən halları görməyə bilərik. Ümumilikdə, onlar o qədər nadirdir ki, biz onları görmürük, lakin biz resurslarla məşğul oluruq.
Bu cədvəldə nə baş verdi? İki şəkil çəkdik. Postgres_checkup sizə hər bir metrik üçün delta verəcək: ümumi vaxt, zənglər, sıralar, shared_blks_read və s. Budur, delta hesablanıb. pg_stat_statements ilə bağlı böyük problem onun nə vaxt sıfırlandığını xatırlamamasıdır. Əgər pg_stat_database xatırlayırsa, pg_stat_statements yadda saxlamır. Görürsünüz ki, 1 ədəd var, amma biz haradan saydığımızı bilmirik.
Və burada biz bilirik, burada iki anlıq görüntü var. Bu vəziyyətdə deltanın 56 saniyə olduğunu bilirik. Çox qısa bir boşluq. Ümumi_vaxt üzrə çeşidlənib. Və sonra biz fərqlənə bilərik, yəni bütün ölçüləri müddətə bölürük. Hər bir metrikanı müddətə bölsək, saniyədə edilən zənglərin sayına sahib olacağıq.
Sonra, saniyədə cəmi_vaxt mənim sevimli metrikdir. Bu, saniyədə saniyələrlə ölçülür, yəni sistemimizin saniyədə bu sorğular qrupunu yerinə yetirmək üçün neçə saniyə çəkdiyi. Orada saniyədə bir saniyədən çox görürsənsə, bu, birdən çox nüvəni verməli olduğun deməkdir. Bu çox yaxşı göstəricidir. Anlaya bilərsiniz ki, bu dost, məsələn, ən azı üç nüvəyə ehtiyac duyur.
Bu, bizim nou-hauumuzdur, mən heç yerdə belə bir şey görməmişəm. Diqqət yetirin - bu çox sadə bir şeydir - saniyədə saniyə. Bəzən CPU 100% olduqda, saniyədə yarım saat, yəni yalnız bu sorğuları yerinə yetirmək üçün yarım saat sərf edirsiniz.
Sonra saniyədə satırları görürük. Onun saniyədə neçə sıra geri döndüyünü bilirik.
Və sonra maraqlı bir şey də var. Paylaşılan_buferlərin özündən saniyədə neçə paylaşılan_bufer oxuyuruq. Xitlər artıq orada idi və biz sətirləri əməliyyat sisteminin önbelleğinden və ya diskdən götürdük. Birinci seçim sürətlidir, ikincisi isə vəziyyətdən asılı olaraq sürətli ola bilər və ya olmaya bilər.
Fərqləndirmənin ikinci yolu isə bu qrupdakı sorğuların sayını bölməkdir. İkinci sütunda həmişə bir sorğuya bölünmüş bir sorğunuz olacaq. Və sonra maraqlıdır - bu sorğuda neçə millisaniyə var idi. Bu sorğunun orta hesabla necə davrandığını bilirik. Hər sorğu üçün 101 millisaniyə tələb olunurdu. Bu, anlamalı olduğumuz ənənəvi metrikdir.
Hər sorğu orta hesabla neçə sıra qaytardı? Bu qrupun 8 nəfərin geri döndüyünü görürük. Orta hesabla, keşdən nə qədər götürülüb oxundu. Hər şeyin gözəl şəkildə yaddaşda saxlandığını görürük. Birinci qrup üçün möhkəm hitlər.
Və hər bir sətirdə dördüncü alt sətir cəmi neçə faizdir. Zənglərimiz var. Tutaq ki, 1. Və bu qrupun hansı töhfə verdiyini anlaya bilərik. Görürük ki, bu halda birinci qrup 000%-dən az töhfə verir. Yəni o qədər ləng gedir ki, biz bunu ümumi mənzərədə görmürük. İkinci qrup isə zənglərdə 000% təşkil edir. Yəni bütün zənglərin 0,01%-i ikinci qrupdur.
Total_time da maraqlıdır. Biz ümumi iş vaxtımızın 14%-ni birinci qrup sorğulara sərf etdik. İkincisi üçün - 11% və s.
Detallara varmayacağam, amma incəliklər var. Biz yuxarıda xətanı göstəririk, çünki müqayisə etdikdə snapshotlar üzə bilər, yəni bəzi sorğular düşə bilər və artıq ikincidə ola bilməz, bəziləri isə yeniləri görünə bilər. Və orada səhvi hesablayırıq. Əgər 0 görürsənsə, bu yaxşıdır. Heç bir səhv yoxdur. Səhv nisbəti 20%-ə qədərdirsə, yaxşıdır.
Sonra mövzumuza qayıdırıq. İş yükünü düzəltməliyik. Biz yuxarıdan aşağıya doğru götürürük və 80% və ya 90% -ə çatana qədər gedirik. Adətən bu 10-20 qrupdur. Və biz pgbench üçün fayllar düzəldirik. Orada təsadüfi istifadə edirik. Bəzən bu, təəssüf ki, nəticə vermir. Postgres 12-də bu yanaşmadan istifadə etmək üçün daha çox imkanlar olacaq.
Və sonra biz bu yolla total_time 80-90% qazanırıq. “@” işarəsindən sonra nə qoymalıyam? Zənglərə baxırıq, baxırıq ki, nə qədər faiz var və başa düşürük ki, burada bu qədər faiz borcumuz var. Bu faizlərdən biz faylların hər birini necə balanslaşdıracağımızı başa düşə bilərik. Bundan sonra pgbench istifadə edirik və işə gedirik.
Bizdə K001 və K002 də var.
K001 dörd alt sətirdən ibarət böyük bir simdir. Bu, bütün yükümüzün bir xüsusiyyətidir. İkinci sütuna və ikinci alt sıraya baxın. Biz görürük ki, saniyədə təxminən bir yarım saniyə, yəni iki nüvə varsa, o zaman yaxşı olacaq. Təxminən 75% tutum olacaq. Və belə işləyəcək. Əgər 10 nüvəmiz varsa, o zaman ümumiyyətlə sakit olacağıq. Bu yolla biz resursları qiymətləndirə bilərik.
K002 sorğu sinifləri adlandırdığım şeydir, yəni SEÇ, INSERT, YENİLƏNİB, SİL. Və ayrıca YENİLƏMƏ ÜÇÜN SEÇİN, çünki bu kiliddir.
Və buradan belə nəticəyə gələ bilərik ki, SELECT adi oxuculardır - bütün zənglərin 82%-i, lakin eyni zamanda - ümumi vaxtda 74%. Yəni, onlar çox adlanır, lakin daha az resurs istehlak edirlər.
Və biz suala qayıdırıq: "Düzgün paylaşılan_buferləri necə seçə bilərik?" Müşahidə edirəm ki, əksər meyarlar ideyaya əsaslanır - gəlin görək ötürmə qabiliyyəti nə olacaq, yəni ötürmə qabiliyyəti nə olacaq. Adətən TPS və ya QPS ilə ölçülür.
Və biz tuning parametrlərindən istifadə edərək, avtomobildən saniyədə mümkün qədər çox əməliyyatı sıxışdırmağa çalışırıq. Burada seçim üçün saniyədə tam olaraq 311.
Amma heç kim maşınla işə gedib evə tam sürətlə getmir. Bu axmaqdır. Verilənlər bazaları ilə eyni. Biz tam sürətlə sürmək məcburiyyətində deyilik və heç kim də etmir. 100% CPU olan istehsalatda heç kim yaşamır. Baxmayaraq ki, bəlkə kimsə yaşayır, amma bu yaxşı deyil.
İdeya ondan ibarətdir ki, biz adətən 20 faiz tutumla, tercihen 50 faizdən çox olmamaqla hərəkət edirik. Biz hər şeydən əvvəl istifadəçilərimiz üçün cavab müddətini optimallaşdırmağa çalışırıq. Yəni, biz düymələrimizi çevirməliyik ki, şərti olaraq 20% sürətdə minimum gecikmə olsun. Bu, bizim də təcrübələrimizdə istifadə etməyə çalışdığımız bir fikirdir.
Və nəhayət, tövsiyələr:
- Verilənlər bazası laboratoriyası etdiyinizə əmin olun.
- Mümkünsə, bunu tələblə edin ki, bir müddət açılsın - oynayın və atın. Əgər buludlarınız varsa, deməli, çoxlu ayaq üstə durun.
- Maraqlı olun. Bir şey səhv olarsa, təcrübələrlə necə davrandığını yoxlayın. Nensi bazanın necə işlədiyini yoxlamaq üçün özünüzü məşq etmək üçün istifadə edilə bilər.
- Və minimum cavab müddətini hədəfləyin.
- Və Postgres mənbələrindən qorxmayın. Mənbələrlə işləyərkən ingilis dilini bilməlisiniz. Orada çoxlu şərhlər var, orada hər şey izah olunur.
- Və verilənlər bazasının sağlamlığını mütəmadi olaraq yoxlayın, ən azı üç ayda bir dəfə əl ilə və ya Postgres-checkup.
Suallar
Çox sağ olun! Çox maraqlı bir şey.
İki ədəd.
Bəli, iki ədəd. Yalnız mən tam başa düşmədim. Nensi və mən işlədiyimiz zaman yalnız bir parametr və ya bütün qrupu düzəldə bilərikmi?
Bizdə delta konfiqurasiya parametri var. Bir anda ora istədiyiniz qədər dönə bilərsiniz. Amma başa düşmək lazımdır ki, çox şeyi dəyişdirəndə yanlış nəticələr çıxara bilərsən.
Bəli. Niyə soruşdum? Çünki yalnız bir parametriniz olduqda eksperimentlər aparmaq çətindir. Siz onu sıxın, görün necə işləyir. Mən onu çölə atdım. Sonra növbəti işə başlayırsınız.
Eyni zamanda sıxa bilərsiniz, lakin bu, əlbəttə ki, vəziyyətdən asılıdır. Ancaq bir fikri sınamaq daha yaxşıdır. Dünən bir fikrimiz var idi. Çox yaxın vəziyyətimiz var idi. İki konfiqurasiya var idi. Və niyə böyük fərq olduğunu anlaya bilmədik. Və belə bir fikir yarandı ki, ardıcıl olaraq başa düşmək və fərqin nə olduğunu tapmaq üçün dixotomiyadan istifadə etmək lazımdır. Parametrlərin yarısını dərhal eyni edə bilərsiniz, sonra dörddə birini və s. Hər şey çevikdir.
Və daha bir sual var. Layihə gənc və inkişaf etməkdədir. Sənədlər artıq hazırdır, ətraflı təsviri varmı?
Orada parametrlərin təsviri üçün xüsusi bir keçid etdim. Oradadır. Amma hələ çox şey yoxdur. Mən həmfikir insanlar axtarıram. Mən onları ifa edəndə tapıram. Bu, çox gözəldir. Artıq kimsə mənimlə işləyir, kimsə kömək edib, orada nəsə edib. Və bu mövzu ilə maraqlanırsınızsa, çatışmayan şeylər haqqında rəy bildirin.
Laboratoriyanı qurduqdan sonra, bəlkə də rəy olacaq. Görək. Çox sağ ol!
Salam! Hesabat üçün təşəkkür edirik! Amazon dəstəyinin olduğunu gördüm. GSP-ni dəstəkləmək planları varmı?
Yaxşı sual. Biz bunu etməyə başladıq. Və biz hələlik onu dondurduq, çünki pula qənaət etmək istəyirik. Yəni localhost-da run istifadə edərək dəstək var. Özünüz bir nümunə yarada və yerli olaraq işləyə bilərsiniz. Yeri gəlmişkən, biz bunu edirik. Mən bunu Getlab-da, orada GSP-də edirəm. Ancaq biz hələlik belə bir orkestrləşdirmənin mənasını görmürük, çünki Google-un ucuz yerləri yoxdur. var??? hallar, lakin onların məhdudiyyətləri var. Birincisi, həmişə yalnız 70% endirim var və orada qiymətlə oynaya bilməzsiniz. Ləkələrdə, təpiklənmə ehtimalınızı azaltmaq üçün qiyməti 5-10% artırırıq. Yəni ləkələri saxlayırsınız, lakin onlar istənilən vaxt sizdən götürülə bilər. Əgər siz başqalarından bir az yuxarı qiymət versəniz, daha sonra öldürüləcəksiniz. Google tamamilə fərqli xüsusiyyətlərə malikdir. Və başqa bir çox pis məhdudiyyət var - onlar yalnız 24 saat yaşayırlar. Və bəzən biz 5 gün sınaq keçirmək istəyirik. Ancaq bunu ləkələrdə edə bilərsiniz; ləkələr bəzən aylarla davam edir.
Salam! Hesabat üçün təşəkkür edirik! Yoxlanışı qeyd etdiniz. stat_statements səhvlərini necə hesablayırsınız?
Çox yaxşı sual. Mən sizə çox ətraflı göstərə və deyə bilərəm. Bir sözlə, sorğu qrupları dəstinin necə dəyişdiyinə baxırıq: neçəsi düşdü və nə qədər yenisi yarandı. Və sonra biz iki ölçüyə baxırıq: total_time və zənglər, buna görə də iki səhv var. Və biz üzən qrupların töhfəsinə baxırıq. İki alt qrup var: gedənlər və gələnlər. Onların ümumi mənzərəyə töhfəsinin nə olduğunu görək.
Snapshotlar arasında iki və ya üç dəfə ora dönəcəyindən qorxmursunuz?
Yəni yenidən qeydiyyatdan keçiblər, yoxsa nə?
Məsələn, bu sorğu artıq bir dəfə qabaqcadan alındı, sonra gəldi və yenidən qabaqcadan alındı, sonra yenidən gəldi və yenidən qabaqcadan alındı. Və burada bir şey hesabladınız və hamısı haradadır?
Yaxşı sualdır, baxmalıyıq.
Mən oxşar bir şey etdim. Daha sadə idi, təbii ki, bunu tək etdim. Ancaq mən stat_statements-i sıfırlamalı, sıfırlamalı və snapshot zamanı müəyyən bir fraksiya olduğunu, hələ də orada nə qədər stat_statements toplaya biləcəyi tavanına çatmayan bir hissənin olduğunu anlamalı oldum. Və mənim başa düşdüyüm odur ki, çox güman ki, heç nə yerindən oynamayıb.
Bəli, bəli.
Ancaq bunu başqa necə etibarlı şəkildə edəcəyimi başa düşmürəm.
Təəssüf ki, orada sorğu mətnindən və ya pg_stat_statements ilə sorğudan istifadə edib ona diqqət yetirdiyimizi dəqiq xatırlamıram. Queryid-ə diqqət yetirsək, nəzəri olaraq müqayisə olunan şeyləri müqayisə edirik.
Xeyr, o, çəkilişlər arasında bir neçə dəfə zorla çıxarıla və yenidən gələ bilər.
Eyni id ilə?
Bəli.
Bunu öyrənəcəyik. Yaxşı sual. Biz bunu öyrənməliyik. Amma hələlik gördüyümüz ya 0 yazılıb...
Bu, əlbəttə ki, nadir bir haldır, lakin stat_statemetns-in orada yerini dəyişə biləcəyini biləndə şoka düşdüm.
Pg_stat_statements-də çox şey ola bilər. Biz belə bir faktla rastlaşdıq ki, əgər sizdə track_utility = aktivdirsə, o zaman dəstləriniz də izlənilir.
Bəli, əlbəttə.
Əgər təsadüfi olan java hibernate varsa, onda hash cədvəli orada yerləşməyə başlayır. Və çox yüklənmiş proqramı söndürən kimi 50-100 qrupla qarşılaşırsınız. Və orada hər şey az-çox sabitdir. Bununla mübarizə aparmağın bir yolu pg_stat_statements.max-ı artırmaqdır.
Bəli, amma nə qədər olduğunu bilmək lazımdır. Və nədənsə biz ona diqqət yetirməliyik. Mən bunu edirəm. Yəni məndə pg_stat_statements.max var. Və görürəm ki, çəkiliş zamanı mən 70%-ə çatmamışdım. Yaxşı, heç nə itirməmişik. Gəlin sıfırlayaq. Və yenidən qənaət edirik. Növbəti şəkil 70-dən azdırsa, çox güman ki, yenə heç nə itirməmisiniz.
Bəli. Defolt indi 5-dir.Və bu bir çox insan üçün kifayətdir.
Adətən bəli.
Video:
PS Öz adımdan əlavə edəcəyəm ki, əgər Postgres məxfi məlumatları ehtiva edirsə və onlar test mühitinə daxil edilə bilmirsə, onda siz istifadə edə bilərsiniz. . Sxem təxminən aşağıdakı kimidir:
Mənbə: www.habr.com