Andrey Salnikovun 2016-cı ilin əvvəlinə dair hesabatının transkriptini oxumağı təklif edirəm "Postgresql-də şişməyə səbəb olan tətbiqlərdə tipik səhvlər"
Bu hesabatda proqram kodunun dizaynı və yazılması mərhələsində tətbiqlərdə baş verən əsas səhvləri təhlil edəcəyəm. Mən yalnız Postgresql-də şişməyə səbəb olan səhvləri götürəcəyəm. Bir qayda olaraq, bu, bütövlükdə sisteminizin performansının sonunun başlanğıcıdır, baxmayaraq ki, əvvəlcə bunun üçün heç bir şərt görülməmişdir.
Hər kəsi salamlamağa şadam! Bu hesabat həmkarımın əvvəlki hesabatı qədər texniki deyil. Bu söhbət back-end sistem tərtibatçıları üçün nəzərdə tutulub, çünki bizim kifayət qədər çoxlu müştərimiz var. Və hamısı eyni səhvləri edir. Onlar haqqında sizə məlumat verəcəyəm. Bu səhvlərin nəyə ölümcül və pis gətirdiyini izah edəcəyəm.
Niyə səhvlər edilir? Onlar iki səbəbə görə həyata keçirilir: təsadüfi, bəlkə də baza ilə tətbiq arasında, eləcə də bazanın özündə baş verən bəzi mexanizmlərin məlumatsızlığından işləyəcək.
Mən sizə işlərin necə pisləşdiyinə dair dəhşətli şəkillərlə üç misal verəcəyəm. Orada baş verən mexanizmi qısaca təsvir edəcəyəm. Və onlarla necə davranmalı, nə vaxt baş verdi və səhvlərin qarşısını almaq üçün hansı profilaktik üsullardan istifadə edilməlidir. Mən sizə köməkçi vasitələr haqqında məlumat verəcəyəm və faydalı bağlantılar verəcəyəm.
Mən iki cədvəlin olduğu bir test verilənlər bazasından istifadə etdim. Bir lövhədə müştəri hesabları, digərində isə bu hesablar üzrə əməliyyatlar var. Və müəyyən dövriliklə biz bu hesablardakı qalıqları yeniləyirik.
Plitənin ilkin məlumatları: olduqca kiçik, 2 MB. Verilənlər bazası və xüsusilə boşqab üçün cavab müddəti də çox yaxşıdır. Və kifayət qədər yaxşı bir yük - boşqabda saniyədə 2 əməliyyat.
Və bu hesabat vasitəsilə sizə qrafiklər göstərəcəyəm ki, nə baş verdiyi aydın olsun. Həmişə qrafikləri olan 2 slayd olacaq. Birinci slayd serverdə ümumiyyətlə baş verənlərdir.
Və bu vəziyyətdə, həqiqətən kiçik bir boşqabımız olduğunu görürük. İndeks kiçikdir - 2 MB. Bu, soldakı ilk diaqramdır.
Serverdə orta cavab müddəti də sabitdir, kiçikdir. Bu yuxarı sağdakı qrafikdir.
Aşağı sol qrafik ən uzun əməliyyatlardır. Əməliyyatların sürətlə tamamlandığını görə bilərik. Avtovakuum isə hələ burada işləmir, çünki - bu, başlanğıc sınaq idi. Sonra işləyəcək və bizim üçün faydalı olacaq.
İkinci slayd həmişə sınaq lövhəsinə həsr olunacaq. Bu vəziyyətdə biz müştərinin hesab qalıqlarını daim yeniləyirik. Və biz görürük ki, yeniləmə əməliyyatı üçün orta cavab müddəti kifayət qədər yaxşıdır, bir millisaniyədən azdır. Görürük ki, prosessor resursları (bu yuxarı sağdakı qrafikdir) eyni zamanda bərabər və kifayət qədər az istehlak olunur.
Aşağı sağ qrafik onu yeniləməzdən əvvəl istədiyimiz xəttin axtarışında nə qədər əməliyyat və disk yaddaşından keçdiyimizi göstərir. Və lövhədə əməliyyatların sayı əvvəldə dediyim kimi saniyədə 2-dir.
İndi isə bizim faciəmiz var. Nədənsə çoxdan unudulmuş bir əməliyyat baş verir. Səbəblər ümumiyyətlə banaldır:
- Ən çox yayılmış olanlardan biri, tətbiq kodunda xarici xidmətə daxil olmağa başlamağımızdır. Və bu xidmət bizə cavab vermir. Yəni biz tranzaksiya açdıq, verilənlər bazasında dəyişiklik etdik və proqramdan poçt oxumağa və ya infrastrukturumuz daxilində başqa xidmətə keçdik və nədənsə bizə cavab vermir. Sessiyamız isə elə vəziyyətdə qaldı - nə vaxt həll olunacağı məlum deyil.
- İkinci vəziyyət kodumuzda nədənsə istisnanın baş verməsidir. Və biz istisna olaraq əməliyyatın bağlanmasını emal etmədik. Və açıq əməliyyatla asma sessiyamız var.
- Və sonuncu da olduqca yaygındır. Bu keyfiyyətsiz koddur. Bəzi çərçivələr əməliyyat açır. O, asılır və siz proqramda onun asılı olduğunu bilməyə bilərsiniz.
Belə şeylər hara aparır?
Cədvəllərimiz və indekslərimiz kəskin şəkildə şişməyə başlayır. Bu tamamilə eyni şişkinlik effektidir. Verilənlər bazası üçün bu, verilənlər bazasının cavab müddətində çox kəskin artım olacağımız, verilənlər bazası serverindəki yükün artacağı ilə ifadə olunacaq. Və nəticədə tətbiqimiz zərər görəcək. Çünki kodunuzda verilənlər bazasına sorğuya 10 millisaniyə, məntiqinizə 10 millisaniyə sərf etmisinizsə, funksiyanız 20 millisaniyə işləmişdir. İndi vəziyyətin çox acınacaqlı olacaq.
Və gəlin görək nə baş verir. Aşağı sol qrafik göstərir ki, uzun bir əməliyyatımız var. Və yuxarı sol qrafa baxsaq görərik ki, cədvəlin ölçüsü iki meqabaytdan 300 meqabayta yüksəldi. Eyni zamanda, cədvəldəki məlumatların miqdarı dəyişməyib, yəni kifayət qədər böyük miqdarda zibil var.
Orta server cavab müddəti baxımından ümumi vəziyyət də bir neçə miqyasda dəyişdi. Yəni, serverdəki bütün sorğular tamamilə sönməyə başladı. Və eyni zamanda, avtovakuum qarşısında bir şey etməyə çalışan və resursları istehlak edən daxili Postgres prosesləri işə salındı.
Bizim boşqabımıza nə olur? Eyni. Planşetdə orta cavab müddəti bir neçə dəfə artdı. Xüsusilə istehlak olunan resurslara gəldikdə, prosessorun yükünün çox artdığını görürük. Bu yuxarı sağdakı qrafikdir. Və artdı, çünki prosessor sizə lazım olanı axtarmaq üçün bir dəstə yararsız xəttdən keçməli olur. Bu sağ alt qrafikdir. Və nəticədə saniyədə edilən zənglərin sayı çox azalmağa başladı, çünki verilənlər bazasında eyni sayda sorğuları emal etməyə vaxt yoxdur.
Biz həyata qayıtmalıyıq. İnternetə dırmaşırıq və uzun əməliyyatların problemə səbəb olduğunu öyrənirik. Bu əməliyyatı tapıb öldürürük. Və bizim üçün hər şey yaxşı gedir. Hər şey lazım olduğu kimi işləyir.
Sakitləşdik, amma bir müddət sonra tətbiqin fövqəladə haldan əvvəlki kimi işləmədiyini görməyə başlayırıq. Sorğular eyni şəkildə daha yavaş və daha yavaş işlənir. Xüsusilə mənim nümunəmdə bir yarım-iki dəfə yavaş. Serverdəki yük də qəzadan əvvəl olduğundan daha yüksəkdir.
Və sual: "Bu anda baza ilə nə baş verir?". Və əsasla aşağıdakı vəziyyət var. Əməliyyat qrafikində onun dayandığını və həqiqətən uzunmüddətli əməliyyatların olmadığını görə bilərsiniz. Lakin qəza zamanı lövhənin ölçüləri ölümcül dərəcədə böyüdü. Və o vaxtdan bəri azalmayıb. Bazada orta vaxt sabitləşdi. Və cavablar bizim üçün məqbul bir sürətlə adekvat gedir. Autovacuum daha aktivləşdi və planşetlə bir şey etməyə başladı, çünki daha çox məlumat kürəkləmək lazımdır.
Xüsusilə, balansları dəyişdirdiyimiz test cədvəlində: sorğuya cavab müddəti normala qayıtmış kimi görünür. Amma əslində bir yarım dəfə çoxdur.
Və prosessorun yüklənməsinə görə, prosessordakı yükün qəzadan əvvəl istənilən dəyərə qayıtmadığını görürük. Və səbəblər sağ alt qrafadadır. Müəyyən miqdarda yaddaş axtarışının olduğunu görmək olar. Yəni, istədiyiniz xətti axtarmaq üçün lazımsız verilənlər arasında çeşidlənərkən verilənlər bazası serverinin resurslarını sərf edirik. Saniyədə əməliyyatların sayı sabitləşib.
Ümumiyyətlə, yaxşıdır, amma vəziyyət əvvəlkindən də pisdir. Bu verilənlər bazası ilə işləyən tətbiqimizin nəticəsi olaraq verilənlər bazasının açıq şəkildə deqradasiyası.
Orada nə baş verdiyini başa düşmək üçün, əgər əvvəlki hesabatda olmasaydınız, indi bir az nəzəriyyə. Daxili proses haqqında nəzəriyyə. Niyə avtovakuum və nə edir?
Anlamaq üçün hərfi mənada. Nə vaxtsa masamız var. Cədvəldə sıralarımız var. Bu xətlər aktiv, canlı ola bilər, indi ehtiyacımız var. Şəkildə yaşıl rənglə qeyd olunublar. Və artıq işlənmiş, yenilənmiş, yeni girişlər görünən ölü xətlər var. Və onlar verilənlər bazası üçün artıq maraqlı olmadıqlarını qeyd edirlər. Ancaq Postqresin xüsusiyyətlərinə görə masada yatırlar.
Niyə avtovakuuma ehtiyacınız var? Autovacuum nə vaxtsa gəlir, verilənlər bazasına zəng edir və ondan soruşur: "Zəhmət olmasa, mənə verilənlər bazasında hazırda açıq olan ən köhnə əməliyyatın id-sini verin." Verilənlər bazası bu id-i qaytarır. Və avtovakuum, ona güvənərək, cədvəldəki sətirlərdən keçir. Və əgər o görsə ki, bəzi sətirlər daha köhnə əməliyyatlar tərəfindən dəyişdirilib, o zaman onları orada yeni məlumatlar yazaraq gələcəkdə təkrar istifadə edə biləcəyimiz sətirlər kimi qeyd etmək hüququ var. Bu fon prosesidir.
Bu zaman biz verilənlər bazası ilə işləməyə davam edirik, cədvəldə bəzi dəyişikliklər etməyə davam edirik. Yenidən istifadə edə biləcəyimiz bu sətirlərə yeni məlumatlar yazırıq. Və beləliklə bir dövrə əldə edirik, yəni orada hər zaman bəzi ölü köhnə xətlər görünür, onların yerinə bizə lazım olan yeni sətirləri yazırıq. Və bu PostgreSQL-in işləməsi üçün normal vəziyyətdir.
Qəza zamanı nə baş verdi? Bu proses necə baş verdi?
Bəzi vəziyyətdə boşqabımız var idi, bəziləri canlı, bəziləri ölü xətlər. Avtovakuum gəldi. Bazadan soruşdu ki, bizim ən qədim əməliyyatımız nədir, onun id nədir. Mən bu identifikatoru aldım, o, bir neçə saat, bəlkə də on dəqiqə köhnə ola bilər. Bu, verilənlər bazasında yükün nə qədər ağır olduğundan asılıdır. Və yenidən istifadə edildiyi kimi qeyd edə biləcəyi xətləri axtarmağa getdi. Və cədvəlimizdə belə sətirlərə rast gəlmədim.
Amma bu zaman biz masa ilə işləməyə davam edirik. Biz orada bir şey edirik, onu yeniləyirik, məlumatları dəyişdiririk. Bu zaman verilənlər bazası nə etməlidir? Onun mövcud cədvəlin sonuna yeni sətirlər əlavə etməkdən başqa çarəsi yoxdur. Beləliklə, bizdə masanın ölçüsü şişirdilməyə başlayır.
İşləmək üçün həqiqətən yaşıl xətlərə ehtiyacımız var. Ancaq belə bir problem zamanı yaşıl xətlərin faizi cədvəlin bütün həcmində son dərəcə aşağı olduğu ortaya çıxır.
Sorğunu yerinə yetirdikdə isə verilənlər bazası düzgün xətti tapmaq üçün qırmızı və yaşıl bütün sətirlərdən keçməlidir. Və cədvəli yararsız məlumatlarla şişirtməyin effekti "bloat" adlanır, bu da disk sahəsimizi yeyir. Yadınızdadır, 2 MB idi, indi 300 MB oldu? İndi meqabaytı gigabayta dəyişin və siz bütün disk resurslarınızı olduqca tez itirəcəksiniz.
Bizim üçün hansı fəsadları var?
- Mənim nümunəmdə cədvəl və indeks 150 dəfə artıb. Müştərilərimizdən bəziləri disk sahəsi sadəcə tükənməyə başlayanda daha ölümcül hallarla üzləşib.
- Cədvəllər heç vaxt öz-özünə kiçilməyəcək. Yalnız ölü xətlər varsa, bəzi hallarda avtovakuum masanın quyruğunu kəsə bilər. Ancaq daimi bir fırlanma olduğundan, bir yaşıl xətt sonunda asa bilər və yenilənməyə bilər və qalanların hamısı boşqabın əvvəlində bir yerdə qeyd olunacaq. Ancaq bu, o qədər çətin bir hadisədir ki, masanızın özü ölçüsündə azalacaq, buna görə də ümid etməməlisiniz.
- Verilənlər bazası lazımsız xətlərin bütün yığınını sıralamalıdır. Və biz disk resurslarını, prosessor resurslarını və elektrik enerjisini israf edirik.
- Və bu, birbaşa tətbiqimizə təsir edir, çünki əgər başlanğıcda bir sorğuya 10 millisaniyə, kodumuza 10 millisaniyə sərf etmişiksə, qəza zamanı biz sorğuya bir saniyə, koda isə 10 millisaniyə sərf etməyə başladıq, yəni. böyüklük tətbiqi performansı azaldı. Qəza həll edildikdən sonra biz hər sorğuya 20 millisaniyəyə, kod başına 10 millisaniyə sərf etməyə başladıq. Bu o deməkdir ki, biz hələ performans baxımından bir dəfə yarım batmışıq. Və bütün bunlar dayanan bir əməliyyatın nəticəsidir və bəlkə də bizim günahımızdır.
- Və sual: "Hər şeyi necə geri ala bilərəm?" Beləliklə, bizdə hər şey qaydasındadır və istəklər qəzadan əvvəlki kimi sürətlə getsin.
Bunun üçün həyata keçirilən müəyyən bir iş dövrü var.
Əvvəlcə şişmiş problemli masaları tapmalıyıq. Biz başa düşürük ki, bəzi cədvəllər daha aktiv, bəziləri isə daha az aktiv qeyd edir. Və bunun üçün uzantıdan istifadə edirik . Bu uzantıyı quraşdıraraq, kifayət qədər şişmiş cədvəlləri tapmağınıza kömək etmək üçün sorğular yaza bilərsiniz.
Bu cədvəlləri tapdıqdan sonra onları sıxışdırmaq lazımdır. Bunun üçün artıq alətlər var. Şirkətimizdə üç alətdən istifadə edirik. Birincisi, quraşdırılmış VACUUM FULL-dur. Qəddar, sərt və amansızdır, lakin bəzən çox faydalıdır. и cədvəlləri sıxışdırmaq üçün üçüncü tərəf proqramlarıdır. Və verilənlər bazası ilə bağlı daha diqqətli olurlar.
Onlar sizin üçün daha əlverişli olandan asılı olaraq istifadə olunur. Amma bu haqda sonda danışacağam. Əsas odur ki, üç alət var. Seçmək üçün çox şey var.
Hər şeyi düzəltdikdən sonra, hər şeyin yaxşı olduğuna əmin olaraq, gələcəkdə bu vəziyyətin qarşısını almaq üçün necə bilməliyik:
- Bunun qarşısını almaq kifayət qədər asandır. Master serverdə seansların müddətinə nəzarət etməlisiniz. Əməliyyat vəziyyətində boş vəziyyətdə olan xüsusilə təhlükəli seanslar. Bunlar sadəcə əməliyyat açan, nəsə edib gedənlər və ya sadəcə asıb kodda itənlərdir.
- Və sizin üçün, tərtibatçılar olaraq, bu vəziyyətlər yarandıqda kodu sınamaq vacibdir. Bunu etmək çətin deyil. Bu faydalı bir yoxlama olacaq. Uzun əməliyyatlarla bağlı bir çox "uşaq" problemlərindən qaçacaqsınız.
Bu qrafiklərdə mən bu halda cədvəlin üzərində VACUUM FULL-u keçdikdən sonra cədvəlin və verilənlər bazasının davranışının necə dəyişdiyini göstərmək istədim. Bu mənim istehsalım deyil.
Cədvəlin ölçüsü dərhal bir neçə meqabaytlıq normal iş vəziyyətinə qayıtdı. Bu, server üzrə orta cavab müddətinə çox təsir etmədi.
Ancaq xüsusi olaraq hesab balanslarını yenilədiyimiz test cədvəlimizdə görürük ki, planşetdəki məlumatların yenilənməsi sorğusuna orta cavab müddəti qəzadan əvvəlki səviyyəyə endirilib. Bu sorğunu yerinə yetirmək üçün prosessorun istehlak etdiyi resurslar da qəzadan əvvəlki səviyyələrə düşdü. Və aşağı sağ qrafik göstərir ki, indi masa sıxılmadan əvvəl olan ölü xətlərin yığınından keçmədən, ehtiyac duyduğumuz xətti dərhal tapırıq. Və orta sorğu müddəti təxminən eyni səviyyədə qaldı. Ancaq burada, daha doğrusu, aparatımın səhvi var.
İlk hekayənin bitdiyi yer budur. O, ən çox yayılmışdır. Və bu, müştərinin təcrübəsindən, nə qədər ixtisaslı proqramçıların olmasından asılı olmayaraq hər kəsin başına gəlir. Gec-tez bu baş verir.
Yükü payladığımız və server resurslarını optimallaşdırdığımız ikinci hekayə
- Biz böyümüşük və ciddi oğlanlara çevrilmişik. Və başa düşürük ki, bizim bir replikamız var və yükü tarazlaşdırmaq bizim üçün yaxşı olardı: Mastera yazın və replikadan oxuyun. Və adətən bu vəziyyət bir növ hesabat və ya ETL hazırlamaq istədikdə yaranır. Biznes isə bundan çox məmnundur. O, həqiqətən bir dəstə mürəkkəb analitika ilə müxtəlif hesabatlar istəyir.
- Hesabatlar bir neçə saat davam edir, çünki mürəkkəb analitikanı millisaniyələrlə hesablamaq mümkün deyil. Biz cəsur oğlanlar kimi kod yazırıq. Biz Master-da qeyd etdiyimiz insert proqramında edirik, replika üzrə hesabatlar həyata keçiririk.
- Yükü paylayırıq.
- Hər şey mükəmməl işləyir. Biz əlayıq.
Və bu vəziyyət necə görünür? Konkret olaraq, bu qrafiklərə əməliyyatın müddəti üçün replikadan əməliyyatların müddətini də əlavə etdim. Bütün digər qrafiklər yalnız Master Serverə aiddir.
Bu zaman hesabat lövhəm böyüdü. Onlardan daha çoxu var. Orta server cavab müddətinin sabit olduğunu görə bilərik. Replikada 2 saat davam edən uzun müddət davam edən bir əməliyyatımız olduğunu görə bilərik. Ölü xətləri emal edən avtovakuumun sakit işini görürük. Və hamımız yaxşıyıq.
Konkret olaraq, test planşetinə əsasən, biz oradakı hesablar üzrə qalıqları yeniləməyə davam edirik. Həm də istək üzrə sabit cavab vaxtımız, sabit resurs istehlakımız var. Bizdə hər şey yaxşıdır.
Bu hesabatlar təkrarlama ilə qarşıdurma ilə bağlı bizə cavab verməyə başlayana qədər hər şey qaydasındadır. Və onlar müəyyən fasilələrlə geri çəkilir.
İnternetə girib bunun niyə baş verdiyini oxumağa başlayırıq. Və bir həll tapırıq.
Birinci həll replikasiya gecikməsini artırmaqdır. Hesabatımızın 3 saat davam etdiyini bilirik. Replikasiya gecikməsini 3 saata təyin edin. Biz hər şeyə başlayırıq, lakin hələ də hesabatların bəzən geri çəkildiyi ilə bağlı problemlərimiz davam edir.
Biz hər şeyin mükəmməl olmasını istəyirik. Gəlin daha da irəli gedək. İnternetdə sərin bir parametr tapırıq - hot_standby_feedback. Biz onu yandırırıq. Hot_standby_feedback bizə Master üzərində işləyən avtovakuumu saxlamağa imkan verir. Beləliklə, biz təkrarlama konfliktlərindən tamamilə xilas oluruq. Biz hamımız hesabatlarla yaxşı işləyirik.
Və bu anda Master server ilə nə baş verir? Və Master server ilə tam bir fəlakətimiz var. İndi bu parametrlərin hər ikisinin aktiv olduğu diaqramları görürük. Və görürük ki, replikadakı sessiya birtəhər Master serverdəki vəziyyətə təsir etməyə başladı. O, təsir edir, çünki o, ölü xətləri təmizləyən avtovakuumu dayandırıb. Masamızın ölçüsü yenidən artdı. Bütün verilənlər bazası üzrə sorğunun orta icra müddəti də sürətlə artdı. Avtovakuumlar bir az dartıldı.
Konkret olaraq, boşqabımızda onun üzərindəki məlumat yeniləməsinin də göyə atıldığını görürük. Prosessor resurslarının istehlakı da eyni dərəcədə artmışdır. Biz yenidən çoxlu sayda ölü yararsız xətləri təkrarlayırıq. Və bu planşetdə cavab müddəti, əməliyyatların sayı azalıb.
Əvvəllər nə haqqında danışdığımı bilməsək, necə görünəcək?
- Problemləri axtarmağa başlayırıq. Birinci hissədə problemlərlə qarşılaşmışıqsa, bunun uzun bir əməliyyatın səbəbi ola biləcəyini bilirik və Ustanın üzərinə qalxırıq. Problem Ustadadır. Ona kolbasa. O, isinir, onun yük ortalaması yüzdən aşağıdır.
- Orada sorğular yavaşlayır, lakin biz orada heç bir uzunmüddətli əməliyyat görmürük. Və biz nə baş verdiyini anlamırıq. Hara baxacağımızı bilmirik.
- Server aparatının yoxlanılması. Ola bilsin ki, reydimiz iflasa uğrayıb. Ola bilsin ki, yaddaş panelini yandırdıq. Bəli, hər şey ola bilər. Amma yox, serverlər yenidir, hər şey qaydasındadır.
- Hamı çalışır: idarəçilər, tərtibatçılar və direktor. Heç nə kömək etmir.
- Və bir anda hər şey birdən özünü düzəltməyə başlayır.
Replikada, o zaman sorğu işləndi və getdi. Hesabat almışıq. Biznes hələ də xoşbəxtdir. Gördüyünüz kimi, süfrəmiz yenidən böyüyüb və azalmaq fikrində deyil. Seanslarla qrafikdə bu uzun əməliyyatın bir hissəsini replikadan buraxdım ki, vəziyyət sabitləşənə qədər nə qədər vaxt lazım olduğunu qiymətləndirə biləsiniz.
Sessiya getdi. Və yalnız bir müddət sonra server az-çox qaydasında gəlir. Və Master serverdə sorğular üçün orta cavab müddəti normala qayıdır. Çünki, nəhayət, avtovakuum bu ölü xətləri təmizləmək, qeyd etmək imkanı əldə etdi. Və öz işini görməyə başladı. Və o bunu nə qədər tez edirsə, o qədər tez qaydaya düşəcəyik.
Hesab qalıqlarını yenilədiyimiz test masasında tam olaraq eyni mənzərəni görürük. Orta hesabın yeniləmə müddəti də tədricən normallaşır. Prosessorun istehlak etdiyi resurslar da azalır. Və saniyədə əməliyyatların sayı normala qayıdır. Amma yenə normal vəziyyətə qayıtdıq, qəzadan əvvəlki kimi deyil.
Hər halda, birinci vəziyyətdə olduğu kimi, bir yarımdan iki dəfə, bəzən daha çox performansda azalma alırıq.
Deyəsən hər şeyi düzgün etdik. Yükü paylayın. Avadanlıqlar boş vəziyyətdə deyil. Ağlına görə, istəkləri pozdular, amma yenə də hər şey pis oldu.
- hot_standby_feedback funksiyasını aktiv etmirsiniz? Bəli, xüsusilə güclü səbəblər olmadan onu açmaq tövsiyə edilmir. Çünki bu bükülmə birbaşa Master Serverə təsir edir və oradakı avtovakuumun işini dayandırır. Onu bəzi replikada yandıraraq və bu barədə unutmaqla siz Master-ı öldürə və proqramla bağlı böyük problemlər yarada bilərsiniz.
- Maks_standby_streaming_gecikmesi artırılsın? Bəli, hesabatlar üçün belədir. Əgər üç saatlıq hesabatınız varsa və replikasiya konfliktləri səbəbindən onun qəzaya uğramasını istəmirsinizsə, onda sadəcə gecikməni artırın. Uzun hesabat heç vaxt verilənlər bazasına hazırda daxil olmuş məlumatları tələb etmir. Əgər onu üç saat saxlayırsınızsa, onda siz onu bəzi köhnə məlumat dövrü üçün işlədirsiniz. Və siz, o üç saat gecikmə, altı saat gecikmə - heç bir rol oynamayacaqsınız, ancaq ardıcıl olaraq hesabatlar alacaqsınız və onların düşməsi ilə bağlı problemləri bilməyəcəksiniz.
- Təbii ki, replikalarda uzun sessiyalara nəzarət etməlisiniz, xüsusən də replikada hot_standby_feedback-i aktivləşdirmək qərarına gəlsəniz. Çünki hər şey ola bilər. Bu qeydi tərtibatçıya verdik ki, sorğuları sınasın. Çılğın bir sorğu yazdı. Başladı və çay içməyə getdi və biz qurulmuş Ustadı aldıq. Yaxud orada səhv tətbiqi işə saldıq. Vəziyyətlər müxtəlifdir. Replikalarda seanslara Masterdə olduğu kimi diqqətlə nəzarət edilməlidir.
- Əgər replikalarda sürətli və uzun sorğularınız varsa, bu halda yükü paylamaq üçün onları bölmək daha yaxşıdır. Bu axın_gecikdirmə keçididir. Kiçik replikasiya gecikməsi ilə bir replikaya sahib olmaq üçün sürətli. Uzun müddət davam edən hesabat sorğuları üçün 6 saat, bir gün geridə qala bilən replikaya sahib olun. Bu tamamilə normal bir vəziyyətdir.
Nəticələri eyni şəkildə aradan qaldırırıq:
- Şişmiş masalar tapırıq.
- Biz isə özümüzə uyğun olan ən rahat alətlə sıxışdırırıq.
İkinci hekayə burada bitir. Üçüncü hekayəyə keçək.
Miqrasiya etdiyimiz bizim üçün də olduqca yaygındır.
- İstənilən proqram məhsulu böyüyür. Tələblər dəyişir. İstənilən halda biz inkişaf etmək istəyirik. Və belə olur ki, cədvəldəki məlumatları yeniləməliyik, yəni inkişafımızın bir hissəsi kimi tətbiq etdiyimiz yeni funksionallığa keçidimiz baxımından yeniləməni işə salmalıyıq.
- Köhnə məlumat formatı uyğun gəlmir. Tutaq ki, indi ikinci cədvələ müraciət edirik, burada mənim bu hesablar üzrə əməliyyatlarım var. Və tutaq ki, onlar rublla idilər və biz dəqiqliyi artırıb, qəpiklə etmək qərarına gəldik. Və bunun üçün bir yeniləmə etməliyik: əməliyyatın miqdarı ilə sahəni yüz ilə çoxaltın.
- Müasir dünyada biz avtomatlaşdırılmış verilənlər bazası versiyaları alətlərindən istifadə edirik. Deyək . Biz miqrasiyamızı orada qeydə alırıq. Test bazamızda sınaqdan keçiririk. Hər şey yaxşıdır. Yeniləmə işləyir. Bloklar bir müddət işləyir, lakin biz yenilənmiş məlumatları alırıq. Və bununla bağlı yeni funksionallıq işə sala bilərik. Hamısı yoxlanılıb və sınaqdan keçirilib. Hamısı təsdiqləndi.
- Planlı işlər həyata keçirdi, köç həyata keçirdi.
Qarşınızda təqdim olunan yeniləmə ilə miqrasiya budur. Hesablarda əməliyyatlarım olduğu üçün boşqab 15 GB idi. Və biz hər sətri yenilədiyimiz üçün yeniləmə ilə lövhəni ikiqat artırdıq, çünki biz hər sətirin üzərinə yazmışıq.
Miqrasiya zamanı biz bu etiketlə heç nə edə bilmədik, çünki onun üçün bütün sorğular növbəyə qoyulmuşdu və bu yeniləmənin bitməsini gözləyirdik. Ancaq burada şaquli oxda olan rəqəmlərə diqqətinizi çəkmək istəyirəm. Yəni, 5 millisaniyəlik bölgədə miqrasiyadan əvvəl orta sorğu vaxtımız var və prosessorda bir yük var, disk yaddaşını oxumaq üçün blok əməliyyatlarının sayı 7,5-dən azdır.
Biz köçdük və yenidən problemlərlə üzləşdik.
Miqrasiya uğurlu oldu, lakin:
- Köhnə funksionallıq daha uzun sürməyə başladı.
- Masanın ölçüsü yenidən böyüdü.
- Serverdəki yük yenidən əvvəlkindən çox oldu.
- Və əlbəttə ki, biz hələ də yaxşı işləyən funksionallıqla məşğul oluruq, onu bir az təkmilləşdirdik.
Və bu yenə də həyatımızı korlayan şişkinlikdir.
Burada nümayiş etdirirəm ki, cədvəl, əvvəlki iki halda olduğu kimi, əvvəlki ölçülərə qayıtmaq niyyətində deyil. Serverdəki orta yük adekvat görünür.
Hesablarla cədvələ müraciət etsək, bu cədvəl üçün orta sorğu vaxtının iki dəfə artdığını görərik. Prosessorun yükü və yaddaşda çeşidlənəcək sətirlərin sayı 7,5-dən yuxarı qalxdı, lakin daha az idi. Prosessorlarda 2 dəfə, blok əməliyyatlarında 1,5 dəfə sıçradıq, yəni server performansında deqradasiya oldu. Və nəticədə - tətbiqimizin performansının pisləşməsi. Eyni zamanda, zənglərin sayı təxminən eyni səviyyədə qalıb.
Və burada əsas şey bu cür miqrasiyaların necə düzgün aparılacağını başa düşməkdir. Və bunları etmək lazımdır. Biz bu köçləri olduqca müntəzəm edirik.
- Belə böyük köçlər avtomatik həyata keçirilmir. Onlara həmişə nəzarət edilməlidir.
- Savadlı adamın nəzarətinə ehtiyacı var. Komandada bir DBA varsa, DBA bunu etsin. Onun işidir. Yoxdursa, o zaman ən təcrübəli, verilənlər bazası ilə işləməyi bilən adam etsin.
- Yeni verilənlər bazası sxemi, hətta bir sütunu yeniləsək də, biz həmişə mərhələlərlə, yəni tətbiqin yeni versiyası çıxmazdan əvvəl əvvəlcədən hazırlayırıq:
- Sadəcə yenilənmiş məlumatları yazacağımız yeni sahələr əlavə olunur.
- Biz məlumatları köhnə sahədən yeni sahəyə kiçik hissələrlə köçürürük. Niyə bunu edirik? Birincisi, biz həmişə bu prosesin prosesinə nəzarət edirik. Biz bilirik ki, biz artıq bu qədər partiya köçürmüşük və çoxlu sayda partiyamız qalıb.
- İkinci müsbət təsir odur ki, hər bir belə partiya arasında əməliyyat bağlayırıq, yenisini açırıq və bu, avtovakuumun lövhəyə uyğun işləməsini, təkrar istifadə üçün ölü xətləri qeyd etməyi mümkün edir.
- Tətbiqin işləməsi zamanı görünəcək sətirlər üçün (hələ köhnə tətbiqimiz var) yeni sahələrə yeni dəyərlər yazan bir tətik əlavə edirik. Bizim vəziyyətimizdə bu, köhnə dəyərin yüz ilə vurulmasıdır.
- Əgər biz tamamilə inadkarıqsa və eyni sahəni istəyiriksə, bütün köçürmələr başa çatdıqdan sonra və tətbiqin yeni versiyasını yaymazdan əvvəl, sadəcə sahələrin adını dəyişdiririk. Köhnələr bəzi icad edilmiş adlara çevrilir və biz yeni sahələri köhnələrə dəyişdiririk.
- Və yalnız bundan sonra tətbiqin yeni versiyasını işə salırıq.
Və eyni zamanda, biz şişirməyəcəyik və performansda əyilməyəcəyik.
Bu üçüncü hekayənin sonu.
İndi ilk hekayədə qeyd etdiyim alətlər haqqında bir az daha çox danışdım.
Şişkinliyi axtarmadan əvvəl, uzantı quraşdırmalısınız .
İstəklər uydurmayasınız deyə, biz artıq bu sorğuları öz işimizdə yazmışıq. Onlardan istifadə edə bilərsiniz. Burada iki xahiş var.
- Birincisi olduqca uzun vaxt tələb edir, ancaq cədvələ uyğun olaraq şişkinliyin dəqiq dəyərlərini göstərəcəkdir.
- İkincisi daha sürətli işləyir və cədvəldə şişkinlik olub-olmadığını tez bir zamanda qiymətləndirmək lazım olduqda çox təsirli olur. Həm də başa düşməlisiniz ki, Postgres cədvəlində həmişə şişkinlik var. Bu, onun MVCC modelinin bir xüsusiyyətidir.
- Və 20% şişkinlik əksər hallarda masalar üçün yaxşıdır. Yəni narahat olmamalı və bu cədvəli sıxmamalısınız.
Bizimlə şişmiş masaları, üstəlik, faydasız məlumatlarla şişdikdə necə müəyyənləşdirəcəyimizi anladıq.
İndi şişkinliyi necə düzəltmək haqqında:
- Kiçik boşqabımız və yaxşı disklərimiz varsa, yəni bir gigabayta qədər boşqabda, VACUUM FULL-dən istifadə etmək olduqca mümkündür. O, sizdən bir neçə saniyəyə eksklüziv kilid alacaq və tamam, amma hər şeyi tez və sərt şəkildə edəcək. VACUUM FULL nə edir? Masada eksklüziv kilid alır və köhnə cədvəllərdən yeni cədvələ canlı sətirləri yenidən yazır. Və sonda onları əvəz edir. Köhnə faylları silir, köhnələri yeniləri ilə əvəz edir. Ancaq işlədiyi müddətdə masada eksklüziv bir kilid alır. Bu o deməkdir ki, siz bu cədvəllə heç nə edə bilməzsiniz: nə ona yaza, nə oxuya, nə də dəyişdirə. Və VACUUM FULL məlumat yazmaq üçün əlavə disk sahəsi tələb edir.
- Növbəti Alət . Prinsipinə görə, o, VACUUM FULL-ə çox bənzəyir, çünki o, həm də köhnə fayllardakı məlumatları yenilərinə yazır və onları cədvəldə əvəz edir. Ancaq eyni zamanda, işinin əvvəlində masada eksklüziv bir kilid götürmür, ancaq faylları əvəz etmək üçün hazır məlumatlara sahib olduğu anda götürür. O, VACUUM FULL ilə eyni disk resurs tələblərinə malikdir. Sizə əlavə disk sahəsi lazımdır və terabayt cədvəlləriniz varsa, bu bəzən çox vacibdir. Və prosessor baxımından olduqca acgözdür, çünki I / O ilə fəal işləyir.
- Üçüncü köməkçi proqramdır . O, resurslara daha diqqətli yanaşır, çünki bir az fərqli prinsiplər üzərində işləyir. pgcompacttable-ın əsas mahiyyəti ondan ibarətdir ki, o, bütün canlı sətirləri cədvəldəki yeniləmələrlə cədvəlin əvvəlinə köçürür. Və sonra bu masada vakuum başlayır, çünki biz bilirik ki, başlanğıcda canlı cərgələr və sonunda ölü cərgələr var. Və vakuum özü bu quyruğu kəsir, yəni çox əlavə disk sahəsi tələb etmir. Və eyni zamanda, hələ də resurslarla sıxışdırıla bilər.
Alətlərlə hər şey.
Əgər şişkinlik mövzusunu daha da dərinləşdirmək baxımından maraqlı hesab edirsinizsə, onda sizin üçün bəzi faydalı bağlantılar var:
- həmkarımın hesabatıdır. Postgresin iş və həyatı zamanı yerinin hara getdiyi haqqında ümumidir. Və şişkinlik haqqında DBA-lar üçün çox böyük və ətraflı texniki parça var.
- verilənlər bazası statusunu yoxlamaq üçün bir dəstə faydalı skript saxladığımız depomuza keçiddir. Orada bloat axtarış skriptlərini tapa bilərsiniz.
- и plitələri sıxmağa kömək edəcək alətlərə bağlantılar.
- Bu, həmkarımın yazısıdır. Orada o, kifayət qədər ciddi və texniki cəhətdən inzibatçılara yaxın səviyyədə şişkinliyi ətraflı təhlil edir.
Burada tərtibatçılar üçün bir dəhşət hekayəsi göstərməyə çalışdım, çünki onlar verilənlər bazalarının birbaşa müştərilərimizdir və nəyə və hansı hərəkətlərə səbəb olduğunu başa düşməlidirlər. Ümid edirəm ki, bacardım. Diqqətinizə görə təşəkkürlər!
Suallar
Hesabat üçün təşəkkür edirik! Problemləri necə müəyyənləşdirmək barədə danışdınız. Onlara necə xəbərdarlıq etmək olar? Yəni, elə bir vəziyyət yaranmışdı ki, müraciətlər təkcə bəzi xarici xidmətlərə müraciət etdiyinə görə asılı deyildi. Sadəcə bəzi vəhşi birləşmələr idi. Bəzi xırda, zərərsiz istəklər var idi ki, onlar bir gün asılır, sonra bir növ cəfəngiyat etməyə başladılar. Yəni sizin təsvir etdiyinizə çox oxşardır. Bunu necə izləmək olar? Otur və daim izlə, hansı sorğu ilişib qalıb? Bunun qarşısını necə almaq olar?
Bu halda, bu, mütləq DBA üçün deyil, şirkətinizin idarəçiləri üçün bir vəzifədir.
Mən idarəçiyəm.
PostgreSQL-də gözləyən sorğuları göstərən pg_stat_activity adlı bir görünüş var. Və orada nə qədər dayandığını görə bilərsiniz.
Mən hər 5 dəqiqədən bir gəlib baxmalıyam?
Cron qurun və yoxlayın. Uzun bir xahişiniz varsa, məktub yazın və bu qədər. Yəni gözlərinizlə baxmaq lazım deyil, bu avtomatlaşdırıla bilər. Bir məktub alacaqsınız, ona cavab verəcəksiniz. Və ya avtomatik çəkə bilərsiniz.
Bunun baş verməsinin aydın səbəbləri varmı?
Bəzilərini sadaladım. Digər daha mürəkkəb nümunələr. Və uzun söhbət ola bilər.
Hesabat üçün təşəkkür edirik! pg_repack yardım proqramına aydınlıq gətirmək istədim. Eksklüziv kilidi qəbul etmirsə, onda...
O, eksklüziv kilid düzəldir.
... onda mən potensial olaraq məlumatları itirə bilərdim. Mənim tətbiqim bu anda nəyisə qeyd etməməlidir?
Xeyr, o, masa ilə sakit işləyir, yəni pg_repack əvvəlcə orada olan bütün canlı xətləri köçürür. Təbii ki, cədvəldə bir növ rekord var. Sadəcə bu at quyruğunu atır.
Yəni hələ də axırda belə edir?
Sonda bu faylları dəyişdirmək üçün eksklüziv kilid tələb olunur.
VACUUM FULL-dən daha sürətli olacaqmı?
VACUUM FULL, işə başlayan kimi dərhal eksklüziv kilidi götürdü. Və hər şeyi edənə qədər onu buraxmayacaq. Və pg_repack yalnız faylların dəyişdirilməsi zamanı eksklüziv kilid alır. Bu nöqtədə siz orada yazmırsınız, amma məlumatlar itməyəcək, hər şey qaydasında olacaq.
Salam! Siz avtovakuumun işindən danışdınız. Qeydin qırmızı, sarı və yaşıl xanaları olan bir qrafik var idi. Yəni, sarı olanları - silinmiş kimi qeyd etdi. Və nəticədə onlarda yeni bir şey yaza bilərsiniz?
Bəli. Postgres satırları silmir. Onun belə bir spesifikliyi var. Xətti yeniləmişiksə, köhnəni silinmiş kimi qeyd etdik. Bu xətti dəyişdirən əməliyyat id oraya qalxır və biz yeni sətir yazırıq. Və onları oxuya biləcək seanslarımız var. Müəyyən bir nöqtədə onlar kifayət qədər qocalırlar. Avtovakuumun mahiyyəti isə ondan ibarətdir ki, o, bu xətlərdən keçir və onları lazımsız kimi qeyd edir. Və orada məlumatların üzərinə yaza bilərsiniz.
Mən başa düşürəm. Amma sual bununla bağlı deyil. Razı olmadım. Tutaq ki, masamız var. Dəyişən ölçülü sahələrə malikdir. Yeni bir şey daxil etməyə çalışsam, o, sadəcə köhnə hüceyrəyə sığmaya bilər.
Xeyr, hər halda bütün xətt yenilənir. Postgres-in iki saxlama modeli var. Məlumat növündən seçir. Birbaşa cədvəldə saxlanılan məlumatlar var və tos məlumatları da var. Bunlar böyük həcmdə verilənlərdir: mətn, json. Onlar ayrı tabletlərdə saxlanılır. Və bu tabletlərə görə, şişkinliklə eyni hekayə baş verir, yəni hər şey eynidir. Onlar sadəcə ayrıca sadalanır.
Hesabat üçün təşəkkür edirik! Müddəti məhdudlaşdırmaq üçün bəyanatın vaxt aşımı sorğularından istifadə etmək nə dərəcədə məqbuldur?
Çox məqbuldur. Biz hər yerdə istifadə edirik. Öz xidmətlərimiz olmadığından, biz uzaqdan dəstək veririk, kifayət qədər müxtəlif müştərilər var. Və hər kəs bundan kifayət qədər razıdır. Yəni cronda çek işlərimiz var. Sadəcə olaraq, seansların müddəti müştəri ilə razılaşdırılır, ondan əvvəl biz mismar vermirik. Bir dəqiqə də ola bilər, 10 dəqiqə də ola bilər. Baza yükündən və məqsədindən asılıdır. Amma hamımız pg_stat_activity istifadə edirik.
Hesabat üçün təşəkkür edirik! Müraciətlərim üçün hesabatınızı sınamağa çalışıram. Və deyəsən, biz hər yerdə əməliyyata başlayırıq və onu hər yerdə açıq şəkildə tamamlayırıq. Bəzi istisnalar varsa, bütün eyni geri çəkilmə baş verir. Və sonra düşündüm. Axı, əməliyyat açıq şəkildə başlaya bilməz. Bu qıza bir işarədir, məncə. Mən sadəcə rekord yeniləmə etsəm, əməliyyat PostgreSQL-də başlayacaq və yalnız əlaqə kəsildikdə bitəcək?
Əgər indi proqram səviyyəsindən danışırsınızsa, bu, istifadə etdiyiniz sürücüdən, istifadə olunan ORM-dən asılıdır. Orada çoxlu parametrlər var. Avtomatik öhdəliyi aktivləşdirsəniz, əməliyyat orada başlayır və dərhal bağlanır.
Yəni yeniləmədən dərhal sonra bağlanır?
Bu, parametrlərdən asılıdır. Bir ayarı adlandırdım. Bu avtomatik öhdəlikdir. O, olduqca adidir. Aktivdirsə, əməliyyat açılıb və bağlanıb. Əgər siz açıq şəkildə “əməliyyata başla” və “əməliyyatı bitir” deməsəniz, sadəcə olaraq sessiyaya sorğu göndərmisiniz.
Salam! Hesabat üçün təşəkkür edirik! Təsəvvür edin ki, bizdə qabaran və qabaran verilənlər bazası var və sonra serverdə boşluq yaranıb. Bu vəziyyəti düzəltmək üçün hər hansı vasitələr varmı?
Serverdəki yeri yaxşı bir şəkildə izləmək lazımdır.
Məsələn, DBA çay içməyə getdi, kurortda idi və s.
Fayl sistemi yaradıldıqda, verilənlərin yazılmadığı yerlərdə ən azı bir qədər ehtiyat boşluq yaranır.
Bəs tamamilə sıfırdırsa?
Orada ona qorunan yer deyilir, yəni onu azad etmək olar və onun nə qədər böyük olmasından asılı olaraq boş yer əldə edirsiniz. Varsayılan olaraq, orada neçə olduğunu bilmirəm. Və başqa bir halda, diskləri çatdırın ki, bərpa əməliyyatı aparmaq üçün bir yeriniz olsun. Ehtiyacınız olmadığına zəmanət verilən bəzi cədvəlləri silə bilərsiniz.
Başqa alətlər yoxdur?
Həmişə əl işidir. Və orada nəyin daha yaxşı olduğu ortaya çıxır, çünki kritik olan məlumatlar var, kritik olmayanlar var. Və onunla işləyən hər bir verilənlər bazası və proqram üçün bu, biznesdən asılıdır. Həmişə yerində qərar verilir.
Hesabat üçün təşəkkür edirik! Mənim iki sualım var. Birincisi, slaydlar göstərdiniz ki, burada asılmış əməliyyatlar zamanı həm masa sahəsinin miqdarı, həm də indeksin ölçüsü böyüyür. Daha sonra hesabatda planşetləri qablaşdıran bir sıra kommunal xidmətlər var idi. Bəs indeks haqqında nə demək olar?
Onları da qablaşdırırlar.
Amma vakuum indeksə təsir etmir?
Bəziləri indekslə işləyir. Məsələn, pg_rapack, pgcompacttable. Vakuum indeksləri yenidən yaradır, onlara təsir göstərir. VACUUM FULL hər şeyi üzərinə yazmaq mahiyyətinə malikdir, yəni hamı ilə işləyir.
Və ikinci sual. Replikalarla bağlı hesabatların niyə replikaların özündən bu qədər asılı olduğunu başa düşmədim. Mənə elə gəldi ki, hesabatlar oxunur, replika isə yazır.
Replikasiya münaqişəsinə nə səbəb olur? Proseslərin baş verdiyi Ustadımız var. Bizdə avtovakuum var. Avtovakuum əslində nə edir? Bir neçə köhnə sətirləri kəsir. Əgər bu anda bu köhnə sətirləri oxuyan replika ilə bağlı sorğumuz varsa və Master-da avtovakuumun bu sətirləri yenidən yazmaq üçün mümkün olduğu kimi qeyd etdiyi bir vəziyyət var idisə, biz onların üzərinə yazdıq. Biz məlumat paketi aldıq, sorğunun replikada ehtiyac duyduğu sətirləri yenidən yazmalı olduğumuz zaman replika prosesi konfiqurasiya etdiyiniz fasiləni gözləyəcək. Və sonra PostgreSQL onun üçün nəyin daha vacib olduğuna qərar verəcək. Və replika onun üçün sorğudan daha vacibdir və o, replikada bu dəyişiklikləri etmək tələbini çəkəcək.
Andrey, bir sualım var. Təqdimat zamanı göstərdiyiniz bu gözəl qrafika, bu sizin kommunal işinizin nəticəsidirmi? Qrafiklər necə quruldu?
Bu bir xidmətdir .
Bu kommersiya məhsuludur?
Bəli. Bu kommersiya məhsuludur.
Mənbə: www.habr.com