Филозофски увод
Као што знате, постоје само два начина за решавање проблема:
- Метода анализе или метода дедукције, или од општег ка специфичном.
- Метода синтезе или метода индукције, или од посебног ка општем.
Да би се решио проблем „побољшања перформанси базе података“, то би могло изгледати овако.
Анализа — анализирамо проблем на одвојене делове и њиховим решавањем покушавамо да побољшамо перформансе базе података у целини.
У пракси, анализа изгледа отприлике овако:
- Дошло је до проблема (инцидент учинка)
- Прикупљање статистичких информација о стању базе података
- У потрази за уским грлима
- Проблеме решавамо из уских грла
Уска грла у бази података — инфраструктура (ЦПУ, Меморија, Дискови, Мрежа, ОС), подешавања (постгрескл.цонф), упити:
Инфраструктура: Могућности утицаја и промене за инжењера су скоро равне нули.
Подешавања базе података: могућности за промене су нешто веће него у претходном случају, али су по правилу и даље прилично тешке, посебно у облацима.
zahtevi у базу података: само маневарски простор.
Синтеза — побољшавамо перформансе појединачних делова, очекујући да ће се перформансе базе података побољшати као резултат.
Лирски увод или зашто је све ово потребно
Који је процес за решавање инцидената перформанси ако се перформансе базе података не надгледају:
Муштерија - „све је лоше код нас, предуго траје, учините нешто добро за нас“
Инжењер - "колико је то лоше?"
Купац – „тако је сада (пре сат времена, јуче, прошли пут) полако“
Инжењер - "када је било добро?"
Купац – „Пре недељу дана (две недеље) није било лоше. „(срећа је)
Купац - „Не сећам се када је било добро, али сада је лоше“ (Редован одговор)
Резултат је класична слика:
Ко је крив и шта да ради?
На први део питања је најлакше одговорити – увек је крив ДБА инжењер.
На други део такође није тешко одговорити - потребно је да имплементирате систем за праћење перформанси базе података.
Поставља се прво питање - шта пратити?
Пут 1. Пратићемо СВЕ
Оптерећење ЦПУ-а, број операција читања/уписивања на диск, величина додељене меморије и још једна мегатона различитих бројача које сваки мање-више радни систем за праћење може да обезбеди.
Резултат је гомила графикона, табела са резимеом и континуираних обавештења путем е-поште и 100% заузет инжењер који решава гомилу идентичних тикета, међутим, по правилу, са стандардном формулацијом - „Привремени проблем. Није потребна никаква акција.” Али сви су заузети, и увек постоји нешто да се покаже купцу - посао је у пуном јеку.
Начин 2. Надгледајте само оно што је потребно, а оно што није потребно не треба пратити
Можете пратити, мало другачије, само ентитете и догађаје:
- На које ДБА инжењер може да утиче
- За које постоји алгоритам радњи када се деси догађај или се ентитет промени.
На основу ове претпоставке и сећања "Филозофски увод"како би се избегло редовно понављање"Лирски увод или зашто је све ово потребно„Било би препоручљиво пратити перформансе појединачних упита ради оптимизације и анализе, што би на крају требало да доведе до побољшања перформанси целе базе података.
Али да бисте побољшали тежак упит који утиче на укупне перформансе базе података, прво га морате пронаћи.
Дакле, постављају се два међусобно повезана питања:
- који захтев се сматра тешким
- како тражити тешке упите.
Очигледно, тежак упит је упит који користи много ОС ресурса да би добио резултат.
Пређимо на друго питање – како претраживати, а затим пратити тешке упите?
Које могућности праћења упита има ПостгреСКЛ?
У поређењу са Орацле-ом, мало је могућности, али ипак нешто може да се уради.
ПГ_СТАТ_СТАТЕМЕНТС
За претраживање и праћење тешких упита у ПостгреСКЛ-у, намењено је стандардно проширење пг_стат_статементс.
Након инсталирања екстензије, у циљној бази података појављује се приказ истог имена, који треба да се користи у сврхе надгледања.
Циљајте пг_стат_статементс колоне за изградњу система за праћење:
- куериид Интерни хеш код израчунат из стабла рашчлањивања оператора
- мак_тиме Максимално време утрошено на изјаву, у милисекундама
Сакупљањем и коришћењем статистике за ове две колоне можете изградити систем за праћење.
Како се пг_стат_статементс користи за праћење перформанси ПостгреСКЛ-а
За праћење учинка упита користите:
На страни циљне базе података - пг_стат_статементс поглед
Са стране сервер и праћење база података - скуп басх скрипти и сервисних табела.
Фаза 1 – прикупљање статистичких података
На хосту за праћење црон-а се редовно покреће скрипта која копира садржај пг_стат_статементс погледа из циљне базе података у табелу пг_стат_хистори у бази података за праћење.
Ово ствара историју појединачних извршавања упита која се може користити за генерисање извештаја о учинку и конфигурисање метрике.
Фаза 2 - постављање метрике учинка
На основу прикупљених података бирамо упите чије је извршење најкритичније/најважније за клијента (апликацију). У договору са купцем постављамо вредности метрике перформанси помоћу поља куериид и мак_тиме.
Резултат - почетак праћења перформанси
- Скрипта за надгледање, када се покрене, проверава конфигурисане метрике учинка упоређивањем вредности мак_тиме метрике са вредношћу из пг_стат_статементс приказа у циљној бази података.
- Ако вредност у циљној бази података премашује метричку вредност, генерише се упозорење (инцидент у систему карата)
Додатна опција 1
Историја плана упита
Да бисте касније помогли у решавању инцидената са перформансама, добра је идеја да имате историју промена планова извршења упита.
Табела услуге лог_куери се користи за чување историје. Табела се попуњава када се анализира учитана ПостгреСКЛ датотека евиденције. Пошто датотека евиденције, за разлику од пг_стат_статементс погледа, садржи цео текст са вредностима параметара извршења, а не нормализовани текст, могуће је евидентирати не само време и трајање захтева, већ и ускладиштити планове извршења на тренутном време.
Додатна опција 2
Процес континуираног побољшања перформанси
Праћење појединачних упита уопште није намењено решавању проблема континуираног побољшања перформанси базе података као целине, јер прати и решава проблеме перформанси само за појединачне упите. Међутим, можете проширити метод и конфигурисати упите за праћење за све базе података.
Да бисте то урадили, потребно је да унесете додатне показатеље учинка:
- За последње дане
- За базни период
Скрипта бира упите из пг_стат_статементс погледа у циљној бази података и упоређује вредност мак_тиме са просечном вредношћу мак_тиме, у првом случају за последње дане или за изабрани временски период (основни), у другом случају.
Дакле, у случају деградације перформанси за било који захтев, упозорење ће бити генерисано аутоматски, без ручне анализе извештаја.
Какве везе има синтеза са тим?
У описаном приступу, како метода синтезе сугерише, унапређењем појединих делова система, унапређујемо систем у целини.
- Упит који извршава база података – сажетак
- Измењени захтев – антитеза
- Промена стања система – синтеза
Развој система
- Проширења прикупљене статистике додавањем историје за системски приказ пг_стат_ацтивити
- Проширивање прикупљене статистике додавањем историје за статистику појединачних табела које учествују у упитима
- Интеграција са АВС системом за праћење облака
- Па ипак, можете смислити нешто...
Извор: ввв.хабр.цом
