Прапаную азнаёміцца з расшыфроўкай даклада Мікалая Самахвалава "Прамысловы падыход да цюнінгу PostgreSQL: эксперыменты над базамі дадзеных"
Shared_buffers = 25% - гэта шмат ці мала? Ці ў самы раз? Як зразумець, ці падыходзіць гэтая - даволі састарэлая - рэкамендацыя ў вашым канкрэтным выпадку?
Прыйшоў час падысці да пытання падбору параметраў postgresql.conf "па-даросламу". Не з дапамогай сляпых "автотюнеров" або састарэлых парад з артыкулаў і блогаў, а на аснове:
- строга вывераных эксперыментаў на БД, якія вырабляюцца аўтаматызавана, у вялікіх колькасцях і ва ўмовах, максімальна набліжаных да "баявых",
- глыбокага разумення асаблівасцяў працы СКБД і АС.
Выкарыстоўваючы Nancy CLI (), мы разгледзім канкрэтны прыклад - праславутыя shared_buffers - у розных сітуацыях, у розных праектах і паспрабуем разабрацца, як жа падабраць аптымальную наладу для нашай інфраструктуры, БД і нагрузкі.
Размова пойдзе аб эксперыментах над базамі даных. Гэта гісторыя, якая працягваецца крыху больш за паўгода.
Крыху пра мяне. Вопыт з Postgres ужо больш за 14 гадоў. Шэраг кампаній заснаваў сацыяльна-сеткавых. Усюды выкарыстоўваўся Postgres і выкарыстоўваецца.
Таксама гурт RuPostgres на Meetup, 2-е месца ў свеце. Набліжаемся паціху да 2 000 чалавек. RuPostgres.org.
І ў ПК розных канферэнцый, у тым ліку Highload, я адказваю за базы дадзеных, у прыватнасці Postgres з самага падставы.
І ў апошнія некалькі гадоў я рэстартаваў маю практыку па Postgres-кансалтынгу ў 11 гадзінных паясах ад сюды.
І калі я гэта зрабіў некалькі гадоў таму, у мяне быў некаторы перапынак актыўнай ручной працы з Postgres, мусіць, з 2010-го гады. Я здзівіўся, наколькі мала змяніліся працоўныя будні DBA, наколькі трэба па-ранейшаму шмат ручной працы выкарыстоўваць. І я адразу падумаў, што тут нешта не так, трэба аўтаматызаваць найбольш.
І так як гэта ўсё было ў выдаленні, то большасць кліентаў было ў аблоках. І ўжо шмат аўтаматызавана відавочна. Пра гэта крыху пазней. Т. е. усё гэта вылілася ў ідэю, што павінна быць шэраг прылад, т. е. нейкая платформа, якая будзе аўтаматызаваць практычна ўсе дзеянні DBA, каб можна было кіраваць вялікай колькасцю баз.
У гэтым дакладзе не будзе:
- "Сярэбраных куль" і заяў тыпу - стаўце 8 GB або 25% shared_buffers і вам будзе добра. Пра shared_buffers будзе ня так шмат.
- Хардкорных «вантроб».
А што будзе?
- Будуць прынцыпы аптымізацыі, якія мы прымяняем і развіваем. Будуць усякія ідэі, якія ўзнікаюць у нас на шляхі і розныя прылады, якія мы ствараем па большай частцы ў Open Source, т. е. мы аснову які робіцца ў Open Source. Больш за тое ў нас цікеты, усе зносіны практычна ў Open Source. Вы можаце глядзець, што мы зараз робім, што будзе ў наступным рэлізе і г. д.
- А таксама будзе некаторы досвед выкарыстання гэтых прынцыпаў, гэтых прылад у шэрагу кампаній: ад маленькіх стартапаў да вялікіх кампаній.
Як гэта ўсё развіваецца?
Па-першае, асноўная задача DBA акрамя забеспячэння стварэння instances, разгортвання бэкапаў і т. д., - гэта пошук вузкіх месцаў і аптымізацыя прадукцыйнасці.
Цяпер гэта ўладкована вось такім чынам. Мы глядзім маніторынг, нешта бачым, нейкіх падрабязнасьцяў нам не хапае. Мы пачынаем капацца больш уважліва, звычайна рукамі і разумеем, што з гэтым рабіць так ці інакш.
І ёсць два падыходы. Pg_stat_statements - стандартнае рашэнне па змаўчанні для выяўлення павольных запытаў. І аналіз логаў Postgres з дапамогай pgBadger.
У кожнага з падыходаў ёсць сур'ёзныя недахопы. У першага падыходу ў нас выкінуты ўсе параметры. І калі мы бачым групы SELECT * FROM table where калонка роўна знаку "?" ці "$" пачынальна з версіі Postgres 10. Мы не ведаем - гэта index scan або seq scan. Вельмі моцна залежыць ад параметра. Падставіш туды рэдка сустракаемае значэнне, будзе index scan. Падставіш туды значэнне, якое займае 90% табліцы, будзе seq scan відавочна, таму што Postgres ведае статыстыку. І гэта вялікі недахоп pg_stat_statements, хаця нейкія працы вядуцца.
У аналізаў логаў самы галоўны недахоп у тым, што вы не можаце сабе дазволіць "log_min_duration_statement = 0", як правіла. І пра гэта мы таксама пагаворым. Адпаведна, вы бачыце не ўсю карцінку. І нейкі запыт, які вельмі хуткі, можа спажываць велізарную колькасць рэсурсаў, але вы яго не ўбачыце, таму што ён ніжэй за ваш парог.
Як DBA вырашаюць знойдзеныя праблемы?
Напрыклад, мы знайшлі нейкую праблему. Што звычайна робіцца? Калі вы распрацоўшчык, то вы будзеце нешта рабіць на нейкім instance, які не такога памеру. Калі вы DBA, то ў вас есць staging. І ён можа быць толькі адзін. І ён адстаў на паўгода. І вы думаеце, што пойдзеце на production. І нават дасведчаныя DBA правяраюць потым на production, на рэпліцы. І бывае што ствараюць часовы індэкс, пераконваюцца, што ён дапамагаюць, драпаюць яго і аддаюць распрацоўшчыкам, каб яны яго ў міграцыйныя файлы засунулі. Вось такое трызненне адбываецца цяпер. І гэта бяда.
- Цюніць канфігурацыі.
- Аптымізаваць набор індэксаў.
- Змяняць сам SQL-запыт (гэта самы складаны спосаб).
- Дадаваць магутнасцяў (самы просты спосаб у большасці выпадкаў).
З гэтымі рэчамі вельмі шмат усяго. Там шмат ручак у Postgres. Трэба шмат шляхта. Шмат індэксаў у Postgres дзякуючы ў тым ліку арганізатарам гэтай канферэнцыі. І ўсё гэта трэба ведаць, і менавіта гэта ў не DBA выклікае адчуванне, што DBA займаюцца чорнай магіяй. Т. е. трэба гадоў 10 займацца, каб пачаць разумець усё гэта нармальна.
І я - змагар з гэтай чорнай магіяй. Я хачу зрабіць усё так, каб была тэхналогія, а не было інтуіцыі ва ўсім гэтым.
Прыклады з жыцця
Гэта я назіраў мінімум у двух праектах, у тым ліку свой. Чарговы пост у блогу паведамляе нам, што значэнне 1 для default_statistict_target - гэта добра. Добра, давайце паспрабуем у production.
І тут мы, выкарыстоўваючы наш інструмент праз два гады з дапамогай эксперыментаў над базамі дадзеных, пра якія сёння гаворка, мы можам параўнаць што было і што стала.
І для гэтага нам трэба стварыць эксперымент. Ён складаецца з чатырох частак.
- Першая - гэта асяроддзе. Нам патрэбная жалязяка. І калі я прыходжу ў нейкую кампанію і заключаю кантракт, то я кажу, каб мне далі такую ж жалязяку як на production. Для кожнага з вашых Майстроў мне патрэбна хаця б адна жалязяка такая ж. Або гэта віртуальная машына instance у Амазоне ці ў Google, альбо мне менавіта такая жа жалязяка патрэбна. Т. е. я хачу ўзнавіць асяроддзе. І ў паняцце асяроддзе мы ўкладваем мажорную версію Postgres.
- Другая частка - гэта аб'ект нашых даследаванняў. Гэта база даных. Яе можна стварыць некалькімі спосабамі. Я пакажу як.
- Трэцяя частка - гэта нагрузка. Гэта самы складаны момант.
- І чацвёртая частка - гэта тое, што мы правяраем, т. е. што з чым параўноўваць будзем. Дапусцім, мы можам у канфігу памяняць адзін або некалькі параметраў, а можам індэкс стварыць і г. д.
Мы запускаем эксперымент. Вось pg_stat_statements. Злева - тое, што было. Справа - што стала.
Злева default_statistics_target = 100, справа = 1. Мы бачым, што нам гэта дапамагло. На 000% у цэлым усё лепш стала.
Але калі мы праматаем уніз, то там будуць групы запытаў з pgBadger ці з pg_stat_statements. Тут два варыянты. Мы ўбачым, што нейкі запыт асеў на 88%. І тут ужо інжынерны падыход. Мы можам далей капаць унутр, таму што цікава, чаму ён асеў. Трэба разумець, што тамака было са статыстыкай. Чаму больш бакетаў у статыстыцы прыводзяць да найгоршага выніку.
А можам не капаць, а зрабіць "ALTER TABLE … ALTER COLUMN" і яму назад 100 бакетаў вернем у статыстыку гэтай калонцы. І далей яшчэ эксперыментам мы можам пераканацца, што гэтая латка дапамагла. Усё. Вось гэта інжынерны падыход, які дапамагае нам бачыць карціну і прымаць рашэнне на аснове даных, а не на аснове інтуіцыі.
Пара прыкладаў з іншых абласцей. У тэстах ёсць CI-тэсты ўжо шмат гадоў. І ніводны ўжо праект у разумным розуме не будзе жыць без аўтаматычных тэстаў.
У іншых галінах: у авіяцыі, у аўтамабілебудаванні, калі выпрабоўваем аэрадынаміку, у нас таксама ёсць магчымасць рабіць эксперыменты. Мы не будзем нешта з чарцяжа адразу ў космас запускаць ці не будзе нейкую машыну адразу выводзіць на трасу. Напрыклад, ёсць аэрадынамічная труба.
З назіранняў за іншымі галінамі мы можам зрабіць высновы.
Па-першае, у нас ёсць спецыяльнае асяроддзе. Яно блізка да production, але не блізка. Галоўная яго асаблівасць у тым, што павінна быць танна, паўтарана і максімальна аўтаматызавана. І яшчэ павінны быць спецыяльныя сродкі для правядзення дэталёвага аналізу.
Хутчэй за ўсё, калі мы самалёт запусцілі і ляцім, у нас менш магчымасцяў вывучаць кожны міліметр паверхні крыла, чым ёсць у аэрадынамічнай трубе. У нас больш сродкаў для дыягностыкі. Мы можам сабе дазволіць навесіць найбольш цяжкага, што не можам дазволіць сабе наведаць самалёт у паветры. Таксама і з Postgres. Мы можам у некаторых выпадках уключыць поўнае лагіраванне запытаў пры эксперыментах. І мы гэтага на production рабіць не жадаем. Мы, магчыма, нават з планамі гэта ўключым з дапамогай auto_explain.
І як я ўжо сказаў, высокі ўзровень аўтаматызацыі азначае, што мы націснулі кнопку і паўтарылі. Вось так павінна гэта быць, каб было шмат эксперыментаў, каб гэта было на плыні.
Nancy CLI - падмурак «лабараторыі БД»
І вось мы зрабілі такую штуку. Г. зн. я пра гэтыя ідэі расказваў у чэрвені, амаль год таму. І ў нас ужо ёсць у Open Source так званая Nancy CLI. Гэта падмурак для таго, каб будаваць лабараторыю базы даных.
- Гэта ў Open Source, на Gitlab. Можаце сказаць, можаце паспрабаваць. Я даў спасылачку ў слайдах. На яе можна клікнуць і там будзе па ўсіх параметрах.
Вядома, там шмат яшчэ ў стадыі распрацоўкі. Там шмат ідэй. Але гэта ўжо тое, што мы прымяняем практычна штодня. І калі ў нас узнікае ідэя - а што гэта пры delete 40 радкоў у нас усё ўперлася ў IO, то мы можам правесці эксперымент і паглядзець падрабязней, каб зразумець, што адбываецца і далей паспрабаваць выправіць гэта на хаду. Т. е. мы робім эксперымент. Напрыклад, нешта падкручваем і глядзім, што ў выніку атрымліваецца. І мы гэта які робіцца не на production. Гэта сутнасць ідэі.
Дзе гэта можа працаваць? Гэта можа працаваць лакальна, т. е. можна гэта рабіць дзе заўгодна, можна нават на MacBook запусціць. Патрэбен докер, паехалі. І ўсё. Можна запусціць у якім-небудзь instance у жалязяцы, або ў віртуалцы, дзе заўгодна.
І ёсць яшчэ магчымасць запускаць выдалена ў Амазоне ў EC2 Instance, у спотах. І гэта вельмi класная магчымасць. Напрыклад, учора мы правялі больш за 500 эксперыментаў на i3 instance, пачынаючы з самага малодшага і заканчваючы i3-16-xlarge. І нам 500 эксперыментаў сталі ў 64 долары. Кожны доўжыўся 15 хвілін. Т. е. за кошт таго, што там выкарыстоўваюцца споты, гэта вельмі танна - зніжка 70%, пасекундная тарыфікацыя Амазона. Вы можаце зрабіць вельмі шмат. Вы можаце рэальнае даследаванне праводзіць.
І тры мажорныя версіі Postgres падтрымліваюцца. Не так складана дапілаваць нейкія старыя і новую 12-ую версію таксама.
Аб'ект мы можам трыма спосабамі задаваць. Гэта:
- Dump/sql-файл.
- Галоўны спосаб - гэта клон PGDATA дырэкторыя. Як правіла бярэцца з бэкап-сервера. Калі ў вас ёсць нармальныя бэкапы нармальныя, адтуль можаце клоны рабіць. Калі ў вас ёсць аблокі, то за вас гэта хмарная кантора тыпу Амазона і Google сама будзе рабіць. Гэта найгалоўнейшы спосаб для клонаў рэальнага production. Мы такім чынам якраз разгортваем.
- І апошні спосаб падыходзіць для даследаванняў, калі ёсць жаданне разабрацца, як у Postgres працуе нейкая штука. Гэта pgbench. Вы можаце згенераваць з дапамогай pgbench. Гэта проста адна опцыя "db-pgbench". Кажаш яму, які scale. І ўсё будзе ў воблаку згенеравана, як сказана.
І нагрузка:
- Нагрузку мы можам у адзін струмень SQL выконваць. Гэта самы прымітыўны спосаб.
- А можам эмуляваць нагрузку. І эмуляваць мы першым чынам можам яе наступным чынам. Нам трэба збіраць усе логі. І гэта балюча. Я пакажу чаму. І з дапамогай pgreplay прайграем, які ўбудаваны ў Nancy.
- Або іншы варыянт. Так званая крафтавая нагрузка, якую мы робім з некаторай колькасцю намаганняў. Аналізуючы нашу бягучую нагрузку на баявую сістэму, мы выдзіраем топавыя групы запытаў. І з дапамогай pgbench можам эмуляваць гэтую нагрузку ў лабараторыі.
- Або мы SQL нейкі павінны выканаць, т. е. міграцыю нейкую правяраем, азначнік тамака ствараем, ANALAZE тамака выконваем. І глядзім, што было да вакуума і пасля вакуума. Увогуле, любы SQL.
- Або мы ў канфігу змяняем адзін ці некалькі параметраў. Мы можам сказаць, каб нам праверылі, напрыклад, 100 значэнняў у Амазоне для нашай тэрабайтнай базы. І праз некалькі гадзін у вас будзе рэзультат. Як правіла, тэрабайтная база ў вас будзе разгортвацца некалькі гадзін. Але ў распрацоўцы ёсць патч, у нас магчымая серыя, т. е. вы можаце паслядоўна на адным і тым жа серверы выкарыстоўваць тую ж самую pgdata і правяраць. Postgres будзе рэстартавацца, кэшы скідацца. І вы можаце ганяць нагрузку.
- Прыязджае дырэкторыя, у якой куча ўсякіх файлікаў, пачынальна ад снапшотаў pgстат***. І там самае цікавае - гэта pg_stat_statements, pg_stat_kcacke. Гэта два пашырэнні, якія аналізуюць запыты. І pg_stat_bgwriter утрымоўвае ў сабе не толькі pgwriter статыстыку, а яшчэ і па checkpoint і па тым, як самі бэкэнды выцясняюць брудныя буферы. І гэта ўсё цікава паглядзець. Напрыклад, калі мы shared_buffers наладжваем, то вельмі цікава паглядзець, колькі тамака хто выцясняў.
- Таксама прыязджаюць логі Postgres. Два лога - лог падрыхтоўкі і лог прайгравання нагрузкі.
- Адносна новая фіча - гэта FlameGraphs.
- Таксама, калі вы выкарыстоўвалі pgreplay ці pgbench варыянты прайгравання нагрузкі, то будзе родная іх выснова. І вы будзеце бачыць latency і TPS. Можна будзе зразумець, як яны гэта бачылі.
- Інфармацыя аб сістэме.
- Базавыя праверкі CPU і IO. Гэта больш для EC2 instance ў Амазоне, калі вы хочаце ў патоку запусціць 100 аднолькавых instances і там прагнаць па 100 розных прагонаў, то ў вас будзе 10 000 эксперыментаў. І вам трэба пераканацца, што вам не трапіўся недасканалы instance, якога ўжо хтосьці прыгнятае. На гэтай жалезцы іншыя актыўнічаюць і вам рэсурсу мала застаецца. Такія вынікі лепш адкінуць. І як раз з дапамогай sysbench ад Аляксея Капытова мы робім некалькі кароценькіх праверак, якія прыедуць і можна параўнаць з іншымі, г.зн. вы зразумееце, як CPU сябе паводзіць і як IO сябе паводзіць.
Якія ёсць тэхнічныя складанасці на прыкладзе розных кампаній?
Дапусцім, мы хочам рэальную нагрузку з дапамогай логаў паўтараць. Выдатная ідэя, калі гэта на Open Source pgreplay напісана. Мы яго выкарыстоўваем. Але, каб ён добра працаваў, вы павінны ўключыць поўнае лагіраванне запытаў з параметрамі і таймінгам.
Там існуюць некаторыя складанасці наконт duration і timestamp. Мы гэтую кухню ўсю апусцім. Галоўнае пытанне - ці можаце вы сабе такое дазволіць ці не можаце?
Праблема такая, што гэта можа быць недаступна. Вы павінны першым чынам зразумець, які струмень будзе ў лог пісацца. Калі ў вас ёсць pg_stat_statements, вы можаце вось такім запытам (спасылка будзе ў слайдах даступная) зразумець, колькі прыкладна байт будзе пісацца ў секунду.
Мы глядзім на даўжыню запыту. Мы грэбуем тым фактам, што тамака няма параметраў, але мы ведаем даўжыню запыту і ведаем, колькі разоў у секунду ён выконваўся. Такім чынам мы можам прыкінуць, колькі прыкладна байт у секунду. Мы можам памыліцца разы ў два, але парадак мы дакладна зразумеем такім спосабам.
Мы можам убачыць, што 802 разы на секунду гэты запыт выконваецца. І мы бачым, што bytes_per sec - 300 kB/s будзе пісацца плюс мінус. І, як правіла, мы такую плынь можам сабе дазволіць.
Але! Справа ў тым, што ёсць розныя сістэмы лагіравання. І па змаўчанні ў людзей звычайна "syslog".
І калі ў вас ёсць syslog, то ў вас можа быць вось такая карцінка. Мы возьмем pgbench, уключым лагіраванне запытаў і паглядзім, што атрымліваецца.
Без лагавання - гэта слупок злева. У нас атрымліваліся 161 TPS. З syslog - гэта ў Ubuntu 000 у Амазоне ў нас атрымліваецца 16.04 37 TPS. А калі мы зменім на два іншыя спосабы лагавання, то нашмат лепшая сітуацыя. Т. е. мы чакалі, што просядзе, але не настолькі ж.
А на CentOS 7, у якім яшчэ journald удзельнічае, ператвараючы логі ў бінарны фармат для зручнага пошуку і г. д., то там увогуле кашмар, у 44 разы прасядаем па TPS.
І гэта тое, з чым жывуць людзі. І часта ў кампаніях, асабліва ў буйных, гэта вельмі складана памяняць. Калі вы можаце з'ехаць ад syslog, то, калі ласка едзьце ад яго.
- Ацэніце IOPS і паток запісу.
- Праверце сваю сістэму лагіравання.
- Калі прагназуемая нагрузка празмеру вялікая, разгледзьце варыянт з сэмпляваннем.
У нас ёсць pg_stat_statements. Як я сказаў, ён абавязкова павінен быць. І мы можам узяць і кожную групу запытаў спецыяльным чынам апісаць у файліцы. І далей можам выкарыстоўваць вельмі зручную фічу ў pgbench - гэта магчымасць падсунуць некалькі файлікаў з дапамогай опцыі "-f".
Ён разумее шмат "-f". І можна сказаць з дапамогай "@" у канцы, якая дзель у кожнага файліка павінна быць. Т. е. мы можам сказаць, што вось гэта выконвай у 10% выпадках, а гэты ў 20%. І гэта будзе набліжаць нас да таго, што мы бачым у production.
А як мы зразумеем, што мы маем на production? Якая доля і чаго як? Тут крыху сыход у бок. У нас ёсць яшчэ адзін прадукт . Таксама база ў Open Source. І мы зараз актыўна яго развіваем.
Ён нарадзіўся крыху па іншых прычынах. Па прычынах таго, што маніторынгу недастаткова. Г. зн. вы прыходзьце, глядзіце на базу, глядзіце на праблемы, якія ёсць. І, як правіла, вы робіце health_check. Калі вы дасведчаны DBA, то вы робіце health_check. Паглядзелі выкарыстанне азначнікаў і т. д. Калі ў вас OKmeter, то выдатна. Гэта класны маніторынг для Postgres. OKmeter.io - калі ласка, стаўце яго, там вельмі класна ўсё зроблена. Ён платны.
Калі ў вас яго няма, то, як правіла, у вас мала што ёсць. У маніторынгу звычайна ёсць CPU, IO і тое з агаворкамі, і ўсё. А нам трэба болей. Нам трэба бачыць, як працуе аўтавакуум, як працуе checkpoint, у io трэба аддзяліць checkpoint ад bgwriter і ад бэкэндаў і г.д.
Праблема ў тым, калі ты дапамагаеш нейкай буйной кампаніі, яны не могуць нешта хутка ўкараніць. Не могуць хутка набыць OKmeter. Можа, праз паўгода купяць. Ня могуць хутка паставіць нейкія пакеты.
І ў нас нарадзілася ідэя, што нам патрэбен такі спецыяльны інструмент, які не патрабуе нічога ва ўстаноўцы, г.зн. вы наогул нічога не павінны ставіць на production. Ставіце сабе на наўтбук, альбо на observing server, адкуль вы будзеце запускаць. І ён будзе аналізаваць шмат чаго: і аперацыйную сістэму, і файлавую сістэму, і сам Postgres, робячы нейкія лёгкія запыты, якія можна ганяць прама на production і нічога не ляжа.
Мы назвалі яго Postgres-checkup. Калі па-медыцынскім, то гэта рэгулярная праверка здароўя. Калі ў аўтамабільнай тэматыцы, то гэта як ТО. Вы ТО робіце ў машыны кожныя паўгода ці год, у залежнасці ад маркі. А ці робіце вы ТО для сваёй базы? Т. е. ці робіце вы глыбокае даследаванне рэгулярна? Яго трэба рабіць. Калі вы робіце бэкапы, то рабіце і checkup, гэта не менш важна.
І ў нас ёсць такі інструмент. Ён пачаў актыўна зараджацца толькі месяцы тры таму. Ён яшчэ малады, але тамака шмат чаго ёсць.
Збіраем самыя «ўплывовыя» групы запытаў - справаздача К003 у Postgres-checkup
І там ёсць група справаздач К. Тры справаздачы пакуль. І ёсць такая справаздача К003. Там верхавіна ад pg_stat_statements, адсартаваная па total_time.
Калі мы сартуем па total_time групы запытаў, то на верхавіне мы бачым такую групу, якая грузіць нашу сістэму найвялікай выявай, т. е. спажывае большую колькасць рэсурсаў. Чаму я называю групы запытаў? Бо мы параметры выкінулі. Гэта ўжо не запыты, а групы запытаў, г.зн. яны абстрагаваныя.
І калі мы будзем аптымізаваць зверху ўніз, мы будзем аблягчаць нашы рэсурсы і адкладаць момант, калі нам будзе трэба рабіць апгрэйд. Гэта вельмі добры спосаб зэканоміць грошы.
Можа быць, гэта не вельмі добры спосаб у якасці клопату аб карыстальніках, таму што мы, можа быць, не бачым рэдкія, але вельмі прыкрыя выпадкі, калі чалавек чакаў 15 секунд. У суме яны такія рэдкія, што мы іх ня бачым, але затое мы рэсурсамі займаемся.
Што здарылася ў гэтай табліцы? Мы зрабілі два снапшоты. Postgres_checkup вам зробіць дэльту па кожнай метрыцы: па total-time, calls, rows, shared_blks_read і т. д. Усё, дэльту вылічыў. У pg_stat_statements вялікая праблема ў тым, што ен не памятае, калі быў reset. Калі pg_stat_database памятае, то pg_stat_statements не памятае. Вы бачыце, што там 1 лік, а адкуль мы лічылі, мы не ведаем.
А тут мы ведаем, тут у нас ёсць два снапшоты. Мы ведаем, што дэльта была ў дадзеным выпадку 56 секунд. Вельмі невялікі прамежак. Па total_time адсартавалі. І далей мы можам дыферэнцаваць, г. зн. мы ўсе метрыкі дзелім на duration. Калі мы кожную метрыку падзелім на duration, у нас будзе колькасць выклікаў у секунду.
Далей total_time per second - гэта мая любімая метрыка. Яна вымяраецца ў секундах, у секунду, т. е. колькі секунд спатрэбілася нашай сістэмы на выкананне гэтай групы запытаў у секунду. Калі вы бачыце там больш за секунду ў секунду, гэта азначае, што больш аднаго ядра вам трэба было даць. Гэта вельмі добрая метрыка. Вы можаце зразумець, што гэтаму таварышу, напрыклад, трэба мінімум тры ядры.
Вось гэта нашае ноў-хаў, я такога нідзе не бачыў. Звярніце ўвагу - гэта вельмі простая рэч - секунда ў секунду. Часам, калі ў вас CPU 100%, то паўгадзіны ў секунду, т. е. вы паўгадзіны займаліся толькі гэтым запытаў.
Далей мы бачым rows у секунду. Мы ведаем, колькі радкоў у секунду вярнула.
І далей таксама цікавая рэч. Колькі мы shared_buffers у секунду прачыталі з самага shared_buffers. Хіты ўжо былі там, а шэрагі мы ўзялі з кэша аперацыйнай сістэмы, альбо з дыска. Першы варыянт хуткі, а другі, можа быць, хуткім, а можа быць і не, ад сітуацыі залежыць.
І другі спосаб дыферэнцыявання - мы дзелім колькасць запытаў у гэтай групе. У другой калонцы ў вас заўсёды будзе адзін запыт падзяліць на запыт. А далей цікава - колькі мілісекунд было ў гэтым запыце. Мы ведаем, як у сярэднім паводзіць сябе гэты запыт. 101 мілісекунда патрабавалася на кожны запыт. Гэта традыцыйная метрыка, якая нам патрэбная для разумення.
Колькі радкоў кожны запыт вярнуў у сярэднім. Мы бачым 8 гэтая група вяртае. Колькі ў сярэднім з кэша ўзялося і прачыталася. Мы бачым, што ўсё закэшавана класна. Суцэльныя хіты для першай групы.
І чацвёрты падрадок у кожным радку - гэта колькі адсоткаў ад агульнай колькасці. У нас ёсць calls. Дапушчальны, у 1 000 000. І мы можам зразумець, які фундуш гэтая група ўносіць. Мы бачым, што ў дадзеным выпадку першая група робіць унёсак менш, чым 0,01 %. Т. е. яна такая павольная, што мы яе не бачым у агульнай карціне. А другая група - 5% па выкліках. Т. е. 5% з усіх выклікаў - гэта другая група.
Па total_time таксама цікава. На першую групу запытаў мы патрацілі 14% усяго часу працы. А на другую - 11% і г.д.
Я ў дэталі не буду паглыбляцца, але тамака ёсць тонкасці. Мы зверху выводзім памылку, таму што, калі мы параўноўваем, снапшоты могуць паплыць, г.зн. нейкія запыты могуць выпасці і ў другім ужо не могуць не прысутнічаць, а нейкія могуць новыя з'явіцца. І мы там вылічваем памылку. Калі вы бачыце 0, тое гэта добра. Гэта памылак няма. Калі паказчык памылкі да 20%, гэта ОК.
Далей мы вяртаемся да нашай тэмы. Мы павінны закрафціць workload. Мы бярэм зверху ўніз ідзём, пакуль не набярэм 80% ці 90%. Звычайна гэта 10-20 гуртоў. І які робіцца файлікі для pgbench. Тамака выкарыстоўваны random. Часам гэта, нажаль, не атрымліваецца. І ў Postgres 12 будзе больш магчымасцяў такі падыход выкарыстоўваць.
І далей мы такім чынам набіраем 80-90% па total_time. Што далей падстаўляць пасля "@"? Мы глядзім на calls, глядзім, колькі працэнтаў і разумеем, што мы вось тут павінны столькі-то працэнтаў. З гэтых працэнтаў мы можам зразумець, як балансаваць кожны з файлікаў. Пасля гэтага мы выкарыстоўваем pgbench і паехалі працаваць.
Ёсць яшчэ ў нас К001 і К002.
К001 - гэта адзін вялікі радок з чатырма падрадкамі. Гэта характарыстыка ўсёй нашай нагрузкі. Глядзіце другую калонку і другую падрадок. Мы бачым, што паўтары секунды ў секунду прыкладна, т. е. калі будзе два ядры, тое будзе добра. Будзе прыкладна 75% загрузка. І гэта будзе так працаваць. Калі ў нас будзе 10 ядраў, то мы ўвогуле будзем спакойныя. Так мы можам рэсурсы ацэньваць.
К002 - гэта я заву класы запытаў, т. е. SELECT, INSERT, UPDATE, DELETE. І асобна SELECT FOR UPDATE, таму што ён лочыць.
І тут мы можам зрабіць выснову, што SELECT звычайныя чытальнікі - 82% ад усіх выклікаў, але пры гэтым - 74% па total_time. Т. е. яны шмат выклікаюцца, але паменш спажываюць рэсурс.
І вяртаемся да пытання: "Як нам правільна падабраць shared_buffers?". Я назіраю, што большасць бенчмаркаў будуюцца на ідэі давайце паглядзім, які throughput будзе, т. е. якой будзе прапускная здольнасць. Яна ў TPS звычайна вымяраецца ці QPS.
І мы імкнемся выціснуць ад тачкі з дапамогай параметраў ад цюнінгу як мага больш транзакцый у секунду. Тут як раз 311 за секунду для select.
Але ніхто не ездзіць на працу і зваротна дадому на машыне на поўнай хуткасці. Гэта недарэчна. Так і з базамі даных. Мы не павінныя ездзіць на поўнай хуткасці, ды ніхто гэтага і не робіць. Ніхто не жыве ў production, які мае 100% CPU. Хаця, можа, нехта і жыве, але гэта нядобра.
Ідэя такая, што мы ездзім звычайна працэнтах на 20 ад магчымасці, пажадана не вышэй за 50%. І мы стараемся час водгуку аптымізаваць для нашых карыстальнікаў перш за ўсё. Т. е. мы павінны нашы ручкі круціць так, каб было мінімальнае latency пры 20%-ай хуткасці, умоўна. Гэта такая ідэя, якую мы таксама імкнемся выкарыстоўваць у нашых эксперыментах.
І ў завяршэнні рэкамендацыі:
- Абавязкова зрабіце Database Lab.
- Па магчымасці зрабіце on demand, каб разгортвалася на нейкі час - пагулялі і выкінулі. Калі ў вас аблокі, то гэта само сабой, т. е. майце шмат standing.
- Будзьце дапытлівымі. І калі нешта не так, то правярайце эксперыментамі, як яно сябе паводзіць. Nancy можна выкарыстоўваць, каб навучаць сябе, каб правяраць, як працуе база.
- І цэліцеся на мінімальны час водгуку.
- І не бойцеся зыходнікаў Postgres. Калі вы працуеце з зыходнікамі, вы павінны ведаць англійскую. Там вельмі шмат каментароў, там усё растлумачана.
- І правярайце здароўе базы рэгулярна, хаця б раз у тры месяцы рукамі, альбо Postgres-checkup.
пытанні
Дзякуй вялікі! Вельмі цікавая штука.
Дзве штукі.
Так, дзве штукі. Толькі я не зусім зразумеў. Калі мы з Nancy працуем, мы толькі адзін параметр можам падкручваць ці цэлую групу?
У нас дэльта-канфіг параметр. Вы можаце туды колькі заўгодна адразу крутнуць. Але трэба разумець, калі вы мяняеце шмат усяго, вы можаце няправільныя высновы зрабіць.
Так. Чаму я спытаў? Бо складана праводзіць эксперыменты, калі ў цябе ёсць толькі адзін параметр. Ты яго падкручваеш, паглядзеў, як працуе. Выставіў яго. Пасля наступны пачынаеш.
Можна адначасова падкручваць, але залежыць ад сітуацыі, канешне. Але лепш адну ідэю правяраць. У нас учора ўзнікла ідэя. У нас была вельмі блізкая сытуацыя. Было два канфігі. І мы не маглі зразумець, чаму вялікая розніца. І ўзнікла ідэя, што трэба выкарыстоўваць дыхатамію, каб паслядоўна зразумець і знайсці ў чым адрозненне. Можна адразу палову параметраў зрабіць аднолькавымі, потым чвэрць і т. д. Усё гнутка.
І яшчэ ёсць пытанне. Праект малады, развіваецца. Дакументацыя ўжо гатова, ёсць падрабязнае апісанне?
Я там спецыяльна спасылку зрабіў на апісанне параметраў. Гэта ёсьць. Але шмат чаго яшчэ няма. Я шукаю аднадумцаў. І я іх знаходжу, калі выступаю. Гэта вельмі крута. Нехта ўжо са мной працуе, нехта дапамог і нешта там зрабіў. І калі вам цікавая гэтая тэма, дайце зваротную сувязь - што не хапае.
Як зробім лабараторыю, магчыма, будзе зваротная сувязь. Пабачым. Дзякуй!
Добры дзень! Дзякуй за даклад! Я ўбачыў, што ёсць падтрымка Амазона. Ці плануецца падтрымка GSP?
Добрае пытанне. Пачалі рабіць. І пакуль замарозілі, бо мы хочам эканоміць. Т. е. ёсць падтрымка з дапамогай run on localhost. Вы можаце самі стварыць instance і працаваць лакальна. Дарэчы, так мы робім. У Getlab я так раблю, тамака на GSP. Але рабіць менавіта такую аркестрацыю мы пакуль не бачым сэнс, таму што ў Google няма спотаў танны. Там ёсць ??? instances, але ў іх абмежаванні. Па-першае, у іх заўсёды толькі зніжка ў 70% і там нельга пагуляць з коштам. Споты мы павялічваем на 5-10% кошт, каб панізіць верагоднасць, што вас кільнуць. Т. е. споты вы эканоміце, але ў вас могуць у любы момант забраць. Калі вы крыху цану вышэй, чым у іншых робіце, вы будзеце пазней забітыя. У Google зусім іншая спецыфіка. І яшчэ вельмі нядобрае абмежаванне ёсць - яны толькі 24 гадзіны жывуць. А часам мы жадаем 5 дзён ганяць эксперымент. Але спотах гэта рабіць можна, споты часам месяцамі жывуць.
Добры дзень! Дзякуй за даклад! Вы згадалі пра checkup. Як вы вылічваеце памылкі stat_statements?
Вельмі добрае пытаньне. Я магу вельмі падрабязна паказаць і расказаць. Коратка - мы глядзім, як паплыў набор груп запытаў: колькі адвалілася і колькі новых з'явілася. І далей мы глядзім дзве метрыкі: total_time і calls, таму тамака дзве памылкі. І глядзім, які фундуш у паплылых груп. Там дзве падгрупы: якая з'ехала і якая прыехала. Глядзім, які ў іх уклад у агульную карціну.
А вы не баіцеся, што яна там пракруціцца два-тры разы за час паміж снапшотамі?
Г. зн. яны зноўку зарэгістраваліся ці як?
Напрыклад, гэты запыт адзін раз ужо выцесніўся, потым прыйшоў і зноў выцесніўся, потым яшчэ раз прыйшоў і зноў выцесніўся. І вы тут нешта палічылі, і дзе гэта ўсё?
Добрае пытанне, трэба глядзець.
Я аналагічную штуку рабіў. Прасцей, вядома, я рабіў яе адзін. Але мне прыйшлося скідаць, зрабіць reset stat_statements і арыентавацца ў момант снапшота, што там менш вызначанай дзелі, што ўсё роўна не дайшло да столі, колькі там stat_statements можа назапасіць. І я арыентуюся, што, хутчэй за ўсё, не выцеснілася нічога.
Так.
Але як па-іншаму зрабіць дакладна я не разумею.
Я, нажаль, сапраўды не памятаю - ці выкарыстоўваем мы там тэкст запыту або queryid з pg_stat_statements і на яго арыентуемся. Калі мы арыентуемся на queryid, то па ідэі, мы параўноўваем параўнальныя рэчы.
Не, ён жа можа выцесніцца некалькі разоў паміж снапшотамі і прыехаць ізноў.
З гэтым жа ID?
Да.
Мы гэта вывучаем. Добрае пытанне. Трэба вывучыць. Але пакуль тое, што мы бачым, у нас альбо 0 пішацца…
Гэта, вядома, рэдкі выпадак, але мяне трасянула, калі я даведаўся, што stat_statemetns там можа выцесніць.
У Pg_stat_statements можа быць шмат чаго. Мы сутыкаліся з тым, што калі ў вас track_utility=on, то ў вас сэты таксама трэкаюцца.
Так, вядома.
І калі ў вас java hibernate, які рандомны, то там пачынаецца лачыцца хэш-табліца. І як толькі вы адключаеце вельмі нагружанае дадатак, у вас становіцца 50-100 груп. І там больш-менш стабільна ўсё. Адзін са спосабаў барацьбы з гэтым - гэта pg_stat_statements.max павялічыць.
Так, але трэба ведаць, наколькі. І неяк за ім трэба сачыць. Я так і раблю. Т. е. у мяне ёсць pg_stat_statements.max. І гляджу, што я на момант снапшота не дайшоў працэнтаў 70 %. Добра, значыцца, мы нічога не страцілі. Які робіцца reset. І збіраем зноў. Калі ў наступным снапшоце менш за 70, то значыць, хутчэй за ўсё, зноў нічога не страцілі.
Так. Па змаўчанні зараз 5 000. І вельмі шмат каму гэтага хапае.
Звычайна - так.
Відэа:
PS Ад сябе дадам што калі ў Postgres знаходзяцца канфедыцыйныя дадзеныя і ім нельга пападаць у тэставае асяроддзе, то можна скарыстацца . Схема прыкладна наступная:
Крыніца: habr.com