Расшыфроўка даклада 2015 года Іллі Касмадзям'янскага "Linux tuning to improve PostgreSQL performance"
Disclaimer: Заўважу, што даклад гэты датаваны лістападам 2015 года — прайшло больш за 4 гады і прайшло шмат часу. Версія 9.4, якая разглядаецца ў дакладзе, ужо не падтрымліваецца. За мінулыя 4 гады выйшла 5 новых рэлізаў PostgreSQL выйшла і 15 версій ядра Linux. Калі перапісваць гэтыя месцы, то атрымаецца ў выніку іншы даклад. Але тут разгледжаны фундаментальны цюнінг Linux для PostgreSQL, які актуальны і зараз.
Мяне клічуць Ілля Касмадзям'янскі. Я працую ў кампаніі PostgreSQL-Consulting. І цяпер буду распавядаць крыху пра тое, што рабіць з Linux у дачыненні да баз дадзеных наогул і да PostgreSQL у прыватнасці, таму што прынцыпы даволі падобныя.
Пра што пойдзе гаворка? Калі вы маеце зносіны з PostgreSQL, то да нейкай ступені трэба быць UNIX'авым адмінам. Што гэта значыць? Калі мы параўнаем Oracle і PostgreSQL, то ў Oracle трэба быць на 80% DBA адмінам базы дадзеных і на 20% адмінам Linux.
З PostgreSQL крыху цяжэй. З PostgreSQL трэба моцна лепш уяўляць сабе, як працуе Linux. І пры гэтым трошкі бегчы ўслед за паравозам, таму што ў апошні час даволі выдатна ўсё апдэйціцца. І новыя ядры выходзяць, і новы функцыянал з'яўляецца, перфоманс паляпшаецца і т. д.
Чаму мы гаворым пра Linux? Зусім не па тым, што мы на канферэнцыі Linux Піцер, а таму што ў сучасных умовах адна з самых апраўданых АС для эксплуатацыі з базамі дадзеных наогул і з PostgreSQL у прыватнасці - гэта Linux. Таму што FreeBSD, нажаль, развіваецца ў нейкім вельмі дзіўным кірунку. І будуць праблемы як з прадукцыйнасцю, так і з многімі іншымі рэчамі. Прадукцыйнасць PostgreSQL на Windows - гэта наогул асобная суровая тэма, якая ўпірае ў тое, што ў Windows няма такой шарэднай памяці як у UNIX, а ў PostgreSQL уся на гэтую справу завязана, таму што шматпрацэсная сістэма.
І экзотыка тыпу Solaris, я думаю, у меншай ступені ўсіх цікавіць, таму паехалі.
У сучаснага дыстрыбутыва Linux больш за 1 000 параметраў syctl, у залежнасці ад таго, як сабраць ядро. Пры гэтым, калі мы паглядзім яшчэ на розныя гайкі, то там можна яшчэ шматлікімі спосабамі што-небудзь падналаджваць. Ёсць параметры файлавых сістэм, як мантаваць. Калі пытанні, як запусціць: што ў BIOS ўключыць, як жалязякі наладзіць і г. д.
Гэта вельмі вялікі аб'ём, пра які можна распавядаць некалькі дзён, а не за адзін кароткі даклад, але я зараз спынюся на важных рэчах, як пазбегнуць тых грабляў, якія з гарантыяй не дадуць вам добра эксплуатаваць базу дадзеных на Linux, калі вы іх не паправіце . І пры гэтым важны такі момант, што многія параметры па дэфолце ўключаны не ў такія наладкі, якія правільныя для базы дадзеных. Т. е. па змаўчанні працаваць будзе дрэнна ці працаваць не будзе наогул.
Якія традыцыйныя tuning targets ёсць у Linux? Я думаю, што паколькі вы ўсё маеце справу з адміністраваннем Linux, тое што такое targets тлумачыць асоба не трэба.
Можна цюніць:
- ЦЭНТРАЛЬНЫ ПРАЦЭСАР.
- Памяць.
- Захоўванне.
- Other. Пра гэта мы пагаворым у канцы на закуску. Нават, напрыклад, такія параметры, як палітыка энергазберажэння могуць вельмі непрадказальным і не самай прыемнай выявай паўплываць на прадукцыйнасць.
Якая спецыфіка ў PostgreSQL і ў базы дадзеных увогуле? Праблема ў тым, што нельга пацюніць нейкую асобную гаечку і паглядзець, што прадукцыйнасць у нас моцна палепшылася.
Так, такія гаечкі ёсць, але база дадзеных - гэта рэч складаная. Яна ўзаемадзейнічае з усімі рэсурсамі, якія ёсць у сервера і аддае перавагу ўзаемадзейнічаць па поўнай. Калі вы паглядзіце на сучасныя рэкамендацыі Oracle па тым, як выкарыстоўваць хаставую АС, тое гэта будзе як у анекдоце пра таго мангольскага касманаўта - пакарміць сабаку і нічога не чапаць. Дамо базе ўсе рэсурсы, база дадзеных сама ўсё разруліць.
У прынцыпе, да некаторай ступені з PostgreSQL сапраўды такая ж сітуацыя. Розніца складаецца ў тым, што база яшчэ і не ўсе рэсурсы сама ўмее сабе забіраць, т. е. дзесьці трэба на ўзроўні Linux гэта ўсё разрульваць самастойна.
Асноўная ідэя - не выбраць нейкі адзінкавы target і пачаць яго цюніць, напрыклад, памяць, CPU ці нешта ў гэтым родзе, а прааналізаваць workload і паспрабаваць максімальна палепшыць прапускную здольнасць, каб праз нашу базу дадзеных максімальна эфектыўна праходзіла тая нагрузка, якую добрыя праграмісты нам стварылі, у тым ліку і нашы карыстачы.
Вось такі малюнак для тлумачэння таго, што гэта такое. Ёсць буфер АС Linux і ёсць шарэдная памяць і ёсць шарэдныя буфера PostgreSQL. PostgreSQL у адрозненне ад Oracle працуе непасрэдна толькі праз буфер ядра, т. е. каб старонка з кружэлкі патрапіла ў яго шарэдную памяць, яна павінна мінуць праз kernel buffer і зваротна сапраўды такая ж сітуацыя.
Пад гэтай сістэмай жывуць дыскі. Я гэта намаляваў як дыскі. Насамрэч там можа быць RAID-кантролер і г.д.
І вось гэты ўвод-вывад так ці інакш адбываецца праз гэтую справу.
PostgreSQL - гэта класічная база дадзеных. Там унутры старонкі. І ўвесь увод-вывад адбываецца пры дапамозе старонак. Мы старонкамі падымаем блокі ў памяць. І калі нічога не адбылося, мы іх проста прачыталі, то паступова яны з гэтага кэша, з шарэдных буфераў тонуць і пападаюць зваротна на дыск.
Калі мы недзе нешта замянілі, то ў нас уся старонка пазначаецца як брудная. Я іх тут сінім колерам зазначыў. І гэта значыць, што гэтая старонка павінна быць сінхранізаваная з блокавым сховішчам. Г. зн. мы, калі яе зрабілі бруднай, зрабілі запіс у WAL. І ў нейкі цудоўны момант часу прыйшла з'ява пад назвай checkpoint. І ў гэты лог запісалася інфармацыя аб тым, што ён прыйшоў. І гэта значыць, што ўсе брудныя старонкі, якія тут былі ў гэты момант у гэтых шарэдных буферах, яны сінхранізаваліся з дыскам сховішча з дапамогай fsync праз kernel buffer.
Навошта гэта робіцца? Калі ў нас прапала напруга, то мы не атрымалі сітуацыю, што ўсе дадзеныя зніклі. Персістэнтная памяць, пра якую нам усё расказвалі, гэта пакуль што ў тэорыі баз дадзеных – гэта светлая будучыня, да якой мы, вядома, імкнемся і яна нам падабаецца, але пакуль што яны жывуць яшчэ ў мінус 20 гадоў. І, канешне, за ўсім гэтым трэба сачыць.
І задача максімізацыі прапускной здольнасці - гэта пацюніць на ўсіх гэтых этапах, каб гэта ўсё ездзіла туды-сюды хутка. Шародная памяць - гэта ў асноўным старонкавы кэш. У PostgreSQL мы даслалі запыт select нешта там, ён дастаў гэтыя дадзеныя з дыска. Яны трапілі ў шарэдныя буферы. Адпаведна, каб гэта працавала лепш, мусіць быць шмат памяці.
Для таго каб гэта ўсё працавала добра і хутка, вам трэба правільна наладзіць на ўсіх этапах аперацыйную сістэму. І выбраць збалансавана жалеза, таму што калі ў вас у нейкім месцы будзе дысбаланс, тыя вы можаце зрабіць вельмі шмат памяці, але абслугоўвацца яна будзе з недастатковай хуткасцю.
І пройдземся па кожным з гэтых пунктаў.
Каб гэтыя старонкі падарожнічалі туды-сюды хутчэй, трэба дабіцца наступнага:
- Па-першае, трэба больш эфектыўна працаваць з памяццю.
- Па-другое, больш эфектыўным павінен быць вось гэты пераход, калі старонкі з памяці трапляюць на дыск.
- І, па-трэцяе, павінны быць добрыя кружэлкі.
Калі ў вас 512 GB аператыўнай памяці ў серверы і ўсё гэта ў фінале прыязджае на SATA цвёрдая кружэлка без усякага кэша, то ўвесь сервер базы дадзеных ператвараецца не проста ў гарбуз, а ў гарбуз з SATA інтэрфейсам. Вы будзеце ўпірацца ў гэта непасрэдна. І нічога вас не выратуе.
Што да першага пункта з памяццю, то ёсць тры рэчы, якія могуць моцна ўскладніць жыццё.
Першая з іх - гэта NUMA. NUMA - гэта рэч, якая зроблена для таго, каб палепшыць прадукцыйнасць. У залежнасці ад workload можна аптымізаваць розныя рэчы. І ў новым яе цяперашнім выглядзе яна для такіх прыкладанняў, як база дадзеных, якія выкарыстоўваюць інтэнсіўна page cache шарэднага буфера, не вельмі добрая.
У двух словах. Як зразумець, што з NUMA нешта не тое? У вас нейкі непрыемны стук, раптоўна які-небудзь CPU апыняецца перагружаны. Пры гэтым вы аналізуеце запыты ў PostgreSQL і бачыце, што нічога такога там падобнага няма. Гэтыя запыты не павінны настолькі інтэнсіўна спажываць CPU. Лавіць гэта можна доўга. Прасцей скарыстацца з самага пачатку правільнай рэкамендацыяй, як наладзіць NUMA для PostgreSQL.
Што насамрэч адбываецца? NUMA - гэта Non-Uniform Memory Access. Сэнс у чым? У вас ёсць CPU, з ім побач ёсць памяць яго лакальная. І гэтая памяць interconnects можа падцягваць памяць з іншых CPU.
Калі вы запусціце numactl --hardware, то вам выйдзе такая вялікая прасціна. Сярод іншага там будзе поле distances. Будуць цыферкі - 10-20, нешта ў гэтым родзе. Гэтыя цыферкі ні што іншае, як колькасць хопаў, каб гэтую выдаленую памяць падчапіць і выкарыстоўваць лакальна. У прынцыпе, добрая ідэя. Гэта добра паскарае прадукцыйнасць пры шэрагу нагрузак.
Цяпер уявіце, што ў вас адзін CPU спачатку спрабуе выкарыстоўваць сваю лакальную памяць, потым спрабуе падцягнуць па interconnect іншую памяць сабе для чаго-небудзь. І на гэты CPU трапляе ўвесь ваш page cache PostgreSQL - усё, колькі-то там гігабайт. Вы заўсёды атрымліваеце горшы выпадак, таму што на CPU непасрэдна ў гэтым модулі памяці звычайна мала. І уся памяць, якая абслугоўваецца, ходзіць праз гэтыя interconnects. Атрымліваецца марудна і сумна. І ў вас працэсар, які абслугоўвае гэты вузел, увесь час перагружаны. І час доступу гэтай памяці - дрэнны, павольны. Гэта тая сітуацыя, якую вы не хочаце, калі карыстаецеся гэтую справу для базы дадзеных.
Таму больш правільны варыянт для базы дадзеных, каб аперацыйная сістэма Linux увогуле не ведала, што там адбываецца. Каб яна звярталася да памяці, як звяртаецца.
Чаму так? Здавалася б, што мусіць быць наадварот. Гэта адбываецца па адной простай прычыне, што памяці нам трэба пад page cache шмат - дзясяткі, сотні гігабайт.
І калі мы гэта ўсё вылучылі і пракэшавалі нашы дадзеныя тамака, то выйгрыш ад выкарыстання кэша будзе істотна больш, чым выйгрыш ад такога хітрага звароту да памяці. І мы такім чынам выйграем не супастаўна ў параўнанні з тым, што мы будзем больш эфектыўна звяртацца да памяці з выкарыстаннем NUMA.
Таму падыходу тут два на дадзены момант, пакуль светлая будучыня не наступіла, і база дадзеных не ўмее сама разбірацца на якіх CPU яна працуе і адкуль ёй нешта трэба падцягнуць.
Таму правільны падыход - гэта наогул адключыць NUMA., напрыклад, пры перазагрузцы. У большасці выпадкаў выйгрышы бываюць на такія парадкі, што ўвогуле не ўзнікае пытання, як лепш.
Ёсць іншы варыянт. Мы ім часцей карыстаемся, чым першым, таму што, калі да нас прыходзіць на падтрымку кліент, то для яго перазагрузіць сервер - гэта цэлая справа. У яго там бізнэс круціцца. А праблемы з-за NUMA яны адчуваюць. Таму мы імкнемся адключыць меней інвазіўнымі спосабамі, чым reboot, але тут акуратней правярайце, што яна адключылася. Таму што, як паказвае досвед, што на бацькоўскі працэс PostgreSQL NUMA мы адключаем, гэта добра, але зусім не абавязкова, што гэта спрацуе. Трэба правяраць і глядзець, што яна сапраўды адключылася.
Ёсць добры пост Robert Haas. Гэта адзін з комітараў PostgreSQL. Адзін з ключавых распрацоўшчыкаў усіх нізкаўзроўневых трыбухоў. І калі па спасылках з гэтай пасады прайсціся, то там апісваецца некалькі каларытных гісторый пра тое, як людзям NUMA ускладняла жыццё. Паглядзіце, вывучыце чэк-ліст сісадмінскі, што трэба наладзіць на серверы для таго, каб у нас база дадзеных працавала добра. Вось гэтыя настройкі трэба запісаць і правяраць, таму што інакш будзе не вельмі добра.
Звяртаю ўвагу, што гэта датычыцца ўсіх настроек, пра якія я буду гаварыць. Але звычайна базы дадзеных збіраюць у рэжыме master-slave для адмоваўстойлівасці. Не забудзьцеся ўнесці гэтыя наладкі на slave, таму што ў адзін цудоўны момант у вас здарыцца аварыя, і вы пераключыцеся на slave, і ён стане майстрам.
У аварыйнай сітуацыі, калі ўсё вельмі дрэнна, у вас увесь час тэлефануе тэлефон і звяртаецца начальнік з вялікай палкай, вам будзе некалі думаць аб тым, каб праверыць. І вынікі могуць быць вельмі жаласнымі.
Наступны момант - гэта huge pages. Huge pages складана пратэставаць асобна, ды і сэнсу ў гэтым няма, хаця ёсць бенчмаркі, якія ўмеюць гэта рабіць. Яны лёгка наганяюцца.
У чым сэнс? У вас не вельмі дарагі сервер, у якім шмат аператыўнай памяці, напрыклад, больш за 30 GB. У вас не выкарыстоўваецца huge pages. Гэта значыць, што ў вас адназначна ёсць overhead па выкарыстанні памяці. І гэты overhead далёка не самы прыемны.
Чаму так? І што адбываецца? Аперацыйная сістэма дробнымі кавалачкамі вылучае памяць. Так зручна, так гістарычна склалася. І калі ўдавацца ў падрабязнасці, то АС павінна трансліраваць віртуальныя адрасы ў фізічныя. І гэта працэс не самы просты, таму АС вынік гэтай аперацыі кэшуецца ў Translation Lookaside Buffer (TLB).
І паколькі TLB - гэта кэш, то ў такой сітуацыі ўзнікаюць усе ўласцівыя кэшу праблемы. Па-першае, калі ў вас вельмі шмат аператыўнай памяці і яна ўся выдзелена дробнымі chunks, то гэты буфер становіцца вельмі вялікім. А калі кэш вялікі, то па ім шукаць павольней. Overhead здаровы і ён сам займае месца, т. е. аператыўную памяць спажывае нешта нешта няправільнае. Гэта раз.
Два - чым больш разрастаецца кэш у такой сітуацыі, тым большая верагоднасць таго, што ў вас будзе cache misses. І эфектыўнасць гэтага кэша хутка падае з ростам яго памеру. Таму ў аперацыйных сістэмах прыдумалі просты падыход. У Linux ён даўно ўжо выкарыстоўваецца. У FreeBSD нядаўна з'явіўся. Але мы гаворым аб Linux. Гэта huge pages.
І тут трэба адзначыць, што huge pages, як ідэя, першапачаткова была праціснута супольнасцямі, якія ўключалі ў сябе Oracle і IBM, т. е. вытворцы баз дадзеных дужа думалі аб тым, што гэта спатрэбіцца, для баз дадзеных у тым ліку.
І як гэта пасябраваць з PostgreSQL? Па-першае, у лінуксавым ядры павінны быць уключаны huge pages.
Па-другое, яны павінны быць у відавочным выглядзе паказаны sysctl параметрам - колькі іх. Лічбы тут з нейкага старога сервера. Вы можаце палічыць, колькі прыкладна ў вас shared buffers, каб huge pages туды залазілі.
І калі ў вас увесь сервер аддадзены пад PostgreSQL, то добрая адпраўная кропка - гэта або 25% аператыўнай памяці аддаць пад шарэдныя буфера, або 75%, калі вы ўпэўненыя, што ў гэтыя 75% ваша база дадзеных сапраўды змесціцца. Адпраўным пункт першая. І лічыце, калі ў вас 256 GB аператыўнай памяці, то, адпаведна, 64 GB у вас будзе шэрдных буфераў. Палічыце прыкладна з некаторым запасам - у што ў вас павінна быць выстаўлена гэтая лічба.
Да версіі 9.2 (калі не памыляюся, з версіі 8.2) можна было з дапамогай іншай бібліятэкі пасябраваць PostgreSQL з huge pages. А гэта заўжды трэба рабіць. Па-першае, вам трэба, каб ядро ўмела вылучаць huge pages правільна. А, па-другое, каб прыкладанне, якое з імі працуе, магло імі скарыстацца. Проста так яно не скарыстаецца. Паколькі PostgreSQL вылучаў памяць у стылі system 5, то гэта можна было зрабіць з дапамогай libhugetlbfs – гэта поўная назва бібліятэкі.
У 9.3 палепшылі прадукцыйнасць PostgreSQL пры працы з памяццю і адмовіліся ад system 5 метаду вылучэння памяці. Усе вельмі ўзрадаваліся, таму што інакш спрабуеш запусціць 9.3 instances PostgreSQL на адной машыне, а ён кажа, што ў мяне шалёнай памяці бракуе. І кажа, што трэба выправіць sysctl. А тамака такі sysctl, што трэба яшчэ перазагрузіцца і т. д. Увогуле, усё ўзрадаваліся. Але вылучэнне памяці mmap зламала выкарыстанне huge pages. У нас большасць кліентаў выкарыстоўваюць вялікія shared buffers. І мы настойліва раілі не пераходзіць на XNUMX, таму што там overhead пачынаўся ў добрых працэнтах вылічацца.
Але затое community звярнула ўвагу на гэтую праблему і ў 9.4 вельмі добрае перапрацавалі гэтае мерапрыемства. І ў 9.4 з'явіўся параметр у postgresql.conf, у якім можна ўключыць try, on ці off.
Try - найбольш бяспечны параметр. Пры старце PostgreSQL, калі ён вылучае шарэдную памяць, ён спрабуе адхапіць сабе з huge pages гэтую памяць. І калі не атрымліваецца, тое адкочваецца на звычайнае вылучэнне. І калі ў вас FreeBSD ці Solaris, тыя вы можаце паставіць try, гэта заўсёды бяспечна.
Калі on, то ён проста не стартуе, калі не здолеў вылучыць з huge pages. Тут ужо - каму і што больш міла. Але калі ў вас стаіць try, то правярайце, што ў вас сапраўды тое, што трэба вылучылася, таму што прастор для памылкі там шмат. Цяпер гэты функцыянал працуе толькі на Linux.
Яшчэ адна маленькая заўвага, перад тым, як пойдзем далей. Transparent huge pages - гэта не пра PostgreSQL пакуль што. Скарыстацца імі па нармальным ён не можа. І пры Transparent huge pages для такога workload, калі патрэбен вялікі кавалак шародной памяці, плюсы наступаюць толькі пры вельмі вялікіх аб'ёмах. Калі ў вас тэрабайты памяці, тады гэта можа гуляць ролю. Калі мы гаворым аб больш жыццёвых прымяненнях, калі ў вас 32, 64, 128, 256 GB памяці на машыне, то звычайны huge pages - гэта Ok, а Transparent проста адключаем.
І апошняя рэч, якая тычыцца памяці, непасрэдна не звязана з фрупутам, яна можа вельмі моцна сапсаваць жыццё. Уся прапускная здольнасць моцна папакутуе ад таго, што сервер увесь час ухапіцца.
І гэта будзе вельмі непрыемна ў шэрагу момантаў. І асноўная непрыемнасць складаецца ў тым, што ў сучасных ядрах трошкі адрозніваюцца паводзіны з больш старымі ядрамі Linux. І гэтая рэч, на якую наступаць даволі непрыемна, таму што, калі мы гаворым пра нейкую працу са swap'ам, заканчваецца гэта не своечасовым прыходам OOM-killer. І OOM-killer, які не своечасова прыйшоў і скінуў PostgreSQL, гэта непрыемна. Пра гэта даведаюцца ўсе, г. зн. да апошняга карыстальніка.
Што адбываецца? У вас тамака вялікая колькасць аператыўнай памяці, усё добра працуе. Але чамусьці сервер вісіць у swap'е і тармозіць з-за гэтага. Здавалася б, памяці многа, але так адбываецца.
Раней мы раілі vm.swappiness ставіць у нуль, г. зн. адключаць swap. Раней здавалася, што 32 GB аператыўнай памяці і шарэдныя буфера адпаведныя - гэта велізарная колькасць. Асноўнае прызначэнне swap'а, каб было месца, куды кінуць скарынку, калі мы адваліліся. І яно ўжо не асоба выконвалася. І што потым з гэтай скарынкай будзеш рабіць? Гэта ўжо такая задача, калі не вельмі зразумела, навошта swap патрэбен, тым больш такога памеру.
Але ў больш сучасных, т. е. у трэціх версіях ядра паводзіны змяніліся. І калі выставіць swap у нуль, т. е. выключыць, то рана ці позна нават пры астатку нейкай аператыўнай памяці да вас будзе прыходзіць OOM-killer, каб забіваць найболей інтэнсіўных спажыўцоў. Таму што ён будзе лічыць, што пры такім workload нам засталося яшчэ крышку і мы выскачам, т. е. не сістэмны працэс прыбіваць, а прыбіць нешта меней важнае. Гэтым меней важным апынецца інтэнсіўны спажывец шародной памяці, а менавіта postmaster. І пасля гэтага будзе добра, калі базу не давядзецца аднаўляць.
Таму зараз дэфолтна, наколькі я памятаю, большасць дыстрыбутываў - гэта дзесьці 6, т. е. у які момант пачынаць выкарыстоўваць swap у залежнасці ад таго, колькі памяці засталося. Мы зараз раім ставіць vm.swappiness = 1, таму што гэта практычна яго выключае, але не дае такіх эфектаў, як з нечакана прыйшэлым OOM-killer'ам і ўся гэтая справа які прыбіў.
Што далей? Калі мы гаворым пра перформанс баз дадзеных і паступова-паступова паходзім да дыскаў, усё пачынаюць хапацца за галаву. Таму што ісціна аб тым, што дыск павольны і памяць хуткая, яна ўсім з дзяцінства знаёмая. І ўсе ведаюць, што ў базе даных будуць праблемы з дыскавай прадукцыйнасцю.
Асноўная праблема з прадукцыйнасцю PostgreSQL, злучаная з checkpoints spikes, з'яўляецца не з-за таго, што дыск павольны. Гэта, хутчэй, ад таго, што прапускная здольнасць памяці і дыска не збалансаваны. Пры гэтым яны могуць быць не збалансаваны ў розных месцах. PostgreSQL не настроены, АС не настроена, жалеза не настроена і жалеза няправільнае. І гэтай праблемы не здараецца толькі ў тым выпадку, калі ўсё адбываецца як трэба, т. е. альбо нагрузкі няма, альбо налады і жалеза добра падабраныя.
Што гэта такое і як гэта выглядае? Звычайна людзі, якія з PostgreSQL працуюць у гэтую справу ўступалі неаднаразова. Я растлумачу. Як я казаў, PostgreSQL перыядычна робіць checkpoints, каб брудныя старонкі ў шалёнай памяці здампіць на дыск. Калі ў нас вялікі аб'ём шарэднай памяці, то checkpoint пачынае інтэнсіўна ўздзейнічаць на дыск, таму што дампіць гэтыя старонкі fsync. Ён прыязджае ў kernel buffer і пішацца на дыскі з дапамогай fsync. І калі аб'ём гэтай справы вялікі, то мы можам назіраць непрыемны эфект, а менавіта вельмі вялікую ўтылізацыю дыскаў.
Тут у мяне ёсць дзве карцінкі. Я зараз растлумачу, што гэта такое. Гэта два з карэлявалі па часе графіка. Першы графік - гэта дыскавая ўтылізацыя. Тут яна даходзіць амаль да 90% у гэты момант часу. Калі ў вас выпад базы дадзеных з фізічнымі дыскамі, з RAID-кантролерам утылізацыя пад 90%, тое гэта дрэнныя навіны. Гэта значыць, што яшчэ ледзь-ледзь і наступіць 100 і ўвод-вывад спыніцца.
Калі ў вас дыскавы масіў, то там іншая крыху гісторыя. Там залежыць ад таго, як ён настроены, што за масіў і г.д.
А паралельна тут сканфігураваны графік з унутранай postgres'авай завірухі, якая кажа, як адбываецца checkpoint. І зялёным колерам тут паказана, якая колькасць буфераў, гэтых брудных старонак у гэты момант прыехала ў гэтым checkpoint для сінхранізацыі. І гэта галоўнае, што тут трэба ведаць. Мы бачым, што ў нас тут шмат старонак прыехала і ў нейкі момант мы ўперліся ў поплатак, т. е. пісалі-пісалі, тут відавочна дыскавая сістэма вельмі моцна занятая. І ў нас checkpoint вельмі моцна ўздзейнічае на кружэлку. У ідэале сітуацыя павінна выглядаць, хутчэй, вось так, г. зн. у нас тут было менш запісу. І мы настройкамі можам гэта паправіць, каб далей так было. Т. е. утылізацыя невялікая, але дзесьці нешта мы тут пішам.
Што трэба зрабіць, каб гэтую праблему перамагчы? Калі ў вас спынілася IO пад базай дадзеных, тое гэта значыць, што ўсе карыстачы, якія дашлі выконваць свае запыты, будуць чакаць.
Калі паглядзець з пункта гледжання Linux, калі вы ўзялі добры hardware, правільна яго наладзілі, нармальна наладзілі PostgreSQL, каб ён радзей рабіў гэтыя checkpoints, размазваў іх па часе сябар паміж сябрам, тыя вы надыходзіцье ў дэфолтныя параметры Debian. Для большасці дыстрыбутываў Linux вось такая карціна: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Што гэта значыць? З ядра 2.6 з'явіўся адзін demon flushing'а. Pdglush у залежнасці ад таго, хто які выкарыстоўвае, які займаецца background'ным скідваннем брудных старонак з kernel buffer і скідваннем, калі трэба ў што б не стала скідваць брудныя старонкі, калі ўжо backgrouind'нае скідванне не дапамагае.
Калі надыходзіць background? Калі 10% ад усёй аператыўнай памяці, якая ёсць на серверы, занята бруднымі старонкамі ў kernel buffer, то выклікаецца спецыяльная функцыя спісвання ў background'е. Чаму яна background'ная? Яна ў якасці параметру прымае ў сябе, колькі старонак спісаць. І, дапусцім, спісвае N старонак. І на нейкі час гэтая штука засынае. І потым яна зноў прыходзіць і спісвае яшчэ нейкую колькасць старонак.
Гэта вельмі простая гісторыя. Тут задача як з басейнам, калі ў адну трубу выліваецца, у іншую ўліваецца. У нас checkpoint прыйшоў і калі ён мала брудных старонак адправіў на скідванне, то паступова з kernel buffer pgflush гэта ўся справа акуратна разыдзецца.
Калі працягваюць назапашвацца гэтыя брудныя старонкі, яны назапашваюцца да 20%, пасля гэтага ў прыярытэце АС усю гэтую справу спісаць на дыск, таму што вылеціць сілкаванне, і ў нас усё будзе дрэнна. Мы страцім гэтыя дадзеныя, напрыклад.
У чым трук? Трук складаецца ў тым, што вось гэтыя параметры ў сучасным свеце 20 і 10% ад усёй аператыўнай памяці, якая ёсць на машыне, яны зусім жахлівыя пункты гледжання прапускной здольнасці любой дыскавай сістэмы, якая ў вас ёсць.
Уявіце сабе, што ў вас 128 Гб аператыўнай памяці. 12,8 GB прыязджаюць у вас у дыскавую сістэму. І які б кэш у вас тамака не стаяў, які б масіў у вас тамака не стаяў, яны не вытрымаюць гэтулькі.
Таму мы рэкамендуем гэтыя лічбы адразу наладжваць ад магчымасці вашага RAID-кантролера. У мяне адразу тут дадзена рэкамендацыя для кантролера, у якога 512 MB кэша.
Лічыцца ўсё вельмі проста. Можна vm.dirty_background у байтах паставіць. І гэтыя налады адмяняюць папярэднія дзве. Або ratio па дэфолце, альбо актываваныя тыя, якія з байтамі, то будуць працаваць тыя, якія з байтамі. Але паколькі я DBA-кансультант і працую з рознымі кліентамі, я імкнуся слаць саломкі і таму, калі ў байтах, то ў байтах. Ніхто не даў ніякай гарантыі, што добры адмін не падсыпле памяці серверу, не перазагрузіць яго, а лічба застанецца той жа. Проста разлічвайце гэтыя лічбы, каб з гарантыяй усё туды ўлезла.
Што адбудзецца, калі вы не ўлезеце? У мяне напісана, што эфектыўна спыняецца любы flushing, але на самой справе гэта фігура гаворкі. Аперацыйная сістэма мае вялікую праблему - у яе шмат брудных старонак, таму спыняецца эфектыўна той IO, якія спараджаюць вашы кліенты, т. е. прыйшло прыкладанне sql-запыт адправіць да базы, яно чакае. Любы ўвод-вывад у яе - у самым найнізкім прыярытэце, таму што база занятая checkpoint. І калі яна яго скончыць зусім незразумела. І калі вы дасягнулі не фонавага, не бэкграўнднага flushing'а, то гэта значыць, што ў вас усё IO занята ім. І пакуль яно не скончыцца, вы нічога не зробіце.
Тут ёсць яшчэ два важныя моманты, якія выходзяць за рамкі гэтага даклада. Вось гэтым наладам павінны матчыцца налады ў postgresql.conf, т. е. налады checkpoints. І ваша дыскавая сістэма павінна быць адэкватна настроена. Калі ў вас ёсць кэш на RAID, то на ім павінна быць батарэйка. Людзі купляюць RAID з добрым кэшам без батарэйкі. Калі ў вас SSD у RAID'ом, то яны павінны быць сервернымі, тамака павінны быць кандэнсатары. Тут разгорнуты чэк-ліст. Па вось гэтай спасылцы ёсць мой даклад пра тое, як наладжваць дыск перфоманс у PostgreSQL. Там усе гэтыя чэк-лісты ёсць.
Што яшчэ вельмі можа ўскладніць жыццё? Гэта два параметры. Яны адносна новыя. Яны па дэфолце могуць быць уключаны ў розныя прыкладанні. І яны могуць ускладніць жыццё ані не менш, калі яны будуць уключаны няправільна.
Ёсць дзве адносна новыя штукі. Яны ўжо ў трэціх ядрах з'явіліся. Гэта sched_migration_cost у нанасекундах і sched_autogroup_enabled, які па дэфолце адзін.
І як яны псуюць жыццё? Што такое sched_migration_cost? У Linux scheduler можа зміграваць працэс з аднаго CPU на іншы. І для PostgreSQL, які выконвае запыты, міграцыя на іншы CPU зусім не зразумела навошта. З пункту гледжання аперацыйнай сістэмы, калі вы перамыкаеце вокны паміж openoffice і тэрміналам, то гэта, можа быць, добра, але для базы дадзеных - гэта вельмі дрэнна. Таму разумная палітыка - паставіць migration_cost у нейкае вялікае значэнне, хаця б некалькі тысяч нанасекунд.
Што гэта будзе азначаць для scheduler? Будзе лічыць, што цягам гэтага часу гэты працэс усё яшчэ гарачы. Т. е. калі ў вас нейкая доўгая транзакцыя чым-небудзь доўга займаецца, што scheduler будзе гэта разумець. Ён будзе лічыць, што пакуль не пройдзе гэты тайм-аўт, то міграваць гэты працэс нікуды не трэба. Калі пры гэтым працэс нешта робіць, то ён не будзе нікуды зміграваны, ён спакойна дапрацуе на тым CPU, які яму вылучылі. І вынік атрымліваецца выдатны.
Другі момант гэта autogroup. Ёсць добрая ідэя для спецыфічных workload, якія не маюць дачынення да сучасных баз дадзеных – гэта групаваць працэсы па тым віртуальным тэрмінале, з-пад якога яны запушчаныя. Гэта зручна для нейкіх задач. На практыцы PostgreSQL - гэта шматпрацэсная сістэма з prefork'ом, якая запускаецца з аднаго тэрмінала. У вас lock writer, checkpoint і ўсе вашыя кліенцкія запыты згрупуюцца на адзін scheduler, на адзін CPU. І будуць там дружна чакаць, калі ён вызваліцца, каб перашкодзіць адзін аднаму і пазаймаць яго даўжэй. Гэта гісторыя, якая зусім не патрэбная ў выпадку такой нагрузкі і таму гэта трэба выключаць.
Мой калега Аляксей Лясоўскі рабіў тэсты з простым pgbench'ам, дзе павялічваў на парадак migration_cost і выключаў autogroup. Розніца на дрэннай жалязяцы атрымалася амаль на 10%. Ёсць абмеркаванне ў postgres'авай рассылцы, дзе людзі прыводзяць вынікі, як падобныя змены на хуткасць запыту уплывалі на 50%. Такіх гісторый даволі шмат.
І напрыканцы пра power saving policy. Добра, што зараз Linux можна выкарыстоўваць на наўтбуку. І ён будзе нібыта добра расходаваць батарэйку. Але раптоўна аказваецца, што на серверы такое таксама можа быць.
Больш за тое, калі вы бераце сервера ў арэнду ў якога-небудзь хосцера, то «добрыя» хосцеры не клапоцяцца аб тым, каб у вас была прадукцыйнасць лепей. Іх задача зрабіць так, каб у іх жалеза утылізавалася максімальна эфектыўна. Таму яны па змаўчанні могуць на аперацыйнай сістэме ўключыць наўтбучны рэжым эканоміі энергіі.
Калі вы карыстаецеся на серверы з базай дадзеных пад інтэнсіўнай нагрузкай вось гэта дабро, то ваш выбар - гэта acpi_cpufreq + permormance. Нават з ondemand'ам ужо будуць праблемы.
Intel_pstate – ужо крыху іншы драйвер. І зараз перавага аддаецца вось гэтаму, як да пазнейшага і больш добра працуючаму.
І, адпаведна, governor толькі performance. Ondemand, powersave і ўсё іншае - гэта не пра вас.
Вынікі па explain analyze PostgreSQL могуць адрознівацца на некалькі парадкаў, калі вы ўключыце powersave, таму што практычна ў вас пад базай будзе шадуліцца CPU зусім непрадказальным спосабам.
Гэтыя рэчы могуць быць уключаны па дэфолце. Уважліва паглядзіце - ці не ўключылі яны па дэфолце. Гэта можа быць сапраўды вялікай праблемай.
І ў канцы я хацеў сказаць дзякуй хлопцам з нашай DBA-каманды PosgreSQL-Consulting, а менавіта Максу Богуку і Аляксею Лясоўскаму, якія кожны дзень набіваюць на гэтай справе шышкі. І для нашых кліентаў мы спрабуем зрабіць максімальна добра, каб у іх гэта ўсё працавала. Тут як з інструкцыямі па авіяцыйнай бяспецы. Тут усё напісана крывёй. Кожная з гэтых гаек выяўлена ў працэсе нейкай праблемы. Я з радасцю імі з вамі дзялюся.
пытанні:
Дзякуй! Калі, напрыклад, кампанія хоча зэканоміць і размяшчаць на адным серверы базу дадзеных і application логіку ці, калі кампанія варта моднай тэндэнцыі мікрасэрвісных архітэктур, у якіх PostgreSQL запускаецца ў кантэйнеры. У чым фішка? Sysctl глабальна на ўсе ядро афектаць. Я не чуў, каб sysctl неяк віртуалізаваліся, каб яны на кантэйнеры паасобку працавалі. Ёсць толькі cgroup, і там толькі на частку ёсць кантроль. Як гэта з гэтым можна жыць? Ці калі жадаеце performance, то запускайце PostgreSQL на асобным жалезным серверы і яго цюньце?
Мы адказалі на вашае пытанне прыкладна трыма спосабамі. Калі гаворка ідзе не аб жалезным серверы, які можна цюніць і т. д., то паслабцеся, усё будзе добра без гэтых налад працаваць. Калі ў вас узнікае такая нагрузка, што трэба рабіць вось гэтыя налады, то да жалезнага сервера вы прыйдзеце раней, чым да гэтых налад.
У чым праблема? Калі гэта віртуалка, то, хутчэй за ўсё, у вас будзе шмат праблем, напрыклад, з тым, што на большасці віртуалак дастаткова некансістэнтная latency дыска. Нават калі прапускная здольнасць дыскаў добрая, то адна якая забілася транзакцыя аперацыі ўводу-высновы, не моцна што ўплывае на сярэднюю прапускную здольнасць, якая здарылася ў момант checkpoint або ў момант запісу ў WAL, то база ад гэтага будзе моцна пакутаваць. І вы гэта заўважыце раней, чым у гэтыя праблемы ўпрэцеся.
Калі ў вас будзе NGINX на тым жа самым сэрвэры, то таксама будзе тая ж самая праблема. Ён будзе біцца за шарэдную памяць. І да тых праблем, якія тут апісаны, вы не дойдзеце.
Але з іншага боку, некаторыя з гэтых параметраў усё роўна вам будуць актуальныя. Напрыклад, з sysctl паставіць dirty_ratio, каб быў не такі шалёны - у любым выпадку гэта дапаможа. Так ці інакш у вас узаемадзеянне з дыскам будзе. І яно будзе па няправільнай схеме. Гэта ўвогуле дэфолт тыя параметры, якія я паказваў. І ў любым выпадку іх лепш памяняць.
А з NUMA могуць быць праблемы. VmWare, напрыклад, добра працуе з NUMA з роўна супрацьлеглымі наладамі. І тут трэба выбіраць - жалезны сервер ці не жалезны.
У мяне пытанне, звязанае з Amazon AWS. У іх ёсць image праднастроеныя. Адзін з іх Amazon RDS называецца. Ці ёсць там нейкія кастамныя наладкі для іх аперацыйнай сістэмы?
Там ёсць наладкі, але гэта іншыя наладкі. Тут мы наладжваем аперацыйную сістэму з пункта гледжання таго, як база дадзеных будзе гэтую справу выкарыстоўваць. А там ёсць параметры, якія вызначаюць, куды ісці нам зараз, вось такі shaping. Г. зн. нам трэба столькі рэсурсаў, мы іх зараз будзем едаць. Пасля гэтага Amazon RDS гэтыя рэсурсы прыкручвае, і там прадукцыйнасць падае. Ёсць асобныя гісторыі, як людзі пачынаюць з гэтай справай хімічыць. Часам нават даволі пасьпяхова. Але гэта не мае дачыненне да налад АС. Гэта як бы хакінг аблокі. Гэта іншая гісторыя.
Чаму Transparent huge pages не даюць эфекту ў параўнанні з Huge TLB?
Не даюць. Растлумачыць гэта можна шматлікімі спосабамі. Але па факце яны проста не даюць яго. Якая гісторыя ў PostgreSQL? Ён пры старце вылучае вялікі кавалак шароднай памяці. Transparent яны пры гэтым ці не transparent - зусім не важна. Той факт, што яны выдзяляюцца на старце, ён тлумачыць усё. І калі памяці вельмі шмат і трэба перабудоўваць shared_memory segment, тады Transparent huge pages будзе актуальны. У PostgreSQL ён проста на старце выдзелены вялізным кавалкам і ўсё, і далей там нічога такога асаблівага не адбываецца. Можна, вядома, выкарыстоўваць, але ёсць шанец атрымаць curruption shared_memory, калі ён будзе перавылучаць што-небудзь. PostgreSQL ж пра гэта не ведае.
Крыніца: habr.com