Илья Космодемьянскийдің 2015 жылғы баяндамасының транскрипциясы «PostgreSQL өнімділігін жақсарту үшін Linux баптауы»
Жауапкершіліктен бас тарту: Мен бұл есептің 2015 жылдың қарашасында екенін ескертемін - 4 жылдан астам уақыт өтті және көп уақыт өтті. Есепте талқыланған 9.4 нұсқасына енді қолдау көрсетілмейді. Соңғы 4 жылда PostgreSQL-тің 5 жаңа шығарылымы және Linux ядросының 15 нұсқасы шығарылды. Егер сіз осы үзінділерді қайта жазсаңыз, сіз басқа есеппен аяқтайсыз. Бірақ бұл жерде біз PostgreSQL үшін іргелі Linux баптауын қарастырамыз, ол бүгінгі күнге дейін өзекті.
Менің атым Илья Космодемьянский. Мен PostgreSQL-Консалтингте жұмыс істеймін. Ал енді мен 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 әкімшілігімен айналысатындықтан, мақсаттардың не екенін түсіндірудің қажеті жоқ.
Реттеуге болады:
- ОРТАЛЫҚ ЕСЕПТЕУІШ БӨЛІМ.
- Жад.
- Сақтау
- Басқа. Біз бұл туралы соңында тіскебасар үшін сөйлесеміз. Тіпті, мысалы, энергияны үнемдеу саясаты сияқты параметрлер өнімділікке өте күтпеген және ең жағымды емес әсер етуі мүмкін.
PostgreSQL және жалпы деректер қорының ерекшеліктері қандай? Мәселе мынада, сіз жеке гайканы бұрап, біздің өнімділігіміз айтарлықтай жақсарғанын көре алмайсыз.
Иә, мұндай гаджеттер бар, бірақ деректер қоры күрделі нәрсе. Ол серверде бар барлық ресурстармен өзара әрекеттеседі және барынша әрекеттесуді қалайды. Егер сіз Oracle компаниясының негізгі операциялық жүйені пайдалану туралы қазіргі ұсыныстарын қарасаңыз, бұл әлгі моңғол ғарышкері туралы әзіл сияқты болады - итті тамақтандырыңыз және ештеңеге қол тигізбеңіз. Дерекқорға барлық ресурстарды берейік, мәліметтер базасының өзі бәрін реттейді.
Негізінде, белгілі бір дәрежеде жағдай PostgreSQL-пен бірдей. Айырмашылығы мынада, дерекқор әлі барлық ресурстарды өзіне ала алмайды, яғни Linux деңгейінде бір жерде бәрін өзіңіз сұрыптауыңыз керек.
Негізгі идея - бір мақсатты таңдап, оны баптауды бастау емес, мысалы, жад, процессор немесе сол сияқты, бірақ жұмыс жүктемесін талдап, жақсы бағдарламашылар оны жасаған жүктеме үшін өткізу қабілетін мүмкіндігінше жақсартуға тырысу. біз үшін, соның ішінде біздің пайдаланушыларымыз үшін.
Бұл не екенін түсіндіру үшін сурет. Linux ОЖ буфері және ортақ жады бар және PostgreSQL ортақ буферлері бар. PostgreSQL, Oracle-дан айырмашылығы, тікелей ядро буфері арқылы жұмыс істейді, яғни дискідегі бет өзінің ортақ жадына енуі үшін ядро буферінен өтіп, кері өтуі керек, дәл сол жағдай.
Дискілер осы жүйенің астында тұрады. Мен мұны дискілер ретінде сыздым. Шын мәнінде, RAID контроллері болуы мүмкін және т.б.
Және бұл енгізу-шығару бір немесе басқа жолмен осы мәселе арқылы жүзеге асады.
PostgreSQL - бұл классикалық деректер базасы. Ішінде бет бар. Және барлық енгізу және шығару беттер арқылы жүзеге асады. Біз блоктарды жадыға беттермен қосамыз. Егер ештеңе болмаса, біз оларды жай ғана оқимыз, содан кейін олар бірте-бірте осы кэштен, ортақ буферлерден жойылып, дискіге қайта оралады.
Егер біз бір жерде бір нәрсені ауыстырсақ, онда бүкіл бет лас деп белгіленеді. Мен оларды көк түспен белгіледім. Және бұл бұл бет блокты сақтаумен синхрондалу керек дегенді білдіреді. Яғни, біз оны кірлеген кезде, біз WAL-ге жазба жасадық. Уақыттың бір тамаша сәтінде бақылау пункті деп аталатын құбылыс келді. Және бұл журналға оның келгені туралы ақпарат жазылған. Бұл ортақ буферлерде сол кезде осы жерде болған барлық лас беттер ядро буфері арқылы fsync көмегімен сақтау дискімен синхрондалғанын білдіреді.
Бұл не үшін жасалып жатыр? Егер біз кернеуді жоғалтсақ, онда біз барлық деректер жоғалған жағдайды алмадық. Барлығы бізге айтып берген тұрақты жад деректер базасының теориясында әлі күнге дейін бар - бұл біз, әрине, ұмтыламыз және оны ұнататын жарқын болашақ, бірақ қазір олар минус 20 жыл өмір сүреді. Және, әрине, мұның бәрін бақылау керек.
Өткізу қабілеттілігін арттыру міндеті - бұл барлық кезеңдердің барлығы алға-артқа жылдам қозғалатындай етіп дәл баптау. Ортақ жад негізінен бет кэші болып табылады. PostgreSQL-де біз таңдау сұрауын немесе бір нәрсені жібердік, ол бұл деректерді дискіден шығарып алды. Олар ортақ буферлерде аяқталды. Тиісінше, бұл жақсы жұмыс істеуі үшін жады көп болуы керек.
Мұның бәрі жақсы және жылдам жұмыс істеуі үшін операциялық жүйені барлық кезеңдерде дұрыс конфигурациялау қажет. Және теңдестірілген жабдықты таңдаңыз, өйткені егер сізде бір жерде теңгерімсіздік болса, онда сіз көп жад жасай аласыз, бірақ оған жеткілікті жылдамдықта қызмет көрсетілмейді.
Және осы пункттердің әрқайсысына тоқталайық.
Бұл беттерді алға-артқа жылдамырақ жылжыту үшін төмендегілерге қол жеткізу керек:
- Біріншіден, жадпен тиімдірек жұмыс істеу керек.
- Екіншіден, беттер жадтан дискіге ауысқан кезде бұл өту тиімдірек болуы керек.
- Үшіншіден, жақсы дискілер болуы керек.
Егер сізде серверде 512 ГБ жедел жады болса және оның барлығы кэшсіз SATA қатты дискісінде аяқталса, онда бүкіл дерекқор сервері жай ғана асқабақ емес, SATA интерфейсі бар асқабаққа айналады. Сіз оған тікелей кіресіз. Және сізді ештеңе құтқара алмайды.
Жадқа қатысты бірінші мәселеге келетін болсақ, өмірді қиындататын үш нәрсе бар.
Олардың біріншісі - NUMA. NUMA - өнімділікті жақсарту үшін жасалған нәрсе. Жұмыс көлеміне байланысты әртүрлі нәрселерді оңтайландыруға болады. Және оның жаңа ағымдағы пішінінде ол бет кэшінің ортақ буферлерін қарқынды пайдаланатын дерекқорлар сияқты қолданбалар үшін өте жақсы емес.
Бір сөзбен айтқанда. NUMA-да бірдеңе дұрыс емес екенін қалай анықтауға болады? Сізде қандай да бір жағымсыз соққы бар, кенеттен CPU шамадан тыс жүктеледі. Сонымен бірге сіз PostgreSQL-де сұрауларды талдайсыз және онда ұқсас ештеңе жоқ екенін көресіз. Бұл сұраулар соншалықты CPU қарқынды болмауы керек. Сіз мұны ұзақ уақыт ұстай аласыз. PostgreSQL үшін NUMA конфигурациялау жолы туралы дұрыс ұсынысты пайдалану оңайырақ.
Шынымен не болып жатыр? NUMA біркелкі емес жадқа қол жеткізуді білдіреді. Мұның мәні неде? Сізде процессор бар, оның жанында оның жергілікті жады бар. Және бұл жад өзара байланыстары басқа процессорлардан жадты тарта алады.
Егер сіз жүгірсеңіз numactl --hardware, сонда сіз осындай үлкен парақты аласыз. Басқа нәрселермен қатар қашықтық өрісі болады. Сандар болады - 10-20, сол сияқты. Бұл сандар қашықтағы жадты алуға және оны жергілікті түрде пайдалануға арналған құлмақтардың санынан басқа ештеңе емес. Негізінде жақсы идея. Бұл әртүрлі жұмыс жүктемелері кезінде өнімділікті жақсы жылдамдатады.
Енді сізде бір процессор бар деп елестетіп көріңіз, алдымен оның жергілікті жадын пайдалануға тырысады, содан кейін бір нәрсе үшін интерконнект арқылы басқа жадты алуға тырысады. Бұл процессор бүкіл PostgreSQL бет кэшін алады - бұл бірнеше гигабайт. Сіз әрқашан ең нашар жағдайға тап боласыз, өйткені процессорда әдетте сол модульде жад аз болады. Ал қызмет көрсетілетін барлық жады осы өзара байланыстар арқылы өтеді. Бұл баяу және қайғылы болып шығады. Бұл түйінге қызмет көрсететін процессорыңыз үнемі шамадан тыс жүктеледі. Ал бұл жадтың кіру уақыты нашар, баяу. Бұл дерекқор үшін пайдалансаңыз, сізге қажет емес жағдай.
Сондықтан, дерекқордың дұрыс нұсқасы - Linux операциялық жүйесінің онда не болып жатқанын мүлде білмеуі. Осылайша ол жадқа қалай қол жеткізеді.
Неге бұлай? Бұл керісінше болуы керек сияқты. Бұл бір қарапайым себеппен орын алады: бет кэші үшін бізге көп жад қажет - ондаған, жүздеген гигабайт.
Егер біз мұның бәрін бөліп, деректерімізді сол жерде кэштесек, кэшті пайдаланудан түсетін пайда жадқа осындай қиын қол жеткізуден түсетін пайдадан айтарлықтай көп болады. Осылайша, біз NUMA көмегімен жадқа тиімдірек қол жеткізетінімізбен салыстырғанда теңдесі жоқ пайда аламыз.
Сондықтан, қазіргі уақытта бұл жерде, жарқын болашақ келгенге дейін екі тәсіл бар және дерекқордың өзі оның қандай процессорларда жұмыс істейтінін және қайдан бірдеңе алу керектігін анықтай алмайды.
Сондықтан дұрыс тәсіл NUMA-ны толығымен өшіру болып табылады, мысалы, қайта жүктеу кезінде. Көп жағдайда ұтыстар соншалықты дәрежеде болады, қайсысы жақсы деген сұрақ мүлдем туындамайды.
Басқа нұсқа бар. Біз оны біріншісіне қарағанда жиі қолданамыз, өйткені клиент бізге қолдау көрсету үшін келгенде, серверді қайта жүктеу ол үшін үлкен мәселе. Онда оның бизнесі бар. Және олар NUMA себебінен қиындықтарға тап болады. Сондықтан біз оны қайта жүктеуге қарағанда аз инвазивті жолдармен өшіруге тырысамыз, бірақ оның өшірілгенін тексеріңіз. Өйткені, тәжірибе көрсеткендей, негізгі PostgreSQL процесінде NUMA-ны өшіргеніміз жақсы, бірақ оның жұмыс істеуі міндетті емес. Біз оның шынымен өшірілгенін тексеріп, көруіміз керек.
Роберт Хаастың жақсы жазбасы бар. Бұл PostgreSQL комиссарларының бірі. Төменгі деңгейлі гиблеттердің негізгі әзірлеушілерінің бірі. Егер сіз осы жазбадағы сілтемелерді орындасаңыз, олар NUMA-ның адамдардың өмірін қалай қиындатқаны туралы бірнеше түрлі-түсті оқиғаларды сипаттайды. Қараңыз, біздің дерекқорымыз жақсы жұмыс істеуі үшін серверде не конфигурациялануы керек екенін жүйелік әкімші бақылау тізімін зерттеңіз. Бұл параметрлерді жазып алып, тексеру керек, әйтпесе бұл өте жақсы болмайды.
Бұл мен айтатын барлық параметрлерге қатысты екенін ескеріңіз. Бірақ әдетте дерекқорлар ақауларға төзімділік үшін негізгі-құлдық режимде жиналады. Бұл параметрлерді құлға орнатуды ұмытпаңыз, өйткені бір күні сіз апатқа ұшырайсыз және сіз құлға ауысасыз және ол қожайын болады.
Төтенше жағдайда, бәрі өте нашар болғанда, телефоныңыз үнемі шырылдап, бастығыңыз үлкен таяқпен жүгіріп келгенде, тексеру туралы ойлауға уақытыңыз болмайды. Және нәтижелер өте қайғылы болуы мүмкін.
Келесі нүкте - үлкен беттер. Үлкен беттерді бөлек сынау қиын және мұны істеудің қажеті жоқ, бірақ мұны жасай алатын эталондар бар. Олар Google-ге оңай.
Мұның мәні неде? Сізде өте қымбат емес сервер бар, мысалы, 30 ГБ-тан астам жедел жады бар. Сіз үлкен беттерді пайдаланбайсыз. Бұл жадты пайдалану тұрғысынан сізде міндетті түрде артық шығын бар екенін білдіреді. Және бұл үстеме шығындар ең жағымдыдан алыс.
Неге бұлай? Сонымен, не болып жатыр? Операциялық жүйе жадты шағын бөліктерге бөледі. Бұл өте ыңғайлы, бұл тарихи түрде болған. Ал егжей-тегжейлі қарастыратын болсақ, ОЖ виртуалды мекенжайларды физикалық мекенжайларға аударуы керек. Және бұл процесс ең қарапайым емес, сондықтан ОЖ бұл әрекеттің нәтижесін Translation Lookaside буферінде (TLB) кэштейді.
Ал TLB кэш болғандықтан, кэшке тән барлық мәселелер осы жағдайда туындайды. Біріншіден, егер сізде ЖЖҚ көп болса және оның барлығы шағын бөліктерге бөлінген болса, онда бұл буфер өте үлкен болады. Ал егер кэш үлкен болса, ол арқылы іздеу баяуырақ болады. Үстіңгі жүктеме сау және өзі орын алады, яғни ЖЖҚ дұрыс емес нәрсеге жұмсалуда. Бұл жолы.
Екі - мұндай жағдайда кэш өскен сайын, кэшті жіберіп алу ықтималдығы соғұрлым жоғары болады. Және бұл кэштің тиімділігі оның көлемі ұлғайған сайын тез төмендейді. Сондықтан операциялық жүйелер қарапайым тәсілмен келді. Ол Linux жүйесінде ұзақ уақыт бойы қолданылған. Ол жақында FreeBSD-де пайда болды. Бірақ біз Linux туралы айтып отырмыз. Бұл үлкен беттер.
Бұл жерде үлкен беттерді идея ретінде бастапқыда Oracle және IBM кіретін қауымдастықтар итермелегенін атап өту керек, яғни дерекқор өндірушілері бұл дерекқорлар үшін де пайдалы болады деп қатты ойлады.
Мұны PostgreSQL-пен қалай достастыруға болады? Біріншіден, Linux ядросында үлкен беттер қосулы болуы керек.
Екіншіден, олар sysctl параметрімен анық көрсетілуі керек - олардың саны қанша. Мұндағы сандар ескі серверден алынған. Үлкен беттер сол жерге сыйуы үшін сізде қанша ортақ буфер бар екенін есептей аласыз.
Ал егер сіздің бүкіл серверіңіз PostgreSQL-ге арналған болса, онда ЖЖҚ-ның 25%-ын ортақ буферлерге бөлу немесе дерекқорыңыздың осы 75%-ға міндетті түрде сәйкес келетініне сенімді болсаңыз, 75%-ын бөлу жақсы бастама болып табылады. Бірінші нүкте. Егер сізде 256 ГБ жедел жады болса, сәйкесінше сізде 64 ГБ үлкен буфер болады. Шамамен белгілі бір маржамен есептеңіз - бұл сан нені орнату керек.
9.2 нұсқасына дейін (қателеспесем, 8.2 нұсқасынан бастап) PostgreSQL-ті үшінші тарап кітапханасының көмегімен үлкен беттермен қосу мүмкін болды. Және бұл әрқашан жасалуы керек. Біріншіден, үлкен беттерді дұрыс бөлу үшін ядро қажет. Екіншіден, олармен жұмыс істейтін қолданба оларды пайдалана алады. Ол жай ғана осылай пайдаланылмайды. PostgreSQL жадты жүйе 5 стилінде бөлгендіктен, мұны libhugetlbfs көмегімен жасауға болады - бұл кітапхананың толық атауы.
9.3-те жадпен жұмыс істегенде PostgreSQL өнімділігі жақсарды және жүйе 5 жадты бөлу әдісінен бас тартылды. Барлығы өте риза болды, өйткені әйтпесе сіз бір машинада екі PostgreSQL данасын іске қосуға тырысасыз және ол менің ортақ жадым жеткіліксіз екенін айтады. Және ол sysctl түзету керек дейді. Және осындай жүйе бар, сіз әлі қайта жүктеуіңіз керек және т.б. Жалпы алғанда, барлығы бақытты болды. Бірақ mmap жадын бөлу үлкен беттерді пайдалануды бұзды. Біздің клиенттеріміздің көпшілігі үлкен ортақ буферлерді пайдаланады. Біз 9.3-ке ауыспауды қатаң түрде ұсындық, өйткені онда үстеме шығындар жақсы пайызбен есептеле бастады.
Бірақ қауымдастық бұл мәселеге назар аударды және 9.4-те бұл оқиғаны өте жақсы өңдеді. Ал 9.4-те postgresql.conf файлында параметр пайда болды, оны қосуға немесе өшіруге болады.
Байқау - ең қауіпсіз нұсқа. PostgreSQL іске қосылғанда, ол ортақ жадты бөлгенде, бұл жадты үлкен беттерден алуға тырысады. Егер ол жұмыс істемесе, ол қалыпты таңдауға оралады. Егер сізде FreeBSD немесе Solaris болса, сынап көруіңізге болады, ол әрқашан қауіпсіз.
Егер қосулы болса, үлкен беттерден таңдай алмаса, ол жай ғана іске қосылмайды. Мұнда кім және не жақсы екені туралы қазірдің өзінде. Бірақ егер сіз тырысып көрген болсаңыз, онда сізде бөлектелген нәрсе бар-жоғын тексеріңіз, себебі қатеге көп орын бар. Қазіргі уақытта бұл функция тек Linux жүйесінде жұмыс істейді.
Әрі қарай жүрмес бұрын тағы бір шағын ескерту. Мөлдір үлкен беттер әлі PostgreSQL туралы емес. Ол оларды қалыпты түрде пайдалана алмайды. Осындай жұмыс жүктемесіне арналған Transparent үлкен беттермен ортақ жадтың үлкен бөлігі қажет болғанда, артықшылықтар өте үлкен көлемде ғана келеді. Егер сізде терабайт жад болса, бұл ойынға келуі мүмкін. Егер біз күнделікті қосымшалар туралы айтатын болсақ, сіздің құрылғыңызда 32, 64, 128, 256 ГБ жады болған кезде, әдеттегі үлкен беттер жақсы болады және біз Transparent функциясын өшіреміз.
Ал есте сақтау туралы соңғы нәрсе жеміске тікелей байланысты емес, ол сіздің өміріңізді шынымен бұзуы мүмкін. Сервердің үнемі ауыстырып отыруы барлық өткізу қабілетіне қатты әсер етеді.
Және бұл бірнеше жағынан өте жағымсыз болады. Ал негізгі мәселе қазіргі ядролардың ескі Linux ядроларынан сәл өзгеше әрекет етуінде. Және бұл нәрсеге қадам басу өте жағымсыз, өйткені біз своппен жұмыстың қандай да бір түрі туралы айтатын болсақ, ол OOM-киллердің уақтылы келмеуімен аяқталады. Ал дер кезінде келмей, PostgreSQL-ті түсіріп алған OOM-киллер жағымсыз. Бұл туралы бәрі біледі, яғни соңғы пайдаланушыға дейін.
Не болып жатыр? Сізде үлкен көлемдегі жедел жады бар, бәрі жақсы жұмыс істейді. Бірақ қандай да бір себептермен сервер свопта тұрып қалады және осыған байланысты баяулайды. Жад көп сияқты көрінеді, бірақ бұл орын алады.
Бұрын біз vm.swappiness параметрін нөлге орнатуға кеңес бердік, яғни свопты өшіру. Бұрын 32 ГБ жедел жады және сәйкес ортақ буферлер үлкен сома болып көрінетін. Своптың негізгі мақсаты - егер біз құлап қалсақ, жер қыртысын тастайтын орынға ие болу. Және ол енді ерекше орындалмады. Ал содан кейін бұл қыртыспен не істейсіз? Бұл своптың не үшін қажет екені анық емес тапсырма, әсіресе мұндай көлемде.
Бірақ қазіргі заманғы, яғни ядроның үшінші нұсқаларында мінез-құлық өзгерді. Егер сіз свопты нөлге орнатсаңыз, яғни оны өшірсеңіз, ерте ме, кеш пе, тіпті кейбір жедел жады қалса да, сізге ең қарқынды тұтынушыларды өлтіру үшін OOM өлтірушісі келеді. Өйткені ол мұндай жұмыс жүктемесінде бізде әлі де аз ғана қалды және біз секіреміз, яғни жүйелік процесті шегелеу үшін емес, маңызды емес нәрсені шегелейміз деп санайды. Бұл маңызды емес нәрсе ортақ жадтың қарқынды тұтынушысы болады, атап айтқанда пошта меңгерушісі. Ал содан кейін базаны қалпына келтірудің қажеті болмаса, жақсы болады.
Сондықтан, қазір әдепкі бойынша, менің есімде, дистрибутивтердің көпшілігі шамамен 6-да, яғни қанша жадтың қалғанына байланысты свопты қай уақыттан бастау керек. Енді vm.swappiness = 1 параметрін орнатуды ұсынамыз, себебі бұл іс жүзінде оны өшіреді, бірақ күтпеген жерден келіп, барлығын өлтіретін OOM-киллермен бірдей әсерлерді бермейді.
Ары қарай не? Мәліметтер базасының өнімділігі туралы айтып, бірте-бірте дискілерге көшкенде, бәрі бастарын ұстай бастайды. Өйткені дискінің баяу, жадының тез болатыны баршаға бала кезінен таныс. Дерекқорда дискінің өнімділігі проблемалары болатынын бәрі біледі.
Бақылау нүктелерінің жоғарылауымен байланысты негізгі PostgreSQL өнімділігі мәселесі диск баяу болғандықтан пайда болмайды. Бұл, ең алдымен, жад пен диск өткізу қабілетінің теңгерілмегендігіне байланысты. Дегенмен, олар әртүрлі жерлерде теңгерімсіз болуы мүмкін. PostgreSQL конфигурацияланбаған, ОЖ конфигурацияланбаған, аппараттық құрал конфигурацияланбаған және аппараттық құрал дұрыс емес. Және бұл мәселе бәрі дұрыс болған жағдайда ғана болмайды, яғни жүктеме болмаса немесе параметрлер мен жабдық дұрыс таңдалған.
Бұл не және ол қалай көрінеді? Әдетте PostgreSQL-пен жұмыс істейтін адамдар бұл мәселеге бірнеше рет кірген. Мен түсіндіремін. Мен айтқанымдай, PostgreSQL мезгіл-мезгіл ортақ жадтағы лас беттерді дискіге тастау үшін бақылау нүктелерін жасайды. Егер бізде ортақ жадтың үлкен көлемі болса, онда бақылау нүктесі дискіге қарқынды әсер ете бастайды, өйткені ол бұл беттерді fsync көмегімен тастайды. Ол ядро буферіне келеді және fsync көмегімен дискілерге жазылады. Ал егер бұл бизнестің көлемі үлкен болса, онда жағымсыз әсерді, атап айтқанда дискілерді өте үлкен пайдалануды байқауға болады.
Міне, менде екі сурет бар. Мен қазір оның не екенін түсіндіремін. Бұл екі уақыттық корреляциялық графиктер. Бірінші график - дискіні пайдалану. Мұнда ол қазіргі уақытта шамамен 90% жетеді. Егер сізде RAID контроллері 90% пайдаланылған физикалық дискілермен дерекқор ақаулығы болса, бұл жағымсыз жаңалық. Бұл сәл артық және ол 100-ге жетеді және енгізу/шығару тоқтайды дегенді білдіреді.
Егер сізде диск массиві болса, онда бұл сәл басқаша оқиға. Бұл оның қалай конфигурацияланғанына, қандай массив екеніне және т.б. байланысты.
Сонымен қатар, бұл жерде бақылау нүктесінің қалай болатынын көрсететін ішкі postgres көрінісінен график конфигурацияланған. Ал мұндағы жасыл түс синхрондау үшін осы бақылау нүктесіне қанша буфер, осы лас беттер келгенін көрсетеді. Және бұл жерде сіз білуіңіз керек басты нәрсе. Бұл жерде бізде көптеген беттер бар екенін және бір сәтте біз тақтаға түсетінін, яғни жазғанымызды және жазғанымызды көреміз, мұнда диск жүйесі өте бос емес. Ал біздің бақылау-өткізу пункті дискіге өте күшті әсер етеді. Ең дұрысы, жағдай осылайша көрінуі керек, яғни бұл жерде бізде аз жазылу болды. Және біз оны параметрлер арқылы түзете аламыз, осылайша ол осылай бола береді. Яғни, қайта өңдеу аз, бірақ бір жерде біз осында бірдеңе жазып жатырмыз.
Бұл проблеманы жеңу үшін не істеу керек? Егер сіз дерекқор астында IO-ны тоқтатқан болсаңыз, бұл өз сұрауларын орындауға келген барлық пайдаланушылар күтетінін білдіреді.
Егер сіз Linux тұрғысынан қарасаңыз, егер сіз жақсы жабдықты алсаңыз, оны дұрыс конфигурацияласаңыз, PostgreSQL-ті қалыпты түрде конфигурацияласаңыз, бұл бақылау нүктелерін жиірек ететіндей етіп, оларды бір-біріне уақыт өте келе таратады, содан кейін сіз әдепкі Debian параметрлеріне кіресіз. Көптеген Linux дистрибутивтері үшін бұл сурет: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Бұл нені білдіреді? 2.6 ядросынан бір қызарған жын пайда болды. Pdglush, кімнің қайсысын пайдаланып жатқанына байланысты, ол ядро буферінен лас беттерді фондық тастаумен айналысады және лас беттерді қандай жағдайда да тастау қажет болғанда, фондық бағдарламаны тастау көмектеспейді.
Фон қашан келеді? Серверде қол жетімді жалпы ЖЖҚ-ның 10%-ын ядро буферіндегі лас беттер алып жатқанда, фондық режимде арнайы есептен шығару функциясы шақырылады. Неліктен бұл фон? Параметр ретінде қанша бетті есептен шығару керектігі ескеріледі. Ал, айталық, ол N бетті жазып тастайды. Ал бұл нәрсе біраз уақыт ұйықтап қалады. Содан кейін ол қайтадан келіп, тағы бірнеше бетті көшіреді.
Бұл өте қарапайым оқиға. Бұл жерде мәселе бассейндегідей, ол бір құбырға құйса, екіншісіне ағып кетеді. Біздің бақылау-өткізу пункті келді және егер ол бірнеше лас беттерді тастауға жіберсе, онда бірте-бірте барлық нәрсе pgflush ядро буферінен ұқыпты шешіледі.
Егер бұл лас беттер жинала берсе, олар 20% дейін жинақталады, содан кейін ОЖ басымдылығы барлық нәрсені дискіге жазу болып табылады, өйткені қуат тоқтап, біз үшін бәрі нашар болады. Біз, мысалы, бұл деректерді жоғалтамыз.
Қандай айла? Қиындық мынада, қазіргі әлемдегі бұл параметрлер машинадағы жалпы жедел жадтың 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.
Және олар сіздің өміріңізді қалай бұзады? Жоспарлы_тасымалдау_құны дегеніміз не? Linux жүйесінде жоспарлаушы процесті бір процессордан екіншісіне тасымалдай алады. Ал сұрауларды орындайтын PostgreSQL үшін басқа процессорға көшу мүлдем түсініксіз. Операциялық жүйе тұрғысынан, терезелерді openoffice және терминал арасында ауыстырған кезде, бұл жақсы болуы мүмкін, бірақ дерекқор үшін бұл өте нашар. Сондықтан, ақылға қонымды саясат - migration_cost параметрін кейбір үлкен мәнге, кем дегенде бірнеше мың наносекундқа орнату.
Бұл жоспарлаушы үшін нені білдіреді? Осы уақыт ішінде процесс әлі де ыстық деп есептелетін болады. Яғни, сізде ұзақ уақыт бойы бірдеңе жасап келе жатқан транзакция болса, жоспарлаушы мұны түсінеді. Ол бұл күту уақыты өткенше бұл процесті ешқайда көшірудің қажеті жоқ деп есептейді. Егер процесс бір уақытта бірдеңе жасаса, онда ол ешқайда тасымалданбайды, ол оған бөлінген процессорда тыныш жұмыс істейді. Және нәтиже тамаша.
Екінші нүкте - автотоп. Қазіргі дерекқорларға қатысы жоқ нақты жұмыс жүктемелері үшін жақсы идея бар - бұл процесстерді олар іске қосылған виртуалды терминал бойынша топтау. Бұл кейбір тапсырмалар үшін ыңғайлы. Іс жүзінде PostgreSQL - бұл бір терминалдан жұмыс істейтін префоркты көп процесстік жүйе. Сізде құлыптау жазушысы, бақылау нүктесі бар және сіздің барлық клиенттік сұрауларыңыз бір CPU үшін бір жоспарлаушыға топтастырылады. Және олар бір-біріне араласып, оны ұзақ уақыт бойы жұмыста ұстау үшін оның бос болуын бірге күтеді. Бұл мұндай жүктеме болған жағдайда мүлдем қажет емес әңгіме, сондықтан оны өшіру керек.
Менің әріптесім Алексей Лесовский қарапайым pgbench көмегімен сынақтар жасады, онда ол migration_cost-ті шама бойынша арттырды және автотопты өшірді. Нашар жабдықтағы айырмашылық шамамен 10% болды. Postgres тарату тізімінде адамдар сұрау жылдамдығына ұқсас өзгерістердің нәтижелерін беретін талқылау бар 50% әсер етті. Мұндай әңгімелер өте көп.
Соңында, қуат үнемдеу саясаты туралы. Бір жақсысы, Linux енді ноутбукте де қолданыла алады. Және ол аккумуляторды жақсы пайдаланады деген болжам бар. Бірақ кенеттен бұл серверде де болуы мүмкін екені белгілі болды.
Сонымен қатар, егер сіз серверлерді қандай да бір хосттерден жалға алсаңыз, «жақсы» хостерлер сіздің өнімділігіңіз жақсы екеніне мән бермейді. Олардың міндеті - темірді мүмкіндігінше тиімді пайдалануды қамтамасыз ету. Сондықтан, әдепкі бойынша олар амалдық жүйеде ноутбук қуатын үнемдеу режимін қоса алады.
Егер сіз бұл материалды дерекқоры ауыр жүктемеде серверде пайдалансаңыз, сіздің таңдауыңыз acpi_cpufreq + permormance болып табылады. Сұраныс болса да проблемалар болады.
Intel_pstate - сәл басқа драйвер. Енді осыған артықшылық беріледі, өйткені ол кейінірек және жақсы жұмыс істейді.
Және, тиісінше, губернатор тек орындау болып табылады. Талап, қуат үнемдеу және басқаның бәрі сізге қатысты емес.
Түсіндіру талдауының нәтижелері PostgreSQL қуатын үнемдеуді қоссаңыз, бірнеше ретпен ерекшеленуі мүмкін, себебі дерекқор астындағы процессор іс жүзінде болжау мүмкін емес түрде жұмыс істейді.
Бұл элементтер әдепкі бойынша қосылуы мүмкін. Оның әдепкі бойынша қосылғанын білу үшін мұқият қараңыз. Бұл шынымен үлкен мәселе болуы мүмкін.
Соңында мен PosgreSQL-Consulting DBA командасының жігіттеріне, атап айтқанда Макс Богук пен Алексей Лесовскийге алғыс айтқым келді, олар бұл мәселеде күн сайын алға жылжып келеді. Біз өз клиенттеріміз үшін қолдан келгеннің бәрін жасауға тырысамыз, сонда бәрі олар үшін жұмыс істейді. Бұл авиациялық қауіпсіздік нұсқаулары сияқты. Мұнда бәрі қанмен жазылған. Бұл жаңғақтардың әрқайсысы қандай да бір мәселенің процесінде кездеседі. Мен оларды сіздермен бөлісуге қуаныштымын.
Сұрақтар:
Рақмет сізге! Мысалы, компания ақшаны үнемдеп, дерекқор мен қолданба логикасын бір серверге орналастырғысы келсе немесе компания PostgreSQL контейнерде жұмыс істейтін микросервис архитектурасының сәнді үрдісін ұстанса. Қандай айла? Sysctl бүкіл ядроға жаһандық әсер етеді. Мен sysctls контейнерде бөлек жұмыс істейтіндей етіп виртуализацияланғанын естіген жоқпын. Онда тек топ бар, бақылаудың бір бөлігі ғана. Сіз мұнымен қалай өмір сүре аласыз? Немесе өнімділікті қаласаңыз, PostgreSQL-ті бөлек аппараттық серверде іске қосып, оны баптаңыз ба?
Біз сіздің сұрағыңызға үш жолмен жауап бердік. Егер біз реттеуге болатын аппараттық сервер және т.б. туралы айтпасақ, демалыңыз, бұл параметрлерсіз бәрі жақсы жұмыс істейді. Егер сізде осы параметрлерді жасау қажет болатын жүктеме болса, онда сіз темір серверіне осы параметрлерге қарағанда ертерек келесіз.
Мәселе неде? Егер бұл виртуалды машина болса, онда сізде көптеген мәселелер туындауы мүмкін, мысалы, көптеген виртуалды машиналарда дискінің кідіріс уақыты мүлдем сәйкес келмейтіндігімен байланысты. Дискінің өткізу қабілеті жақсы болса да, бақылау нүктесі кезінде немесе WAL-ге жазу кезінде орын алған орташа өткізу қабілетіне айтарлықтай әсер етпейтін бір сәтсіз енгізу/шығару транзакциясы, одан деректер базасы үлкен зардап шегеді. Сіз бұл проблемаларға тап болғанға дейін мұны байқайсыз.
Бір серверде NGINX болса, сізде де бірдей мәселе болады. Ол ортақ есте сақтау үшін күреседі. Сіз мұнда сипатталған мәселелерге жете алмайсыз.
Бірақ екінші жағынан, бұл параметрлердің кейбірі әлі де сізге қатысты болады. Мысалы, dirty_ratio параметрін sysctl көмегімен ол соншалықты ақылсыз болмайтындай етіп орнатыңыз - кез келген жағдайда бұл көмектеседі. Қалай болғанда да, сіз дискімен өзара әрекеттесетін боласыз. Және ол дұрыс емес үлгі бойынша болады. Бұл әдетте мен көрсеткен параметрлер үшін әдепкі болып табылады. Және кез келген жағдайда оларды өзгерту жақсы.
Бірақ NUMA-мен проблемалар болуы мүмкін. Мысалы, VmWare дәл қарама-қарсы параметрлермен NUMA-мен жақсы жұмыс істейді. Және мұнда таңдау керек - темір сервер немесе темір емес.
Менің Amazon AWS-ке қатысты сұрағым бар. Оларда алдын ала конфигурацияланған кескіндер бар. Олардың бірі Amazon RDS деп аталады. Олардың операциялық жүйесі үшін реттелетін параметрлер бар ма?
Онда параметрлер бар, бірақ олар басқа параметрлер. Мұнда біз операциялық жүйені дерекқор осы нәрсені қалай пайдаланатыны тұрғысынан конфигурациялаймыз. Ал қазір қайда бару керектігін анықтайтын параметрлер бар, мысалы, пішіндеу. Яғни, бізге қаншама ресурстар керек, енді оларды жеп қоямыз. Осыдан кейін Amazon RDS бұл ресурстарды қатайтады және өнімділік төмендейді. Адамдардың бұл мәселемен араласа бастағаны туралы жеке әңгімелер бар. Кейде тіпті сәтті. Бірақ бұл операциялық жүйе параметрлеріне ешқандай қатысы жоқ. Бұл бұлтты бұзу сияқты. Бұл басқа әңгіме.
Неліктен мөлдір үлкен беттер Үлкен TLB-мен салыстырғанда әсер етпейді?
Берме. Мұны көптеген жолдармен түсіндіруге болады. Бірақ іс жүзінде олар оны бермейді. PostgreSQL тарихы қандай? Іске қосу кезінде ол ортақ жадтың үлкен бөлігін бөледі. Олар мөлдір ме, жоқ па, бұл мүлдем маңызды емес. Олардың басында ерекшеленуі бәрін түсіндіреді. Ал егер жад көп болса және ортақ_жад сегментін қайта құру қажет болса, мөлдір үлкен беттер өзекті болады. PostgreSQL-де ол басында үлкен бөлікке бөлінген, содан кейін ол жерде ерекше ештеңе болмайды. Сіз, әрине, оны пайдалана аласыз, бірақ ол бірдеңені қайта бөлген кезде ортақ жадтың бұзылуы мүмкін. PostgreSQL бұл туралы білмейді.
Ақпарат көзі: www.habr.com