Илья Космодемьянскийдин 2015-жылдагы отчетунун стенограммасы "PostgreSQL иштешин жакшыртуу үчүн Linuxту тюнинг"
Жоопкерчиликтен баш тартуу: Бул отчет 2015-жылдын ноябрында экенин белгилеймин - 4 жылдан ашык убакыт өттү жана көп убакыт өттү. Баяндамада талкууланган 9.4 версиясы мындан ары колдоого алынбайт. Акыркы 4 жылдын ичинде PostgreSQLдин 5 жаңы релиздери жана Linux ядросунун 15 версиясы чыгарылды. Эгер сиз бул үзүндүлөрдү кайра жазсаңыз, сиз башка отчетко ээ болосуз. Бирок бул жерде биз PostgreSQL үчүн фундаменталдуу Linux тюнингди карап чыгабыз, ал бүгүнкү күндө дагы актуалдуу.
Менин атым Илья Космодемьянский. Мен PostgreSQL-Consulting компаниясында иштейм. Эми мен Linux менен жалпы маалымат базаларына жана атап айтканда PostgreSQLге карата эмне кылуу керектиги жөнүндө бир аз сүйлөшөм, анткени принциптер абдан окшош.
Эмне жөнүндө сүйлөшөбүз? Эгер сиз PostgreSQL менен байланышсаңыз, анда кандайдыр бир деңгээлде сиз UNIX администратору болушуңуз керек. Бул эмнени билдирет? Эгерде биз Oracle менен PostgreSQLди салыштырсак, анда Oracleде сиз 80% DBA маалымат базасынын администратору жана 20% Linux администратору болушуңуз керек.
PostgreSQL менен бул бир аз татаалыраак. PostgreSQL менен сиз Linux кантип иштээрин жакшыраак түшүнүшүңүз керек. Жана ошол эле учурда, локомотивдин артынан бир аз чуркагыла, анткени акыркы убакта баары жакшынакай жаңыланды. Жана жаңы ядролор чыгарылып, жаңы функциялар пайда болот, аткаруу жакшырат ж.б.
Эмне үчүн биз Linux жөнүндө сөз кылып жатабыз? Биз Петирдин Linux конференциясында болгонубуз үчүн эмес, бирок азыркы шарттарда жалпысынан маалымат базаларын жана өзгөчө PostgreSQLди колдонуу үчүн эң негиздүү операциялык системалардын бири Linux болуп саналат. Анткени FreeBSD, тилекке каршы, кандайдыр бир кызыктай багытта өнүгүп жатат. Жана аткаруу менен да, башка көптөгөн нерселер менен да көйгөйлөр болот. Windows'та PostgreSQLдин иштеши жалпысынан өзүнчө олуттуу маселе, анын негизинде Windowsтун UNIX сыяктуу жалпы эс тутуму жок, ал эми PostgreSQL бардыгы ушуга байланыштуу, анткени ал көп процесстүү система.
Анан менимче, бардыгы Solaris сыяктуу экзотикага азыраак кызыгышат, андыктан кетели.
Заманбап Linux дистрибуциясында ядрону кантип курганыңызга жараша 1ден ашык syctl варианттары бар. Ошол эле учурда, эгерде биз ар кандай жаңгактарды карасак, биз бир нерсени ар кандай жолдор менен тууралай алабыз. Аларды кантип орнотуу керектиги боюнча файл тутумунун параметрлери бар. Аны кантип баштоо керектиги жөнүндө суроолоруңуз болсо: BIOS'та эмнени иштетүү керек, аппараттык камсыздоону кантип конфигурациялоо керек ж.б.у.с.
Бул абдан чоң көлөм, аны бир нече күн бою талкуулоого болот, бирок бир кыска баяндамада эмес, бирок азыр мен маанилүү нерселерге токтолом, эгерде сиз Linux'та базаңызды жакшы колдонууга жол бербөө үчүн кепилденген тырмоолорду кантип болтурбоо керек. аларды оңдобо. Ошол эле учурда, маанилүү жагдай - көптөгөн демейки параметрлер маалымат базасына туура келген орнотууларга кирбейт. Башкача айтканда, демейки боюнча ал начар иштейт же такыр иштебейт.
Linux'та кандай салттуу тюнинг максаттары бар? Менимче, баарыңар Linux башкаруусу менен алектенип жаткандыктан, максаттар эмне экенин түшүндүрүүнүн өзгөчө кереги жок.
Сиз күүлөй аласыз:
- CPU'лар.
- Эстутум.
- Сактоо.
- Башка. Бул тууралуу акырында закуска үчүн сүйлөшөбүз. Ал тургай, мисалы, энергия үнөмдөө саясаты сыяктуу параметрлери абдан күтүлбөгөн жана абдан жагымдуу жол менен аткарууга таасир этиши мүмкүн.
PostgreSQL жана жалпысынан маалымат базасынын өзгөчөлүктөрү кандай? Көйгөй сиз жеке гайканы чыңдап, биздин көрсөткүчтөр кыйла жакшырганын көрө албайсыз.
Ооба, мындай гаджеттер бар, бирок маалымат базасы татаал нерсе. Ал серверде болгон бардык ресурстар менен өз ара аракеттенет жана толук кандуу иштешүүнү артык көрөт. Эгерде сиз Oracle компаниясынын хост OS кантип колдонуу боюнча сунуштарын карасаңыз, анда ал ошол монгол космонавты жөнүндөгү тамашага окшош болот - итке тамак бериңиз жана эч нерсеге тийбеңиз. Келгиле, базага бардык ресурстарды берели, база өзү баарын иреттейт.
Негизи, кандайдыр бир деңгээлде абал PostgreSQL менен бирдей. Айырмачылыгы, маалымат базасы бардык ресурстарды өзүнө ала албайт, башкача айтканда, Linux деңгээлинде сиз мунун баарын өзүңүз иргешиңиз керек.
Негизги идея бир максатты тандап, аны тууралоону баштоо эмес, мисалы, эстутум, CPU же башка ушул сыяктуу, бирок иш жүгүн талдоо жана жакшы программисттер жүктөгөн жүктү болушу үчүн мүмкүн болушунча өткөрүү жөндөмдүүлүгүн жакшыртууга аракет кылуу. биз үчүн, анын ичинде биздин колдонуучулар үчүн.
Бул эмне экенин түшүндүрүү үчүн сүрөт. Linux OS буфери жана жалпы эс тутуму бар жана PostgreSQL бөлүшүлгөн буферлери бар. PostgreSQL, Oracleдан айырмаланып, түздөн-түз өзөк буфери аркылуу гана иштейт, б.а., дисктен бир барак анын жалпы эс тутумуна кириши үчүн, ядро буферинен өтүшү керек жана дал ошол эле жагдай.
Бул системанын астында дисктер жашайт. Мен муну диск катары тарттым. Чынында, RAID контроллери болушу мүмкүн, ж.б.
Жана бул киргизүү-чыгаруу тигил же бул маселе аркылуу болот.
PostgreSQL классикалык маалымат базасы. Ичинде барак бар. Жана бардык киргизүү жана чыгаруу барактар аркылуу пайда болот. Биз блокторду барактар менен эс тутумга түшүрүп жатабыз. Эгерде эч нерсе болбогондо, биз аларды жөн эле окуйбуз, анан акырындык менен алар бул кэштен, жалпы буферлерден жок болуп, кайра дискке түшүп калышат.
Эгерде биз бир нерсени алмаштырсак, анда бүт бет кир деп белгиленет. Мен аларды бул жерде көк менен белгилеп койдум. Жана бул бул барак блокту сактоо менен синхрондоштуруу керек дегенди билдирет. Башкача айтканда, биз аны булгаганыбызда, WALга киргиздик. Ал эми убакыттын кандайдыр бир кереметтүү көз ирмеминде, текшерүү пункту деген кубулуш келди. Ал эми бул журналга анын келгени тууралуу маалымат жазылган. Жана бул бул жалпы буферлерде ошол учурда бул жерде болгон бардык кир барактар ядро буфери аркылуу fsync аркылуу сактагыч диск менен синхрондоштурууну билдирет.
Бул эмне үчүн жасалып жатат? Эгерде биз чыңалууну жоготуп алсак, анда биз бардык маалыматтар жоголгон жагдайды алган жокпуз. Ар бир адам айтып берген туруктуу эс тутум, маалымат базасынын теориясында азырынча - бул жаркын келечек, биз, албетте, умтулабыз жана бул бизге жагат, бирок азыр алар минус 20 жыл жашайт. Анан, албетте, мунун бардыгын көзөмөлдөө керек.
Ал эми өткөрүү жөндөмдүүлүгүн жогорулатуу милдети баары алдыга жана артка тез кыймылдай тургандай кылып, бул этаптардын баарын тактоо болуп саналат. Бөлүшүлгөн эс - бул барактын кэши. PostgreSQLде биз тандалган суроо же башка нерсени жөнөттүк, ал бул маалыматты дисктен чыгарды. Алар жалпы буферлерде бүтүштү. Демек, бул жакшы иштеши үчүн, эстутум көп болушу керек.
Мунун баары жакшы жана тез иштеши үчүн, сиз бардык этаптарда операциялык системаны туура конфигурациялашыңыз керек. Жана балансталган аппаратты тандаңыз, анткени сизде бир жерде дисбаланс бар болсо, анда сиз көп эстутумду түзө аласыз, бирок ал жетиштүү ылдамдыкта тейленбейт.
Жана бул пункттардын ар бирин карап көрөлү.
Бул барактарды алдыга жана артка тезирээк кыдыруу үчүн, сиз төмөнкүлөргө жетишишиңиз керек:
- Биринчиден, эс тутум менен эффективдүү иштешиңиз керек.
- Экинчиден, эстутумдагы баракчалар дискке өткөндө бул өтүү натыйжалуураак болушу керек.
- Үчүнчүдөн, жакшы дисктер болушу керек.
Эгерде сизде серверде 512 ГБ оперативдик эс тутум болсо жана анын баары SATA катуу дискинде эч кандай кэш жок болсо, анда бүт маалымат базасы сервери жөн эле ашкабакка эмес, SATA интерфейси бар ашкабакка айланат. Сиз ага түздөн-түз чуркайсыз. Жана эч нерсе сени куткара албайт.
Эстутумдун биринчи пунктуна келсек, жашоону абдан кыйындата турган үч нерсе бар.
Алардын биринчиси - NUMA. NUMA - бул ишти жакшыртуу үчүн жасалган нерсе. Жумуштун жүгүнө жараша ар кандай нерселерди оптималдаштырса болот. Жана анын жаңы учурдагы формасында, бул баракча кэш бөлүшүлгөн буферлерди интенсивдүү колдонгон маалыматтар базасы сыяктуу тиркемелер үчүн анча жакшы эмес.
Кыскасы. NUMA менен бир нерсе туура эмес экенин кантип айта аласыз? Сизде кандайдыр бир жагымсыз тыкылдатыңыз, күтүлбөгөн жерден кандайдыр бир CPU ашыкча жүктөлөт. Ошол эле учурда, сиз PostgreSQLдеги сурамдарды талдап, ал жерде окшош эч нерсе жок экенин көрөсүз. Бул сурамдар CPU интенсивдүү болбошу керек. Сиз муну көпкө кармай аласыз. PostgreSQL үчүн NUMAны кантип конфигурациялоо керектиги боюнча эң башынан эле туура сунушту колдонуу оңой.
Чынында эмне болуп жатат? NUMA бирдиктүү эмес эс тутумуна кирүү дегенди билдирет. Мунун эмне кереги бар? Сизде CPU бар, анын жанында анын жергиликтүү эс тутуму бар. Жана бул эстутумдун өз ара байланыштары башка процессорлордон эстутумду тарта алат.
Эгер чуркасаң numactl --hardware, анда сиз ушундай чоң барак аласыз. Башка нерселер менен катар аралыктар талаасы болот. Сандар болот - 10-20, ушуга окшош. Бул сандар бул алыскы эстутумду алуу жана аны жергиликтүү түрдө колдонуу үчүн хоп санынан башка эч нерсе эмес. Негизи жакшы идея. Бул бир катар жүктөмдөрдүн алкагында аткарууну тездетет.
Эми сизде бир CPU бар деп элестетип көрүңүз, адегенде анын жергиликтүү эс тутумун колдонууга аракет кылып, андан кийин бир нерсе үчүн интерконнект аркылуу башка эстутумду тартууга аракет кылып жатат. Жана бул CPU сиздин PostgreSQL баракчаңыздын кэшин бүт алат - бул, бир нече гигабайт. Сиз ар дайым эң начар абалга туш болосуз, анткени CPUда көбүнчө ошол модулдун өзүндө эстутум аз. Ал эми тейленген эс тутумдун баары ушул өз ара байланыштар аркылуу өтөт. Бул жай жана кайгылуу болуп чыгат. Жана бул түйүндү тейлеген процессоруңуз дайыма ашыкча жүктөлөт. Ал эми бул эстутумдун кирүү убактысы начар, жай. Эгер сиз муну маалымат базасы үчүн колдонуп жатсаңыз, бул сиз каалабаган жагдай.
Ошондуктан, Linux операциялык тутумунун ал жерде эмне болуп жатканын такыр билбеши үчүн, маалыматтар базасынын туура варианты болуп саналат. Ошентип, ал эстутумга кандай болсо, ошондой кире алат.
Эмнеге андай? Бул тескерисинче болушу керек окшойт. Бул бир жөнөкөй себеп менен болот: баракчанын кэши үчүн бизге көп эстутум керек - ондогон, жүздөгөн гигабайттар.
Эгерде биз мунун бардыгын бөлүп, маалыматтарыбызды ошол жерде кэштеп алсак, анда кэшти колдонуудан алынган пайда эстутумга мындай татаал жетүүдөн алда канча көп болот. Ошентип, биз NUMA аркылуу эстутумга эффективдүү жетүү менен салыштырганда теңдешсиз пайда алабыз.
Ошондуктан, учурда бул жерде, жаркыраган келечек келгенге чейин эки ыкма бар, ал эми маалымат базасы кайсы процессорлордо иштеп жатканын жана кайсы жерден бир нерсе алуу керектигин аныктай албайт.
Ошондуктан, туура мамиле - NUMAны толугу менен өчүрүү, мисалы, кайра жүктөөдө. Көпчүлүк учурларда, утуштар ушунчалык чоңдукта болгондуктан, кайсынысы жакшы деген суроо такыр жаралбайт.
Дагы бир вариант бар. Биз аны биринчисине караганда көбүрөөк колдонобуз, анткени кардар бизге жардам сурап келгенде, серверди кайра жүктөө ал үчүн чоң маселе. Ал жерде анын бизнеси бар. Жана алар NUMAнын айынан көйгөйлөргө туш болушат. Ошондуктан, биз аны кайра жүктөөгө караганда азыраак инвазивдүү жолдор менен өчүрүүгө аракет кылабыз, бирок анын өчүрүлгөнүн текшерүүдөн этият болуңуз. Анткени, тажрыйба көрсөткөндөй, биз PostgreSQL ата-эне процессинде NUMAны өчүргөнүбүз жакшы, бирок анын иштеши такыр зарыл эмес. Биз текшерип, анын чындап эле өчүп калганын көрүшүбүз керек.
Роберт Хаастын жакшы посту бар. Бул PostgreSQL комиссарларынын бири. Бардык төмөнкү деңгээлдеги гиблеттердин негизги иштеп чыгуучуларынын бири. Эгер сиз бул посттун шилтемелерин карасаңыз, алар NUMA адамдардын жашоосун кантип кыйындатканы жөнүндө бир нече түстүү окуяларды сүрөттөйт. Караңыз, маалымат базабыз жакшы иштеши үчүн серверде конфигурацияланышы керек болгон системалык администратордун текшерүү тизмесин изилдеңиз. Бул орнотууларды жазып, текшериш керек, антпесе бул абдан жакшы болбойт.
Бул мен сүйлөшө турган бардык орнотууларга тиешелүү экенин эске алыңыз. Бирок, адатта, маалымат базалары каталарга чыдамдуулук үчүн мастер-кул режиминде чогултулат. Бул жөндөөлөрдү кулга жасоону унутпаңыз, анткени бир күнү кырсыкка учурап, кулга өтөсүз жана ал кожоюн болуп калат.
Өзгөчө кырдаалда, баары өтө начар болуп, телефонуңуз тынымсыз шыңгырап турганда жана жетекчиңиз чоң таяк менен чуркап келгенде, текшерүү жөнүндө ойлонууга убактыңыз калбай калат. Ал эми натыйжалары абдан каргашалуу болушу мүмкүн.
Кийинки пункт - чоң баракчалар. Чоң барактарды өзүнчө сынап көрүү кыйын жана муну жасоонун эч кандай мааниси жок, бирок муну жасай турган көрсөткүчтөр бар. Алар Google үчүн оңой.
Мунун эмне кереги бар? Сизде өтө кымбат эмес сервер бар, мисалы, 30 ГБ ашык оперативдүү эс тутуму бар. Сиз чоң баракчаларды колдонбойсуз. Бул, албетте, эстутумду пайдалануу жагынан сизде ашыкча чыгым бар экенин билдирет. Ал эми бул ашыкча чыгымдар абдан жагымдуу эмес.
Эмнеге андай? Анда эмне болуп жатат? Иштөө системасы эстутумду кичинекей бөлүктөргө бөлөт. Бул абдан ыңгайлуу, бул тарыхый жактан кандай болгон. Ал эми майда-чүйдөсүнө чейин айта турган болсок, ОС виртуалдык даректерди физикалык даректерге которуусу керек. Жана бул процесс эң жөнөкөй эмес, ошондуктан ОС бул операциянын натыйжасын Translation Lookaside Buffer (TLB) ичинде кэштейт.
Жана TLB кэш болгондуктан, кэшке мүнөздүү бардык көйгөйлөр ушул кырдаалда пайда болот. Биринчиден, эгер сизде RAM көп болсо жана анын баары кичинекей бөлүктөргө бөлүнгөн болсо, анда бул буфер абдан чоң болуп калат. Ал эми кэш чоң болсо, анда аны издөө жайыраак болот. Үстүнкү дени сак жана өзү мейкиндикти ээлейт, б.а. RAM туура эмес нерсеге жумшалып жатат. Бул убакыт.
Эки - мындай кырдаалда кэш канчалык көп өссө, сизде кэш сагынуу ыктымалдыгы ошончолук жогору. Жана бул кэштин эффективдүүлүгү анын көлөмү чоңойгон сайын тез төмөндөйт. Ошондуктан, операциялык системалар жөнөкөй ыкма менен келди. Ал көп убакыттан бери Linuxда колдонулуп келет. Ал жакында эле FreeBSDде пайда болгон. Бирок биз Linux жөнүндө сөз кылып жатабыз. Бул чоң баракчалар.
Жана бул жерде белгилей кетүүчү нерсе, чоң барактарды идея катары башында Oracle жана IBM камтыган жамааттар түртүшкөн, башкача айтканда, маалымат базаларын өндүрүүчүлөр бул маалымат базалары үчүн да пайдалуу болот деп катуу ойлошкон.
Муну PostgreSQL менен кантип достосо болот? Биринчиден, чоң баракчалар Linux ядросунда иштетилиши керек.
Экинчиден, алар sysctl параметри менен ачык көрсөтүлүшү керек - алардын саны канча. Бул жердеги сандар эски серверден алынган. Сизде канча бөлүшүлгөн буфер бар экенин эсептей аласыз, ошондо чоң баракчалар ал жерге батат.
Эгерде сиздин бүт сервериңиз PostgreSQLге арналган болсо, анда RAMдын 25% бөлүшүлгөн буферлерге же 75% ын бөлүштүрүү жакшы башталыш болуп саналат. Биринчи чекит. Эгер сизде 75 ГБ оперативдик эс тутум болсо, анда 256 ГБ чоң буферге ээ болосуз. Болжол менен кээ бир маржа менен эсептеңиз - бул көрсөткүч эмнеге коюлушу керек.
9.2 версиясына чейин (эгер жаңылбасам, 8.2 версиясынан бери), PostgreSQLди үчүнчү тараптын китепканасын колдонуп чоң баракчалар менен туташтыруу мүмкүн болчу. Жана бул ар дайым жасалышы керек. Биринчиден, чоң барактарды туура бөлүштүрүү үчүн ядро керек. Экинчиден, алар менен иштеген тиркеме аларды колдоно алышы үчүн. Бул жөн эле колдонулбайт. PostgreSQL эс тутумун 5 стилинде бөлгөндүктөн, муну libhugetlbfs аркылуу жасоого болот - бул китепкананын толук аталышы.
9.3-жылы, эс тутум менен иштөөдө PostgreSQL көрсөткүчтөрү жакшыртылды жана тутум 5 эстутум бөлүштүрүү ыкмасынан баш тартты. Баары абдан кубанышты, анткени антпесе сиз бир машинада эки PostgreSQL инстанциясын иштетүүгө аракет кыласыз, жана ал менде жалпы эсим жетишсиз дейт. Жана ал sysctl оңдоо керек дейт. Жана ушундай sysctl бар, сиз дагы эле кайра жүктөө керек, ж.б. Жалпысынан алганда, баары бактылуу болду. Бирок mmap эстутумун бөлүштүрүү чоң барактарды колдонууну сындырды. Биздин кардарлардын көбү чоң жалпы буферлерди колдонушат. Ал эми биз 9.3кө өтпөөнү катуу сунуш кылдык, анткени ал жерде кошумча чыгымдар жакшы пайыздар менен эсептеле баштады.
Бирок коомчулук бул көйгөйгө көңүл буруп, 9.4-жылы бул окуяны абдан жакшы иштеп чыгышты. Ал эми 9.4-те postgresql.conf ичинде параметр пайда болду, анда сиз аракет кылып, күйгүзүп же өчүрө аласыз.
Аракет кылуу эң коопсуз вариант. PostgreSQL иштей баштаганда, ал жалпы эстутумду бөлгөндө, бул эстутумду чоң барактардан алууга аракет кылат. Ал иштебесе, анда ал кадимки тандоого кайтып келет. Эгер сизде FreeBSD же Solaris болсо, анда аракет кылып көрсөңүз болот, ал ар дайым коопсуз.
Эгер күйгүзүлсө, анда ал чоң барактардан тандап албаса, жөн эле башталбайт. Бул жерде ким жана эмне жакшыраак экендиги жөнүндө. Бирок, эгер сиз аракет кылып көрсөңүз, анда сизде эмне керек экенин текшериңиз, анткени ката кетирүүгө көп орун бар. Учурда бул функция Linuxда гана иштейт.
Андан ары барардан мурун дагы бир кичинекей эскертүү. Тунук чоң баракчалар PostgreSQL жөнүндө азырынча эмес. Ал аларды кадимкидей колдоно албайт. Жана ушундай жумуш жүгү үчүн Transparent чоң баракчалары менен, жалпы эстутумдун чоң бөлүгү керек болгондо, артыкчылыктар өтө чоң көлөмдө гана келет. Эгер сизде терабайт эс тутум болсо, анда бул оюнга кириши мүмкүн. Эгерде биз көбүрөөк күнүмдүк тиркемелер жөнүндө сөз кыла турган болсок, анда сиздин машинаңызда 32, 64, 128, 256 ГБ эстутум болгондо, анда кадимки чоң баракчалар жакшы болот жана биз Transparentти жөн эле өчүрөбүз.
Ал эми эс жөнүндө акыркы нерсе түздөн-түз fruitut менен байланыштуу эмес, ал чындап эле жашообузду бузуп алат. Сервердин тынымсыз алмашуусу бардык өткөрүү жөндөмдүүлүгүнө чоң таасирин тийгизет.
Жана бул бир катар жагынан абдан жагымсыз болот. Ал эми негизги көйгөй - заманбап ядролор эски Linux өзөктөрүнөн бир аз башкачараак. Ал эми бул нерсеге кадам таштоо абдан жагымсыз, анткени биз своп менен кандайдыр бир иш жөнүндө сөз кылганда, ал ООМ-киллердин өз убагында келбей калышы менен аяктайт. Ал эми өз убагында келбеген жана PostgreSQLди түшүргөн OOM-киллер жагымсыз. Бул тууралуу ар бир адам, башкача айтканда, акыркы колдонуучуга чейин билет.
Эмне болуп жатат? Сизде чоң көлөмдөгү RAM бар, баары жакшы иштейт. Бирок кандайдыр бир себептерден улам сервер свопта илинип, ушундан улам жайлайт. Эстутум көп окшойт, бирок бул болот.
Мурда биз vm.swappiness нөлгө коюуну, б.а. алмашууну өчүрүүнү сунуштаганбыз. Буга чейин 32 ГБ оперативдүү эс жана тиешелүү жалпы буферлер абдан чоң сумма болуп көрүнгөн. Своптун негизги максаты - биз жыгылып калсак жер кыртышын ыргыта турган жер. Ал эми өзгөчө аткарылган жок. Анан бул кабыкты эмне кыласың? Бул своп эмне үчүн керек экендиги так эмес тапшырма, айрыкча, мындай өлчөмдөгү.
Бирок заманбап, башкача айтканда, ядронун үчүнчү версияларында жүрүм-турум өзгөрдү. Эгерде сиз свопту нөлгө коюңуз, башкача айтканда, аны өчүрсөңүз, анда эртеби-кечпи, бир аз оперативдүү эс тутум болсо да, эң интенсивдүү керектөөчүлөрдү өлтүрүү үчүн сизге OOM өлтүргүч келет. Анткени, ал мындай иш жүктөмү менен бизде дагы эле бир аз калды жана биз секирип чыгабыз, башкача айтканда, система процессин мык менен эмес, анча маанилүү эмес нерсени мыктайбыз деп эсептейт. Бул анча маанилүү эмес, жалпы эс тутумдун интенсивдүү керектөөчүсү, тактап айтканда, почта башчысы болот. Ошондон кийин базаны калыбына келтириш керек болбосо жакшы болот.
Ошондуктан, азыр демейки, менин эсимде, көпчүлүк дистрибуциялар 6га жакын жерде, башкача айтканда, эстутумдун көлөмүнө жараша алмашууну кайсы учурда колдонууну баштоо керек. Биз азыр vm.swappiness = 1 коюуну сунуштайбыз, анткени бул иш жүзүндө аны өчүрөт, бирок күтүлбөгөн жерден келип, бүт нерсени өлтүргөн OOM-киллердик эффекттерди бербейт.
Кийинкиси эмне? Биз маалымат базаларынын иштеши жөнүндө сөз кылып, акырындык менен дисктерге өткөнүбүздө, бардыгы баштарын кармай башташат. Анткени диск жай, эс тутуму тез деген чындык ар кимге бала кезинен тааныш. Ал эми маалымат базасында дисктин иштеши көйгөйлөрү бар экенин баары билет.
Текшерүү пункттарынын кескин көтөрүлүшү менен байланышкан PostgreSQL иштешинин негизги көйгөйү диск жай болгондуктан пайда болбойт. Бул, кыязы, эстутум жана диск өткөрүү жөндөмдүүлүгү тең салмактуу эместиги менен байланыштуу. Бирок, алар ар кайсы жерлерде тең салмактуу болбошу мүмкүн. PostgreSQL конфигурацияланган эмес, ОС конфигурацияланган эмес, жабдык конфигурацияланган эмес жана аппараттык камсыздоо туура эмес. Жана бул маселе баары каалагандай болгондо гана болбойт, б.а. жүк жок болсо, же орнотуулар жана жабдыктар жакшы тандалган.
Бул эмне жана ал кандай көрүнөт? Адатта PostgreSQL менен иштеген адамдар бул маселеге бир нече жолу киришкен. Мен түшүндүрүп берем. Мен айткандай, PostgreSQL мезгил-мезгили менен бөлүшүлгөн эстутумдагы кир баракчаларды дискке таштоо үчүн текшерүү пункттарын түзөт. Эгерде бизде чоң көлөмдөгү жалпы эс тутум болсо, анда текшерүү пункту дискке интенсивдүү таасирин тийгизе баштайт, анткени ал бул баракчаларды fsync менен таштайт. Ал ядро буферине келип, fsync аркылуу дисктерге жазылат. Ал эми бул бизнестин көлөмү чоң болсо, анда биз жагымсыз эффектти, тактап айтканда, дисктерди абдан чоң колдонууну байкай алабыз.
Бул жерде менде эки сүрөт бар. Мен азыр эмне экенин түшүндүрөм. Бул эки убакыт менен байланышкан графиктер. Биринчи график - дискти колдонуу. Бул жерде бул учурда дээрлик 90% жетет. Эгер сизде физикалык дисктер менен маалымат базасы бузулуп калса, RAID контроллерин 90% колдонуу менен, анда бул жаман жаңылык. Бул бир аз көбүрөөк жана ал 100 жетет жана I/O токтойт дегенди билдирет.
Эгер сизде диск массивиңиз болсо, анда бул бир аз башкача окуя. Бул анын кантип конфигурацияланганына, кандай массив экендигине ж.б. көз каранды.
Жана параллелдүү, бул жерде постгрестин ички көрүнүшүнөн график конфигурацияланган, ал текшерүү пунктунун кантип пайда болгонун айтып берет. Ал эми бул жерде жашыл түс синхрондоштуруу үчүн бул өткөрмө пунктуна канча буфер, бул кир барактар келгенин көрсөтүп турат. Жана бул жерде сиз билишиңиз керек болгон негизги нерсе. Бул жерде бизде көп баракчалар бар экенин көрүп жатабыз жана кайсы бир учурда тактага тийип калдык, башкача айтканда, биз жазып жана жазганбыз, бул жерде диск системасы абдан бош эмес. Ал эми биздин өткөрүү пункту дискке абдан катуу таасир этет. Идеалында, кырдаал ушуга окшош болушу керек, б.а. биз бул жерде жаздыруу азыраак болгон. Ал эми биз аны жөндөөлөр менен оңдой алабыз, ошентип ал мындан ары да ушундай болот. Башкача айтканда, кайра иштетүү аз, бирок бир жерде биз бул жерде бир нерсе жазып жатабыз.
Бул көйгөйдү жеңүү үчүн эмне кылуу керек? Эгерде сиз базанын астында IOну токтоткон болсоңуз, бул алардын суроо-талаптарын аткаруу үчүн келген бардык колдонуучулар күтө турганын билдирет.
Эгерде сиз Linux көз карашынан карасаңыз, анда сиз жакшы жабдыктарды алып, аны туура конфигурациялаган болсоңуз, PostgreSQLди кадимкидей конфигурациялаган болсоңуз, анда бул текшерүү пункттарын азыраак кылып, убакыттын өтүшү менен бири-бирине таратып, анда сиз демейки Debian параметрлерине кадам таштайсыз. Көпчүлүк Linux дистрибуциялары үчүн бул сүрөт: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Бул эмнени билдирет? 2.6 ядросунан бир кызарган жин чыкты. Pdglush, ким колдонуп жатканына жараша, ядро буферинен булганган барактарды фонго таштоо менен алектенет жана кир беттерди эмнеге болбосун таштоо керек болгондо, фон графигин таштоо жардам бербейт.
Фон качан келет? Серверде жеткиликтүү болгон жалпы оперативдик эстутумдун 10% ядро буфериндеги кир барактар ээлегенде, фондо атайын өчүрүү функциясы чакырылат. Эмне үчүн бул фон? Параметр катары канча барактан чыгуу керектиги эске алынат. Ал эми, айталы, ал N барактарды жазат. Анан бир азга бул нерсе уктап калат. Анан кайра келип, дагы бир нече барактарды көчүрөт.
Бул өтө жөнөкөй окуя. Бул жерде көйгөй бассейндегидей, ал бир түтүккө куйса, экинчи түтүккө агып кетет. Биздин көзөмөл-өткөрүү пунктубуз келди жана эгерде ал бир нече кир баракчаларды жок кылуу үчүн жөнөтсө, анда бара-бара бүт нерсе pgflush ядросунун буферинен тыкан чечилет.
Эгерде бул кир барактар топтоло берсе, алар 20% га чейин чогулат, андан кийин OS приоритети бүт нерсени дискке жазуу болуп саналат, анткени электр энергиясы өчүп калат жана биз үчүн баары жаман болот. Биз, мисалы, бул маалыматтарды жоготуп алабыз.
Кандай амал? Куулук, азыркы дүйнөдө бул параметрлер машинадагы жалпы оперативдүү эс тутумдун 20 жана 10% түзөт, алар сизде болгон ар кандай диск тутумунун өткөрүү жөндөмдүүлүгү жагынан абдан коркунучтуу.
Элестетиңиз, сизде 128 ГБ оперативдүү эс тутум бар. 12,8 ГБ диск тутумуңузга келет. Ал жерде кандай кэш болсо да, ал жерде кандай массив болсо да, алар мынчалык узакка созулбайт.
Ошондуктан, бул сандарды RAID контроллеруңуздун мүмкүнчүлүктөрүнө жараша дароо тууралоону сунуштайбыз. Мен дароо бул жерде 512 МБ кэши бар контроллер боюнча сунуш бердим.
Баары абдан жөнөкөй деп эсептелет. Сиз vm.dirty_background байттарга кое аласыз. Жана бул орнотуулар мурунку экөөнү жокко чыгарат. Же катышы демейки боюнча, же байттары барлар иштетилген болсо, анда байттары барлар иштейт. Бирок мен DBA консультанты болгондуктан жана ар кандай кардарлар менен иштегендиктен, самандарды тартууга аракет кылам, демек, байт менен болсо, анда байт менен. Эч ким эч кандай кепилдик берген эмес, жакшы админ серверге эстутум кошуп, аны кайра жүктөбөйт жана фигура ошол эле бойдон калат. Бул сандарды эсептеп чыккыла, баары кепилдик менен ошол жерге туура келет.
Эгер сиз туура келбесеңиз эмне болот? Мен ар кандай кызаруунун эффективдүү токтотуларын жаздым, бирок чындыгында бул сөздүн көрсөткүчү. Операциялык тутумда чоң көйгөй бар - анда көптөгөн кир барактар бар, ошондуктан сиздин кардарлар түзгөн IO эффективдүү токтотулган, б.а. колдонмо маалымат базасына SQL сурамын жөнөтүү үчүн келди, ал күтүп жатат. Ага ар кандай киргизүү/чыгарма эң төмөнкү артыкчылыктуу, анткени маалымат базасын текшерүү пункту ээлейт. Ал качан бүтөөрү такыр белгисиз. Ал эми сиз фондо эмес тазалоого жетишкениңизде, бул сиздин бардык IOңузду ээлегенин билдирет. Ал бүткүчө, сен эч нерсе кылбайсың.
Бул жерде бул отчеттун чегинен тышкары дагы эки маанилүү жагдай бар. Бул орнотуулар postgresql.conf дарегиндеги жөндөөлөргө дал келиши керек, б.а. текшерүү пункттарынын жөндөөлөрү. Жана сиздин диск тутумуңуз адекваттуу конфигурацияланган болушу керек. Эгер сизде RAIDде кэш бар болсо, анда анын батареясы болушу керек. Адамдар батареясы жок жакшы кэш менен RAID сатып алышат. Эгер сизде RAIDде SSD бар болсо, анда алар сервердик болушу керек, ал жерде конденсаторлор болушу керек. Бул жерде деталдуу текшерүү тизмеси. Бул шилтемеде PostgreSQLде иштөө дискин кантип конфигурациялоо керектиги тууралуу менин баяндамам камтылган. Ал жерде бул текшерүү баракчаларынын баары бар.
Жашоону дагы эмне кыйындатат? Бул эки параметр. Алар салыштырмалуу жаңы. Демейки боюнча, алар ар кандай тиркемелерге киргизилиши мүмкүн. Жана алар туура эмес күйгүзүлсө, жашоону кыйындата алышат.
Эки салыштырмалуу жаңы нерсе бар. Алар буга чейин үчүнчү өзөктө пайда болгон. Бул наносекундалардагы sched_migration_cost жана sched_autogroup_enabled, бул демейки боюнча бир.
Анан кантип алар сенин жашооңду бузушат? Sched_migration_cost деген эмне? Linuxда пландоочу процессти бир CPUдан экинчисине көчүрө алат. Ал эми суроо-талаптарды аткарган PostgreSQL үчүн башка процессорго өтүү такыр түшүнүксүз. Операциялык системанын көз карашынан алганда, сиз терезелерди openoffice менен терминалдын ортосунда алмаштырганда, бул жакшы болушу мүмкүн, бирок маалымат базасы үчүн бул абдан жаман. Ошондуктан, акылга сыярлык саясат - migration_cost параметрин кандайдыр бир чоң мааниге, жок дегенде бир нече миң наносекундга коюу.
Бул пландоочу үчүн эмнени билдирет? Бул убакыттын ичинде процесс дагы эле ысык деп эсептелинет. Башкача айтканда, эгер сизде көптөн бери бир нерсе кылып келе жаткан узак мөөнөттүү транзакция болсо, пландоочу муну түшүнөт. Ал бул тайм-аут өтмөйүнчө, бул процессти эч жакка көчүрүүнүн кереги жок деп ойлойт. Эгерде процесс бир эле учурда бир нерсе жасаса, анда ал эч жакка көчүрүлбөйт, ал ага бөлүнгөн CPU менен тынч иштейт. Ал эми натыйжасы сонун.
Экинчи пункт - автогруппа. Заманбап маалымат базаларына тиешеси жок конкреттүү жүктөмдөр үчүн жакшы идея бар - бул процесстерди алар ишке киргизилген виртуалдык терминал боюнча топтоо. Бул кээ бир тапшырмалар үчүн ыңгайлуу. Практикада PostgreSQL бир терминалдан иштей турган префорк менен көп процесстүү система. Сизде кулпу жазуучу, текшерүү пункту бар жана кардарыңыздын бардык суроо-талаптары бир CPU үчүн бир пландоочуга топтолот. Жана алар бири-бирине кийлигишип, аны көпкө ээлеп туруу үчүн, анын боштондукка чыгышын бир добуштан күтүшөт. Бул мындай жүк болгон учурда таптакыр кереги жок окуя, ошондуктан аны өчүрүү керек.
Кесиптешим Алексей Лесовский жөнөкөй pgbench менен тесттерди жасап, анда ал миграциялык_баасын чоңдук менен жогорулатып, автогруппаны өчүрдү. Жаман аппараттык айырма дээрлик 10% болгон. Postgres почта тизмесинде талкуу бар, анда адамдар суроо ылдамдыгына окшош өзгөрүүлөрдүн натыйжаларын беришет 50% таасир эткен. Мындай окуялар абдан көп.
Акыр-аягы, электр энергиясын үнөмдөө саясаты жөнүндө. Жакшы нерсе, Linux азыр ноутбукта колдонулушу мүмкүн. Жана ал батарейканы жакшы сарптайт имиш. Бирок күтүлбөгөн жерден бул серверде да болушу мүмкүн экен.
Андан тышкары, эгер сиз серверлерди кандайдыр бир хосттерден ижарага алсаңыз, анда "жакшы" хостерлер сиздин жакшыраак иштешиңизге маани беришпейт. Алардын милдети темирди мүмкүн болушунча натыйжалуу пайдаланууну камсыз кылуу. Ошондуктан, демейки боюнча, алар операциялык тутумда ноутбуктун энергияны үнөмдөө режимин иштете алышат.
Эгер сиз бул нерсени оор жүктө турган маалымат базасы бар серверде колдонсоңуз, анда сиздин тандооңуз acpi_cpufreq + permormance. Ал тургай, суроо-талап менен көйгөйлөр болот.
Intel_pstate бир аз башкача драйвер. Эми ушуга артыкчылык берилет, анткени ал кийинчерээк жана жакшыраак иштейт.
Демек, губернатор бир гана аткаруу болуп саналат. Demand, powersave жана башкалардын баары сиз жөнүндө эмес.
Түшүндүрмө анализинин натыйжалары PostgreSQL кубаттуулугун үнөмдөө функциясын иштетсеңиз, бир нече чоңдук тартиби менен айырмаланышы мүмкүн, анткени сиздин маалымат базасынын астындагы CPU дээрлик күтүүсүз түрдө иштейт.
Бул нерселер демейки боюнча киргизилиши мүмкүн. Алар демейки боюнча күйгүзүлгөнүн билүү үчүн кылдаттык менен караңыз. Бул чынында эле чоң көйгөй болушу мүмкүн.
Акырында мен биздин PosgreSQL-Consulting DBA командасынын жигиттерине, атап айтканда Макс Богук менен Алексей Лесовскийге рахмат айткым келди, алар бул маселеде күн сайын алдыга жылууда. Жана биз кардарларыбыз үчүн колубуздан келгендин баарын кылууга аракет кылабыз, ошентип баары алар үчүн иштейт. Бул авиациялык коопсуздук көрсөтмөлөрү сыяктуу. Бул жерде баары кан менен жазылган. Бул жаңгактардын ар бири көйгөйдүн кандайдыр бир процессинде кездешет. Мен аларды сиз менен бөлүшүүгө кубанычтамын.
суроолор:
Рахмат! Эгерде, мисалы, компания акча үнөмдөп, маалымат базасын жана тиркеме логикасын бир серверге жайгаштыргысы келсе, же компания PostgreSQL контейнерде иштеген микросервис архитектурасынын модалуу тенденциясын карманса. Кандай амал? Sysctl бүткүл ядрого глобалдык таасирин тийгизет. Мен sysctls кандайдыр бир жол менен виртуалдаштырылганын уккан эмесмин, алар контейнерде өзүнчө иштешет. Ал жерде бир гана топ бар жана ал жерде көзөмөлдүн бир бөлүгү гана бар. Муну менен кантип жашай аласың? Же аткарууну кааласаңыз, PostgreSQLди өзүнчө аппараттык серверде иштетип, аны тууралаңызбы?
Сурооңузга үч түрдүү жооп бердик. Эгерде биз жөндөлгөн аппараттык сервер ж. Эгер сизде ушундай жүк болсо, бул орнотууларды жасашыңыз керек болсо, анда сиз темир серверге бул орнотууларга караганда эрте келесиз.
Көйгөй эмнеде? Эгерде бул виртуалдык машина болсо, анда сизде көптөгөн көйгөйлөр пайда болушу мүмкүн, мисалы, көпчүлүк виртуалдык машиналарда дисктин кечигүү мөөнөтү бир топ дал келбегендиктен. Дисктин өткөрүү жөндөмдүүлүгү жакшы болсо дагы, текшерүү пунктунда же WALга жазуу учурунда болгон орточо өткөрүү жөндөмдүүлүгүнө анчалык таасир этпеген бир I/O транзакциясы иштебей калса, анда маалымат базасы мындан чоң зыян тартат. Жана сиз бул көйгөйлөргө туш боло электе муну байкайсыз.
Эгер сизде NGINX бир эле серверде болсо, сизде да ушундай көйгөй болот. Ал жалпы эскерүү үчүн күрөшөт. Жана сиз бул жерде сүрөттөлгөн көйгөйлөргө жете албайсыз.
Бирок, экинчи жагынан, бул параметрлердин айрымдары дагы эле сиз үчүн актуалдуу болот. Мисалы, sysctl менен dirty_ratio коюңуз, ал ушунчалык жинди болбошу үчүн - кандай болгон күндө да бул жардам берет. Кандайдыр бир жол менен, сиз диск менен өз ара аракеттенесиз. Жана ал туура эмес үлгү боюнча болот. Бул жалпысынан мен көрсөткөн параметрлер үчүн демейки болуп саналат. Жана кандай болгон күндө да аларды өзгөртүү жакшы.
Бирок NUMA менен көйгөйлөр болушу мүмкүн. VmWare, мисалы, так карама-каршы орнотуулары менен NUMA менен жакшы иштейт. Ал эми бул жерде сиз тандоо керек - темир сервер же темир эмес.
Менде Amazon AWS менен байланышкан суроом бар. Аларда алдын ала конфигурацияланган сүрөттөр бар. Алардын бири Amazon RDS деп аталат. Алардын операциялык тутумунун жеке жөндөөлөрү барбы?
Ал жерде орнотуулар бар, бирок алар башка орнотуулар. Бул жерде биз маалымат базасы бул нерсени кантип колдоно тургандыгы боюнча операциялык системаны конфигурациялайбыз. Ал эми калыптандыруу сыяктуу азыр кайда барышыбыз керектигин аныктаган параметрлер бар. Башкача айтканда, бизге ушунчалык көп ресурстар керек, биз аларды азыр жеп коёбуз. Андан кийин, Amazon RDS бул ресурстарды күчөтөт жана ал жерде иштөөсү төмөндөйт. Адамдар бул маселе менен кантип баш аламандык кыла баштагандыгы жөнүндө жеке окуялар бар. Кээде ал тургай абдан ийгиликтүү. Бирок бул OS орнотуулары менен эч кандай байланышы жок. Бул булутту бузуп жаткандай. Бул башка окуя.
Эмне үчүн Transparent чоң баракчалары чоң TLBге салыштырмалуу эч кандай таасир этпейт?
Бербе. Муну ар кандай жолдор менен түшүндүрсө болот. Бирок чындыгында алар жөн эле бербейт. PostgreSQL тарыхы кандай? Ишке киргизүүдө ал жалпы эстутумдун чоң бөлүгүн бөлүп берет. Алар ачык-айкын болобу же жокпу, бул таптакыр тиешеси жок. Алардын эң башында өзгөчөлөнүп турганы баарын түшүндүрөт. Ал эми эстутум көп болсо жана сиз shared_memory сегментин калыбына келтиришиңиз керек болсо, анда Transparent чоң баракчалар актуалдуу болот. PostgreSQLде, ал жөн гана башында чоң бөлүккө бөлүнгөн жана бүттү, андан кийин ал жерде өзгөчө эч нерсе болбойт. Сиз, албетте, колдонсоңуз болот, бирок ал бир нерсени кайра бөлүштүргөндө shared_memory бузулуп калуу мүмкүнчүлүгү бар. PostgreSQL бул жөнүндө билбейт.
Source: www.habr.com