PostgreSQL ish faoliyatini yaxshilash uchun Linuxni sozlash. Ilya Kosmodemyanskiy

Ilya Kosmodemyanskiyning 2015 yilgi hisobotining transkripti "PostgreSQL ish faoliyatini yaxshilash uchun Linuxni sozlash"

Rad etish: Men ushbu hisobot 2015 yil noyabr oyida ekanligini ta'kidlayman - 4 yildan ortiq vaqt o'tdi va ko'p vaqt o'tdi. Hisobotda muhokama qilingan 9.4 versiyasi endi qo'llab-quvvatlanmaydi. Oxirgi 4 yil ichida PostgreSQLning 5 ta yangi relizlari va Linux yadrosining 15 ta versiyasi chiqarildi. Agar siz ushbu parchalarni qayta yozsangiz, siz boshqacha hisobotga ega bo'lasiz. Ammo bu erda biz PostgreSQL uchun Linuxni fundamental sozlashni ko'rib chiqamiz, bu bugungi kunda ham dolzarbdir.

Mening ismim Ilya Kosmodemyanskiy. Men PostgreSQL-Consulting kompaniyasida ishlayman. Va endi men Linux bilan umuman ma'lumotlar bazalari va xususan PostgreSQL bilan nima qilish kerakligi haqida bir oz gaplashaman, chunki printsiplar juda o'xshash.

Nima haqida gaplashamiz? Agar siz PostgreSQL bilan muloqot qilsangiz, ma'lum darajada siz UNIX administratori bo'lishingiz kerak. Bu nima degani? Agar biz Oracle va PostgreSQL-ni solishtirsak, Oracle-da siz 80% DBA ma'lumotlar bazasi administratori va 20% Linux administratori bo'lishingiz kerak.

PostgreSQL bilan bu biroz murakkabroq. PostgreSQL yordamida siz Linux qanday ishlashini yaxshiroq tushunishingiz kerak. Va shu bilan birga, lokomotivdan keyin biroz yuguring, chunki so'nggi paytlarda hamma narsa juda yaxshi yangilandi. Va yangi yadrolar chiqariladi va yangi funksiyalar paydo bo'ladi, ishlash yaxshilanadi va hokazo.

Nega biz Linux haqida gapirayapmiz? Biz Peter Linux konferentsiyasida bo'lganimiz uchun emas, balki zamonaviy sharoitda umuman ma'lumotlar bazalaridan va xususan PostgreSQLdan foydalanish uchun eng oqlangan operatsion tizimlardan biri Linux bo'lganligi sababli. Chunki FreeBSD, afsuski, juda g'alati yo'nalishda rivojlanmoqda. Va ishlashda ham, boshqa ko'p narsalarda ham muammolar bo'ladi. Windows-da PostgreSQL-ning ishlashi odatda alohida jiddiy muammo bo'lib, Windows-ning UNIX kabi umumiy xotiraga ega emasligiga asoslanadi, PostgreSQL esa bunga bog'liq, chunki u ko'p jarayonli tizimdir.

Va menimcha, hamma Solaris kabi ekzotiklarga kamroq qiziqadi, shuning uchun ketaylik.

Zamonaviy Linux distributivida yadroni qanday yaratishingizga qarab 1 dan ortiq syctl opsiyalari mavjud. Shu bilan birga, turli xil yong'oqlarni ko'rib chiqsak, biz ko'p jihatdan biror narsani sozlashimiz mumkin. Ularni qanday o'rnatish haqida fayl tizimi parametrlari mavjud. Agar sizda uni qanday boshlash haqida savollaringiz bo'lsa: BIOS-da nimani yoqish kerak, apparatni qanday sozlash kerak va hokazo.

Bu bir necha kun davomida muhokama qilinishi mumkin bo'lgan juda katta hajm, va bitta qisqa hisobotda emas, lekin endi men muhim narsalarga e'tibor qarataman, agar siz Linuxda ma'lumotlar bazasidan yaxshi foydalanishingizga xalaqit beradigan rakelardan qanday qochish kerak. ularni tuzatmang. Va shu bilan birga, muhim jihat shundaki, ko'plab standart parametrlar ma'lumotlar bazasi uchun to'g'ri bo'lgan sozlamalarga kiritilmagan. Ya'ni, sukut bo'yicha u yomon ishlaydi yoki umuman ishlamaydi.

Linuxda qanday an'anaviy sozlash maqsadlari mavjud? O'ylaymanki, barchangiz Linux boshqaruvi bilan shug'ullanayotganingiz uchun maqsadlar nima ekanligini tushuntirishga alohida ehtiyoj yo'q.

Siz sozlashingiz mumkin:

• MARKAZIY PROTSESSOR.
• Xotira.
• Saqlash.
• Boshqa. Biz bu haqda oxirida gazak uchun gaplashamiz. Hatto, masalan, energiya tejash siyosati kabi parametrlar ishlashga juda oldindan aytib bo'lmaydigan va eng yoqimli tarzda ta'sir qilishi mumkin.

PostgreSQL va umuman ma'lumotlar bazasining o'ziga xos xususiyatlari qanday? Muammo shundaki, siz biron bir yong'oqni bura olmaysiz va bizning ishlashimiz sezilarli darajada yaxshilanganini ko'rasiz.

Ha, bunday gadjetlar bor, lekin ma'lumotlar bazasi murakkab narsa. U server mavjud bo'lgan barcha resurslar bilan o'zaro ta'sir qiladi va to'liq o'zaro ta'sir qilishni afzal ko'radi. Agar siz Oracle’ning xost operatsion tizimidan qanday foydalanish bo‘yicha joriy tavsiyalarini ko‘rib chiqsangiz, bu xuddi o‘sha mo‘g‘ul kosmonavti haqidagi hazilga o‘xshab ketadi – itni boqing va hech narsaga tegmang. Keling, ma'lumotlar bazasiga barcha resurslarni beraylik, ma'lumotlar bazasining o'zi hamma narsani tartibga soladi.

Printsipial jihatdan, vaziyat qandaydir darajada PostgreSQL bilan bir xil. Farqi shundaki, ma'lumotlar bazasi hali o'zi uchun barcha resurslarni olishga qodir emas, ya'ni Linux darajasida hamma narsani o'zingiz saralashingiz kerak.

Asosiy g'oya bitta maqsadni tanlash va uni sozlashni boshlash emas, masalan, xotira, protsessor yoki shunga o'xshash narsalarni, balki ish yukini tahlil qilish va yaxshi dasturchilar tomonidan yaratilgan yukni imkon qadar oshirishga harakat qilishdir. biz uchun, shu jumladan bizning foydalanuvchilarimiz uchun.

Bu nima ekanligini tushuntirish uchun rasm. Linux OS buferi va umumiy xotira mavjud va PostgreSQL umumiy buferlari mavjud. PostgreSQL, Oracle'dan farqli o'laroq, to'g'ridan-to'g'ri faqat yadro buferi orqali ishlaydi, ya'ni diskdagi sahifa o'zining umumiy xotirasiga kirishi uchun yadro buferidan o'tishi va orqaga qaytishi kerak, xuddi shu holat.

Disklar ushbu tizim ostida yashaydi. Men buni disklar sifatida chizganman. Aslida, RAID tekshiruvi va boshqalar bo'lishi mumkin.

Va bu kirish-chiqish u yoki bu masala orqali sodir bo'ladi.

PostgreSQL - bu klassik ma'lumotlar bazasi. Ichkarida sahifa bor. Va barcha kirish va chiqish sahifalar yordamida sodir bo'ladi. Biz sahifalar bilan bloklarni xotiraga ko'tarmoqdamiz. Va agar hech narsa bo'lmagan bo'lsa, biz ularni o'qiymiz, keyin asta-sekin ular ushbu keshdan, umumiy buferlardan yo'qoladi va diskda qayta tiklanadi.

Agar biror joyda biror narsani almashtirsak, butun sahifa iflos deb belgilangan. Men ularni bu erda ko'k rang bilan belgiladim. Va bu shuni anglatadiki, ushbu sahifa blokli saqlash bilan sinxronlashtirilishi kerak. Ya'ni, biz uni iflos qilganimizda, biz WAL-ga kirishni amalga oshirdik. Va bir vaqtning o'zida qandaydir ajoyib daqiqada nazorat punkti deb ataladigan hodisa keldi. Va bu jurnalda uning kelgani haqida ma'lumot yozilgan. Va bu shuni anglatadiki, o'sha paytda bu umumiy buferlarda bo'lgan barcha iflos sahifalar yadro buferi orqali fsync yordamida saqlash diski bilan sinxronlashtirildi.

Bu nima uchun qilinmoqda? Agar biz kuchlanishni yo'qotgan bo'lsak, unda biz barcha ma'lumotlar yo'qolgan vaziyatni olmadik. Hamma bizga aytib bergan doimiy xotira, ma'lumotlar bazasi nazariyasida hozirgacha - bu biz, albatta, intilamiz va biz buni yoqtiradigan yorqin kelajakdir, ammo hozircha ular minus 20 yil ichida yashaydilar. Va, albatta, bularning barchasini kuzatib borish kerak.

Va o'tkazuvchanlikni maksimal darajada oshirish vazifasi bu bosqichlarning barchasida oldinga va orqaga tez harakatlanishi uchun nozik sozlashdir. Umumiy xotira asosan sahifa keshidir. PostgreSQL-da biz tanlangan so'rov yoki biror narsa yubordik, u bu ma'lumotlarni diskdan oldi. Ular umumiy buferlarda tugadi. Shunga ko'ra, bu yaxshi ishlashi uchun juda ko'p xotira bo'lishi kerak.

Bularning barchasi yaxshi va tez ishlashi uchun siz barcha bosqichlarda operatsion tizimni to'g'ri sozlashingiz kerak. Va muvozanatli uskunani tanlang, chunki agar sizda biron bir joyda nomutanosiblik mavjud bo'lsa, unda siz juda ko'p xotira hosil qilishingiz mumkin, ammo unga etarli tezlikda xizmat ko'rsatilmaydi.

Va keling, ushbu nuqtalarning har birini ko'rib chiqaylik.

Ushbu sahifalar tezroq oldinga va orqaga sayohat qilish uchun siz quyidagilarga erishishingiz kerak:

• Birinchidan, siz xotira bilan yanada samarali ishlashingiz kerak.
• Ikkinchidan, sahifalar xotiradan diskka o'tganda bu o'tish samaraliroq bo'lishi kerak.
• Uchinchidan, yaxshi disklar bo'lishi kerak.

Agar sizda serverda 512 Gb operativ xotira mavjud bo'lsa va ularning barchasi keshsiz SATA qattiq diskida bo'lsa, unda butun ma'lumotlar bazasi serveri nafaqat qovoqqa, balki SATA interfeysiga ega qovoqqa aylanadi. Siz to'g'ridan-to'g'ri unga duch kelasiz. Va hech narsa sizni qutqarmaydi.

Xotira bilan bog'liq birinchi nuqtaga kelsak, hayotni juda qiyinlashtiradigan uchta narsa bor.

Ulardan birinchisi NUMA. NUMA - bu ish faoliyatini yaxshilash uchun yaratilgan narsa. Ish yukiga qarab, turli xil narsalarni optimallashtirish mumkin. Va uning yangi joriy shaklida, sahifa keshini umumiy buferlardan intensiv foydalanadigan ma'lumotlar bazalari kabi ilovalar uchun unchalik yaxshi emas.

Qisqasini etkanda. NUMA bilan nimadir noto'g'ri ekanligini qanday aniqlash mumkin? Sizda qandaydir noxush zarba bor, to'satdan ba'zi CPU haddan tashqari yuklangan. Shu bilan birga, siz PostgreSQL-da so'rovlarni tahlil qilasiz va u erda o'xshash narsa yo'qligini ko'rasiz. Bu so'rovlar CPU intensiv bo'lmasligi kerak. Siz buni uzoq vaqt ushlab turishingiz mumkin. PostgreSQL uchun NUMA ni qanday sozlash bo'yicha to'g'ri tavsiyani boshidanoq ishlatish osonroq.

Haqiqatan ham nima bo'lyapti? NUMA qisqartmasi Non-Uniform Memory Access-ni anglatadi. Buning nima keragi bor? Sizda protsessor bor, uning yonida uning mahalliy xotirasi mavjud. Va bu xotira o'zaro ulanishlari boshqa protsessorlardan xotirani tortib olishi mumkin.

Yugursang numactl --hardware, keyin siz shunday katta varaq olasiz. Boshqa narsalar qatorida masofalar maydoni ham bo'ladi. Raqamlar bo'ladi - 10-20, shunga o'xshash narsa. Bu raqamlar ushbu masofaviy xotirani olish va uni mahalliy sifatida ishlatish uchun hops sonidan boshqa narsa emas. Aslida, yaxshi fikr. Bu turli xil ish yuklari ostida ishlashni tezlashtiradi.

Endi tasavvur qiling-a, sizda bitta protsessor bor, avvalo uning mahalliy xotirasidan foydalanishga harakat qiladi, keyin biror narsa uchun o'zaro ulanish orqali boshqa xotirani olishga harakat qiladi. Va bu protsessor sizning butun PostgreSQL sahifa keshini oladi - bu bir necha gigabayt. Siz har doim eng yomon holatga duch kelasiz, chunki protsessorda odatda ushbu modulning o'zida kam xotira mavjud. Va barcha xizmat ko'rsatiladigan xotira ushbu o'zaro bog'lanishlar orqali o'tadi. Bu sekin va qayg'uli bo'lib chiqadi. Va bu tugunga xizmat ko'rsatadigan protsessoringiz doimo haddan tashqari yuklanadi. Va bu xotiraning kirish vaqti yomon, sekin. Agar siz ma'lumotlar bazasi uchun foydalanayotgan bo'lsangiz, bu siz istamaydigan holat.

Shuning uchun, ma'lumotlar bazasi uchun to'g'riroq variant Linux operatsion tizimining u erda nima sodir bo'layotganini umuman bilmasligidir. Shunday qilib, u xotiraga xuddi shunday kirishi uchun.

Nega bunday? Bu aksincha bo'lishi kerakdek tuyuladi. Bu bitta oddiy sababga ko'ra sodir bo'ladi: sahifa keshi uchun bizga juda ko'p xotira kerak - o'nlab, yuzlab gigabayt.

Va agar biz bularning barchasini ajratsak va u erda ma'lumotlarimizni keshlashtirsak, keshdan foydalanishdan olingan daromad xotiraga bunday qiyin kirishdan ko'ra sezilarli darajada katta bo'ladi. Shunday qilib, biz NUMA yordamida xotiraga yanada samarali kirishimiz bilan solishtirganda beqiyos foyda olamiz.

Shuning uchun, hozirda bu erda ikkita yondashuv mavjud, yorqin kelajak kelgunga qadar va ma'lumotlar bazasining o'zi qaysi protsessorlarda ishlayotganini va qaerdan nimanidir tortib olish kerakligini aniqlay olmaydi.

Shuning uchun, to'g'ri yondashuv NUMA-ni butunlay o'chirib qo'yishdir, masalan, qayta ishga tushirilganda. Ko'pgina hollarda, yutuq shunchalik katta bo'ladiki, qaysi biri yaxshiroq degan savol tug'ilmaydi.

Boshqa variant ham bor. Biz uni birinchisiga qaraganda tez-tez ishlatamiz, chunki mijoz bizga yordam so'rab kelganida, serverni qayta ishga tushirish uning uchun katta ishdir. U yerda biznesi bor. Va ular NUMA tufayli muammolarga duch kelishadi. Shuning uchun, biz uni qayta ishga tushirishdan ko'ra kamroq invaziv usullar bilan o'chirishga harakat qilamiz, lekin uning o'chirilganligini tekshirish uchun ehtiyot bo'ling. Chunki, tajriba shuni ko'rsatadiki, biz PostgreSQL-ning asosiy jarayonida NUMA-ni o'chirib qo'yganimiz ma'qul, lekin u ishlashi shart emas. Biz tekshirishimiz va u haqiqatan ham o'chirilganligini ko'rishimiz kerak.

Robert Haasning yaxshi posti bor. Bu PostgreSQL komitentlaridan biri. Barcha past darajadagi gibletlarning asosiy ishlab chiquvchilaridan biri. Va agar siz ushbu postdagi havolalarga rioya qilsangiz, ular NUMA odamlarning hayotini qanday qiyinlashtirgani haqida bir nechta rang-barang hikoyalarni tasvirlaydi. Bizning ma'lumotlar bazasi yaxshi ishlashi uchun serverda nima sozlanishi kerakligi haqida tizim ma'muri nazorat ro'yxatini o'rganing. Ushbu sozlamalarni yozib olish va tekshirish kerak, chunki aks holda bu juda yaxshi bo'lmaydi.

E'tibor bering, bu men gaplashadigan barcha sozlamalarga tegishli. Ammo odatda ma'lumotlar bazalari xatolarga chidamlilik uchun master-slave rejimida to'planadi. Qulda bu sozlamalarni o'rnatishni unutmang, chunki bir kun siz baxtsiz hodisaga duch kelasiz va siz qulga o'tasiz va u xo'jayin bo'ladi.

Favqulodda vaziyatda, hamma narsa juda yomon bo'lsa, telefoningiz doimo jiringlaydi va xo'jayiningiz katta tayoq bilan yugurib kelsa, tekshirish haqida o'ylashga vaqtingiz bo'lmaydi. Va natijalar juda halokatli bo'lishi mumkin.

Keyingi nuqta - katta sahifalar. Katta sahifalarni alohida sinab ko'rish qiyin va buni amalga oshirishning ma'nosi yo'q, garchi buni amalga oshiradigan mezonlar mavjud. Ular Google uchun oson.

Buning nima keragi bor? Sizda juda ko'p RAMga ega, masalan, 30 GB dan ortiq bo'lgan unchalik qimmat bo'lmagan serveringiz bor. Siz katta sahifalardan foydalanmaysiz. Bu shuni anglatadiki, sizda xotiradan foydalanish bo'yicha aniq yuk bor. Va bu yuk eng yoqimli narsadan uzoqdir.

Nega bunday? Xo'sh, nima bo'lyapti? Operatsion tizim xotirani kichik qismlarga ajratadi. Bu juda qulay, bu tarixan qanday sodir bo'lgan. Va agar biz batafsil ma'lumotga ega bo'lsak, OS virtual manzillarni jismoniy manzillarga tarjima qilishi kerak. Va bu jarayon eng oddiy emas, shuning uchun OS ushbu operatsiya natijasini Translation Lookaside Buferida (TLB) keshlaydi.

Va TLB kesh bo'lganligi sababli, keshga xos bo'lgan barcha muammolar bu holatda paydo bo'ladi. Birinchidan, agar sizda juda ko'p operativ xotira bo'lsa va ularning barchasi kichik qismlarga ajratilgan bo'lsa, unda bu bufer juda katta bo'ladi. Va agar kesh katta bo'lsa, u orqali qidirish sekinroq bo'ladi. Yuqori yuk sog'lom va uning o'zi joy egallaydi, ya'ni RAM noto'g'ri narsa tomonidan iste'mol qilinmoqda. Bu safar.

Ikkita - bunday vaziyatda kesh qanchalik ko'p o'ssa, sizda kesh o'tkazib yuborish ehtimoli shunchalik yuqori bo'ladi. Va bu keshning samaradorligi uning hajmi oshgani sayin tezda pasayadi. Shuning uchun operatsion tizimlar oddiy yondashuv bilan chiqdi. U Linuxda uzoq vaqtdan beri ishlatilgan. Bu yaqinda FreeBSD-da paydo bo'ldi. Ammo biz Linux haqida gapiramiz. Bu katta sahifalar.

Shuni ta'kidlash kerakki, ulkan sahifalar g'oya sifatida dastlab Oracle va IBMni o'z ichiga olgan jamoalar tomonidan ilgari surilgan, ya'ni ma'lumotlar bazasi ishlab chiqaruvchilari bu ma'lumotlar bazalari uchun ham foydali bo'ladi deb o'ylashgan.

Qanday qilib buni PostgreSQL bilan do'stlash mumkin? Birinchidan, Linux yadrosida katta sahifalar yoqilgan bo'lishi kerak.

Ikkinchidan, ular sysctl parametri bilan aniq ko'rsatilishi kerak - ularning soni qancha. Bu yerdagi raqamlar eski serverdan olingan. Katta sahifalar joylashishi uchun sizda qancha umumiy bufer borligini hisoblashingiz mumkin.

Va agar sizning butun serveringiz PostgreSQL-ga bag'ishlangan bo'lsa, unda yaxshi boshlanish nuqtasi RAMning 25 foizini umumiy buferlarga yoki ma'lumotlar bazasi ushbu 75 foizga mos kelishiga ishonchingiz komil bo'lsa, 75 foizini ajratishdir. Boshlanish nuqtasi birinchi. Va o'ylab ko'ring, agar sizda 256 GB operativ xotira bo'lsa, demak, sizda 64 GB katta bufer bo'ladi. Taxminan bir oz chegara bilan hisoblang - bu raqam nimaga o'rnatilishi kerak.

9.2 versiyasidan oldin (agar xato qilmasam, 8.2 versiyasidan boshlab) PostgreSQL-ni uchinchi tomon kutubxonasi yordamida ulkan sahifalar bilan ulash mumkin edi. Va buni har doim qilish kerak. Birinchidan, katta sahifalarni to'g'ri taqsimlash uchun yadro kerak. Ikkinchidan, ular bilan ishlaydigan dastur ulardan foydalanishi uchun. U shunchaki shunday ishlatilmaydi. PostgreSQL xotirani tizim 5 uslubida ajratganligi sababli, buni libhugetlbfs yordamida amalga oshirish mumkin - bu kutubxonaning to'liq nomi.

9.3 da PostgreSQL xotira bilan ishlashda unumdorlik yaxshilandi va tizim 5 xotirasini ajratish usulidan voz kechildi. Hamma juda xursand edi, chunki aks holda siz bitta mashinada ikkita PostgreSQL nusxasini ishga tushirishga harakat qilasiz va u mening umumiy xotiram etarli emasligini aytdi. Va u sysctl ni tuzatish kerakligini aytadi. Va shunday sysctl borki, siz hali ham qayta ishga tushirishingiz kerak va hokazo. Umuman olganda, hamma xursand edi. Ammo mmap xotirasini ajratish katta sahifalardan foydalanishni buzdi. Aksariyat mijozlarimiz katta umumiy buferlardan foydalanadilar. Va biz 9.3 ga o'tmaslikni qat'iy tavsiya qildik, chunki u erda qo'shimcha xarajatlar yaxshi foizlarda hisoblana boshladi.

Ammo jamiyat bu muammoga e'tibor qaratdi va 9.4 da bu voqeani juda yaxshi qayta ishladi. 9.4 da postgresql.conf da parametr paydo bo'ldi, unda siz sinash, yoqish yoki o'chirishni yoqishingiz mumkin.

Sinab ko'ring - eng xavfsiz variant. PostgreSQL ishga tushganda, umumiy xotira ajratilganda, u bu xotirani katta sahifalardan tortib olishga harakat qiladi. Va agar u ishlamasa, u odatdagi tanlovga qaytadi. Agar sizda FreeBSD yoki Solaris bo'lsa, sinab ko'rishingiz mumkin, bu har doim xavfsiz.

Agar yoqilgan bo'lsa, u katta sahifalardan tanlay olmasa, u shunchaki boshlamaydi. Bu erda allaqachon kim va nima yoqimli ekanligi haqida. Agar siz sinab ko'rgan bo'lsangiz, haqiqatan ham ta'kidlangan narsangiz borligini tekshiring, chunki xato qilish uchun juda ko'p joy bor. Hozirda bu funksiya faqat Linuxda ishlaydi.

Oldinga borishdan oldin yana bir kichik eslatma. Shaffof ulkan sahifalar hali PostgreSQL haqida emas. U ularni odatdagidek ishlata olmaydi. Va bunday ish yuki uchun Transparent ulkan sahifalari bilan, umumiy xotiraning katta qismi kerak bo'lganda, foyda faqat juda katta hajmlarda keladi. Agar sizda terabayt xotira bo'lsa, bu o'yinga kirishi mumkin. Agar biz ko'proq kundalik ilovalar haqida gapiradigan bo'lsak, kompyuteringizda 32, 64, 128, 256 GB xotira mavjud bo'lsa, odatdagidek katta sahifalar OK bo'ladi va biz Shaffofni o'chirib qo'yamiz.

Va xotira haqida oxirgi narsa to'g'ridan-to'g'ri fruitut bilan bog'liq emas, u, albatta, hayotingizni buzishi mumkin. Server doimiy ravishda almashtirilishi barcha o'tkazish qobiliyatiga katta ta'sir qiladi.

Va bu bir necha jihatdan juda yoqimsiz bo'ladi. Va asosiy muammo shundaki, zamonaviy yadrolar eski Linux yadrolaridan biroz farq qiladi. Va bu narsaga qadam qo'yish juda yoqimsiz, chunki biz almashtirish bilan qandaydir ish haqida gapirganda, bu OOM qotilining o'z vaqtida kelishi bilan tugaydi. Va o'z vaqtida kelmagan va PostgreSQL-ni tashlab ketgan OOM-qotil yoqimsiz. Bu haqda hamma biladi, ya'ni oxirgi foydalanuvchigacha.

Nima bo'lyapti? U erda sizda katta hajmdagi RAM bor, hamma narsa yaxshi ishlaydi. Lekin negadir server almashtirishda osilib qoladi va shu sababli sekinlashadi. Xotira juda ko'pga o'xshaydi, lekin bu sodir bo'ladi.

Ilgari biz vm.swappiness ni nolga o'rnatishni, ya'ni almashtirishni o'chirishni maslahat bergan edik. Ilgari, 32 GB operativ xotira va mos keladigan umumiy buferlar juda katta miqdor bo'lib tuyulardi. Almashtirishning asosiy maqsadi, agar biz yiqilib tushsak, qobiqni tashlash uchun joyga ega bo'lishdir. Va u endi ayniqsa bajarilmadi. Va keyin bu qobiq bilan nima qilmoqchisiz? Bu, ayniqsa, bunday o'lchamdagi almashtirish nima uchun kerakligi juda aniq bo'lmagan vazifadir.

Ammo zamonaviyroq, ya'ni yadroning uchinchi versiyalarida xatti-harakatlar o'zgargan. Va agar siz almashtirishni nolga qo'ygan bo'lsangiz, ya'ni uni o'chirib qo'ysangiz, ertami-kechmi, bir oz RAM qolgan bo'lsa ham, eng intensiv iste'molchilarni o'ldirish uchun sizga OOM qotili keladi. Chunki u bunday ish yuki bilan bizda hali oz narsa qolganligini va biz sakrab chiqamiz, ya'ni tizim jarayonini mixlash uchun emas, balki unchalik muhim bo'lmagan narsani mixlash uchun o'ylaydi. Bu unchalik muhim bo'lmagani umumiy xotiraning intensiv iste'molchisi, ya'ni postmaster bo'ladi. Va bundan keyin bazani qayta tiklash kerak bo'lmasa yaxshi bo'ladi.

Shuning uchun, endi sukut bo'yicha, esimda, ko'pchilik tarqatishlar 6 atrofida, ya'ni qancha xotira qolganiga qarab almashtirishni qaysi nuqtadan boshlash kerak. Endi biz vm.swappiness = 1 ni o'rnatishni tavsiya qilamiz, chunki bu amalda uni o'chiradi, lekin kutilmaganda kelgan va hamma narsani o'ldiradigan OOM qotilidagi kabi effektlarni bermaydi.

Keyin nima? Ma'lumotlar bazalarining ishlashi haqida gapirganda va asta-sekin disklarga o'tsak, hamma boshini ushlay boshlaydi. Chunki disk sekin, xotira esa tez degan haqiqat hammaga bolalikdan tanish. Va hamma biladiki, ma'lumotlar bazasida diskning ishlashi bilan bog'liq muammolar bo'ladi.

Tekshirish nuqtalarining keskin o'zgarishi bilan bog'liq asosiy PostgreSQL ishlash muammosi disk sekin bo'lgani uchun yuzaga kelmaydi. Bu, ehtimol, xotira va disk o'tkazish qobiliyati muvozanatli emasligi bilan bog'liq. Biroq, ular turli joylarda muvozanatli bo'lmasligi mumkin. PostgreSQL sozlanmagan, OT sozlanmagan, apparat sozlanmagan va apparat noto‘g‘ri. Va bu muammo faqat hamma narsa kerak bo'lganda sodir bo'lmaydi, ya'ni yuk bo'lmasa yoki sozlamalar va apparat yaxshi tanlangan bo'lsa.

Bu nima va u nimaga o'xshaydi? Odatda PostgreSQL bilan ishlaydigan odamlar bu masalaga bir necha marta kirishgan. Men tushuntiraman. Aytganimdek, PostgreSQL vaqti-vaqti bilan umumiy xotiradagi iflos sahifalarni diskka tashlash uchun nazorat nuqtalarini o'rnatadi. Agar bizda katta hajmdagi umumiy xotira mavjud bo'lsa, nazorat nuqtasi diskga intensiv ta'sir qila boshlaydi, chunki u ushbu sahifalarni fsync bilan tashlaydi. U yadro buferiga keladi va fsync yordamida disklarga yoziladi. Va agar bu biznesning hajmi katta bo'lsa, unda biz yoqimsiz ta'sirni, ya'ni disklardan juda katta foydalanishni kuzatishimiz mumkin.

Mana menda ikkita rasm bor. Endi nima ekanligini tushuntiraman. Bular vaqt bilan bog'liq ikkita grafik. Birinchi grafik diskdan foydalanish. Bu erda u hozirgi vaqtda deyarli 90% ga etadi. Agar sizda jismoniy disklar bilan ma'lumotlar bazasida nosozlik bo'lsa, RAID kontrolleridan foydalanish 90% bo'lsa, bu yomon yangilik. Bu biroz ko'proq va u 100 ga etadi va I/U to'xtaydi.

Agar sizda disk majmuasi bo'lsa, unda bu biroz boshqacha hikoya. Bu uning qanday tuzilganiga, qanday massiv ekanligiga va hokazolarga bog'liq.

Va parallel ravishda, ichki postgres ko'rinishidagi grafik bu erda sozlangan, bu nazorat nuqtasi qanday sodir bo'lishini ko'rsatadi. Yashil rang esa o'sha paytda sinxronizatsiya uchun ushbu nazorat punktiga qancha buferlar, bu iflos sahifalar kelganligini ko'rsatadi. Va bu erda siz bilishingiz kerak bo'lgan asosiy narsa. Biz bu erda juda ko'p sahifalarimiz borligini ko'rmoqdamiz va bir vaqtning o'zida biz taxtaga tushamiz, ya'ni biz yozdik va yozdik, bu erda disk tizimi juda band ekanligi aniq. Va bizning nazorat punktimiz diskka juda kuchli ta'sir qiladi. Ideal holda, vaziyat shunga o'xshash bo'lishi kerak, ya'ni biz bu erda kamroq yozib oldik. Va biz buni sozlamalar bilan tuzatamiz, shunda u shunday bo'lib qoladi. Ya'ni, qayta ishlash kichik, lekin bir joyda biz bu erda biror narsa yozmoqdamiz.

Bu muammoni yengish uchun nima qilish kerak? Agar siz ma'lumotlar bazasi ostida IO ni to'xtatgan bo'lsangiz, bu ularning so'rovlarini bajarish uchun kelgan barcha foydalanuvchilar kutishlarini anglatadi.

Agar siz Linux nuqtai nazaridan qarasangiz, yaxshi uskunani olgan bo'lsangiz, uni to'g'ri sozlagan bo'lsangiz, PostgreSQL-ni an'anaviy tarzda sozlagan bo'lsangiz, u bu nazorat nuqtalarini kamroq qiladi, vaqt o'tishi bilan ularni bir-biriga tarqatadi, keyin siz standart Debian parametrlariga o'tasiz. Ko'pgina Linux distributivlari uchun bu rasm: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Bu nima degani? 2.6 yadrosidan bitta qizarib ketgan jin paydo bo'ldi. Pdglush, kim foydalanayotganiga qarab, yadro buferidan iflos sahifalarni fondan olib tashlash va iflos sahifalarni nima bo'lishidan qat'iy nazar tashlab yuborish bilan shug'ullanadi, qachonki fonni o'chirish yordam bermasa.

Fon qachon keladi? Agar serverda mavjud bo'lgan jami operativ xotiraning 10% yadro buferidagi iflos sahifalar bilan band bo'lsa, fonda maxsus o'chirish funksiyasi chaqiriladi. Nima uchun bu fon? Parametr sifatida qancha sahifani hisobdan chiqarishni hisobga oladi. Va aytaylik, u N sahifani yozadi. Va bir muncha vaqt bu narsa uxlab qoladi. Va keyin u yana kelib, yana bir nechta sahifalarni ko'chiradi.

Bu juda oddiy hikoya. Bu erda muammo suzish havzasiga o'xshaydi, u bir trubaga quyilsa, boshqasiga oqib chiqadi. Bizning nazorat punktimiz keldi va agar u bir nechta iflos sahifalarni yo'q qilish uchun yuborgan bo'lsa, unda asta-sekin pgflush yadro buferidan hamma narsa aniq hal qilinadi.

Agar bu iflos sahifalar to'planishda davom etsa, ular 20% gacha to'planadi, shundan so'ng OS ustuvorligi diskka hamma narsani yozishdir, chunki quvvat uzilib qoladi va biz uchun hamma narsa yomon bo'ladi. Biz, masalan, bu ma'lumotlarni yo'qotamiz.

Qanday hiyla? Qizig'i shundaki, zamonaviy dunyoda ushbu parametrlar mashinadagi jami operativ xotiraning 20 va 10% ni tashkil qiladi, ular sizda mavjud bo'lgan har qanday disk tizimining o'tkazuvchanligi nuqtai nazaridan juda dahshatli.

Tasavvur qiling, sizda 128 GB operativ xotira bor. Disk tizimingizga 12,8 GB keladi. Va u erda qanday keshingiz bo'lishidan qat'i nazar, u erda qanday massiv bo'lishidan qat'i nazar, ular uzoq davom etmaydi.

Shuning uchun, RAID kontrolleringizning imkoniyatlaridan kelib chiqib, ushbu raqamlarni darhol sozlashingizni tavsiya qilamiz. Men darhol bu yerda 512 MB keshga ega kontrollerni tavsiya qildim.

Hamma narsa juda oddiy deb hisoblanadi. Siz vm.dirty_background ni baytlarga qo'yishingiz mumkin. Va bu sozlamalar avvalgi ikkitasini bekor qiladi. Yoki nisbat sukut bo'yicha, yoki baytlilar faollashtirilgan bo'lsa, baytlilar ishlaydi. Ammo men DBA maslahatchisi bo'lganim va turli mijozlar bilan ishlaganim uchun, men somonlarni chizishga harakat qilaman va shuning uchun agar baytlarda, keyin baytlarda. Hech kim yaxshi administrator serverga ko'proq xotira qo'shmasligiga, uni qayta ishga tushirmasligiga va raqam bir xil bo'lib qolishiga hech kim kafolat bermadi. Faqat bu raqamlarni hisoblang, shunda hamma narsa kafolat bilan mos keladi.

Agar mos kelmasangiz nima bo'ladi? Men har qanday qizarish samarali ravishda to'xtatilishini yozganman, lekin aslida bu nutq figurasi. Operatsion tizimda katta muammo bor - unda juda ko'p iflos sahifalar mavjud, shuning uchun sizning mijozlaringiz yaratadigan IO samarali to'xtatiladi, ya'ni dastur ma'lumotlar bazasiga sql so'rovini yuborish uchun keldi, u kutmoqda. Unga har qanday kirish/chiqarish eng past ustuvorlikka ega, chunki ma'lumotlar bazasi nazorat punkti bilan band. Va u qachon tugatishi mutlaqo noma'lum. Agar siz fonda bo'lmagan tozalashga erishgan bo'lsangiz, bu sizning barcha IO'laringiz bilan band ekanligini anglatadi. Va u tugaguncha, siz hech narsa qilmaysiz.

Ushbu hisobot doirasidan tashqarida bo'lgan yana ikkita muhim nuqta bor. Ushbu sozlamalar postgresql.conf dagi sozlamalarga, ya'ni nazorat nuqtalari sozlamalariga mos kelishi kerak. Va sizning disk tizimingiz mos ravishda sozlangan bo'lishi kerak. Agar sizda RAID-da kesh bo'lsa, unda batareya bo'lishi kerak. Odamlar batareyasiz yaxshi kesh bilan RAID sotib olishadi. Agar sizda RAID-da SSD-lar bo'lsa, ular server bo'lishi kerak, u erda kondensatorlar bo'lishi kerak. Bu erda batafsil nazorat ro'yxati. Ushbu havolada PostgreSQL-da ishlash diskini qanday sozlash bo'yicha mening hisobotim mavjud. Bu erda barcha nazorat ro'yxatlari mavjud.

Hayotni yana nima qiyinlashtirishi mumkin? Bu ikkita parametr. Ular nisbatan yangi. Odatiy bo'lib, ular turli ilovalarga kiritilishi mumkin. Va agar ular noto'g'ri yoqilgan bo'lsa, hayotni xuddi shunday qiyinlashtirishi mumkin.

Ikki nisbatan yangi narsa bor. Ular allaqachon uchinchi yadrolarda paydo bo'lgan. Bu nanosoniyalarda sched_migration_cost va sched_autogroup_enabled, sukut bo'yicha bitta.

Va ular sizning hayotingizni qanday buzishadi? sched_migration_cost nima? Linuxda rejalashtiruvchi jarayonni bir protsessordan ikkinchisiga o'tkazishi mumkin. Va so'rovlarni bajaradigan PostgreSQL uchun boshqa protsessorga o'tish mutlaqo noaniq. Operatsion tizim nuqtai nazaridan, siz ochiq ofis va terminal o'rtasida oynalarni almashtirganingizda, bu yaxshi bo'lishi mumkin, lekin ma'lumotlar bazasi uchun bu juda yomon. Shuning uchun, oqilona siyosat migration_cost qiymatini katta qiymatga, kamida bir necha ming nanosoniyaga o'rnatishdir.

Bu rejalashtiruvchi uchun nimani anglatadi? Bu vaqt ichida jarayon hali ham issiq ekanligi hisobga olinadi. Ya'ni, agar sizda uzoq vaqtdan beri biror narsa bilan shug'ullanadigan uzoq muddatli tranzaktsiyangiz bo'lsa, rejalashtiruvchi buni tushunadi. U bu taym-aut tugamaguncha, bu jarayonni boshqa joyga ko'chirishga hojat yo'q deb taxmin qiladi. Agar jarayon bir vaqtning o'zida biror narsa qilsa, u hech qaerga ko'chirilmaydi, unga ajratilgan protsessorda jimgina ishlaydi. Va natija ajoyib.

Ikkinchi nuqta - avtoguruh. Zamonaviy ma'lumotlar bazalari bilan bog'liq bo'lmagan maxsus ish yuklari uchun yaxshi fikr bor - bu jarayonlarni ular ishga tushirilgan virtual terminal bo'yicha guruhlashdir. Bu ba'zi vazifalar uchun qulay. Amalda, PostgreSQL bir terminaldan ishlaydigan preforka ega ko'p jarayonli tizimdir. Sizda blokirovka yozuvchisi, nazorat punkti bor va sizning barcha mijoz so'rovlaringiz protsessor uchun bitta rejalashtiruvchiga to'planadi. Va ular bir-birlariga aralashish va uni uzoqroq band qilish uchun uning ozod bo'lishini bir ovozdan kutishadi. Bu bunday yuk bo'lgan taqdirda mutlaqo keraksiz bo'lgan hikoya va shuning uchun uni o'chirish kerak.

Mening hamkasbim Aleksey Lesovskiy oddiy pgbench bilan sinovlar o'tkazdi, u erda migration_costni kattalik bilan oshirdi va avtoguruhni o'chirib qo'ydi. Yomon apparatdagi farq deyarli 10% edi. Postgres pochta ro'yxatida odamlar so'rovlar tezligiga o'xshash o'zgarishlar natijalarini beradigan muhokamalar mavjud 50% ta'sir qilgan. Bunday hikoyalar juda ko'p.

Va nihoyat, energiya tejash siyosati haqida. Yaxshi tomoni shundaki, Linux endi noutbukda ham ishlatilishi mumkin. Va go'yoki u batareyani yaxshi sarflaydi. Ammo to'satdan bu serverda ham sodir bo'lishi mumkinligi ma'lum bo'ldi.

Bundan tashqari, agar siz biron bir hosterdan serverlarni ijaraga olsangiz, unda "yaxshi" hosterlar sizning ishlashingiz yaxshiroq ekanligiga ahamiyat bermaydilar. Ularning vazifasi temirdan iloji boricha samarali foydalanishni ta'minlashdir. Shuning uchun, sukut bo'yicha ular operatsion tizimda noutbukning quvvatni tejash rejimini yoqishlari mumkin.

Agar siz ushbu materialni ma'lumotlar bazasi og'ir yuk ostida bo'lgan serverda ishlatsangiz, sizning tanlovingiz acpi_cpufreq + permormance bo'ladi. Hatto talab bilan ham muammolar bo'ladi.

Intel_pstate biroz boshqacha drayverdir. Va endi bu narsaga ustunlik beriladi, chunki u keyinroq va yaxshiroq ishlaydi.

Va shunga ko'ra, gubernator faqat ishlashdir. Ondemand, powersave va boshqa hamma narsa sizga tegishli emas.

PostgreSQL tahlilini tushuntirish natijalari, agar siz quvvatni tejashni yoqsangiz, bir necha darajalar bilan farq qilishi mumkin, chunki ma'lumotlar bazasi ostidagi protsessor deyarli oldindan aytib bo'lmaydigan tarzda ishlaydi.

Ushbu elementlar sukut bo'yicha kiritilishi mumkin. Ular uni sukut bo'yicha yoqilganligini bilish uchun diqqat bilan qarang. Bu haqiqatan ham katta muammo bo'lishi mumkin.

Va nihoyat, men PosgreSQL-Consulting DBA jamoasining yigitlariga, xususan, bu borada har kuni oldinga siljib kelayotgan Maks Boguk va Aleksey Lesovskiyga rahmat aytmoqchi edim. Va biz mijozlarimiz uchun qo'limizdan kelganini qilishga harakat qilamiz, shunda hammasi ular uchun ishlaydi. Bu aviatsiya xavfsizligi bo'yicha ko'rsatmalarga o'xshaydi. Bu yerda hamma narsa qon bilan yozilgan. Ushbu yong'oqlarning har biri qandaydir muammoni hal qilish jarayonida topiladi. Men ularni siz bilan baham ko'rishdan xursandman.

Savollar:

Rahmat! Agar, masalan, kompaniya pulni tejashni va ma'lumotlar bazasi va ilovalar mantig'ini bitta serverga joylashtirishni xohlasa yoki kompaniya PostgreSQL konteynerda ishlaydigan mikroservis arxitekturasining moda tendentsiyasiga amal qilsa. Qanday hiyla? Sysctl butun yadroga global ta'sir qiladi. Sysctls konteynerda alohida ishlashi uchun virtualizatsiya qilinganligini eshitmaganman. Faqat guruh mavjud va u erda nazoratning faqat bir qismi mavjud. Bu bilan qanday yashay olasiz? Yoki ishlashni xohlasangiz, PostgreSQL-ni alohida apparat serverida ishga tushiring va uni sozlang?

Sizning savolingizga taxminan uchta usulda javob berdik. Agar biz sozlanishi mumkin bo'lgan apparat serveri va boshqalar haqida gapirmasak, dam oling, bu sozlamalarsiz hamma narsa yaxshi ishlaydi. Agar sizda shunday yuk bo'lsa, bu sozlamalarni o'rnatishingiz kerak bo'lsa, siz temir serverga ushbu sozlamalardan oldinroq kelasiz.

Muammo nimada? Agar bu virtual mashina bo'lsa, unda siz ko'p muammolarga duch kelishingiz mumkin, masalan, ko'pgina virtual mashinalarda diskning kechikishi juda mos kelmaydi. Diskning o'tkazuvchanligi yaxshi bo'lsa ham, tekshirish punktida yoki WAL-ga yozish paytida sodir bo'lgan o'rtacha o'tkazuvchanlikka katta ta'sir ko'rsatmaydigan bitta I/U tranzaksiyasi muvaffaqiyatsiz bo'lsa ham, ma'lumotlar bazasi bundan katta zarar ko'radi. Va siz ushbu muammolarga duch kelishingizdan oldin buni sezasiz.

Agar bir xil serverda NGINX bo'lsa, sizda ham xuddi shunday muammo bo'ladi. U umumiy xotira uchun kurashadi. Va siz bu erda tasvirlangan muammolarga erisha olmaysiz.

Ammo boshqa tomondan, ushbu parametrlarning ba'zilari siz uchun hali ham tegishli bo'ladi. Misol uchun, dirty_ratio ni sysctl bilan o'rnating, shunda u aqldan ozmaydi - har qanday holatda, bu yordam beradi. Qanday bo'lmasin, siz disk bilan o'zaro aloqada bo'lasiz. Va bu noto'g'ri naqsh bo'yicha bo'ladi. Bu men ko'rsatgan parametrlar uchun odatda standart hisoblanadi. Va har qanday holatda ularni o'zgartirish yaxshiroqdir.

Ammo NUMA bilan bog'liq muammolar bo'lishi mumkin. Masalan, VmWare NUMA bilan mutlaqo teskari sozlamalar bilan yaxshi ishlaydi. Va bu erda siz tanlashingiz kerak - temir server yoki temir bo'lmagan.

Amazon AWS bilan bog'liq savolim bor. Ularda oldindan sozlangan tasvirlar mavjud. Ulardan biri Amazon RDS deb ataladi. Ularning operatsion tizimi uchun maxsus sozlamalar mavjudmi?

U erda sozlamalar mavjud, ammo ular turli xil sozlamalar. Bu erda biz ma'lumotlar bazasi ushbu narsadan qanday foydalanishi nuqtai nazaridan operatsion tizimni sozlaymiz. Va hozir qaerga borishimiz kerakligini aniqlaydigan parametrlar mavjud, masalan, shakllantirish. Ya'ni, bizga juda ko'p resurslar kerak, biz ularni endi yeymiz. Shundan so'ng Amazon RDS ushbu resurslarni kuchaytiradi va unumdorlik u erda pasayadi. Odamlar bu masala bilan qanday aralasha boshlaganligi haqida individual hikoyalar mavjud. Ba'zan hatto juda muvaffaqiyatli. Ammo bu OS sozlamalariga hech qanday aloqasi yo'q. Bu bulutni buzishga o'xshaydi. Bu boshqa hikoya.

Nima uchun Transparent ulkan sahifalar Huge TLB bilan solishtirganda hech qanday ta'sir ko'rsatmaydi?

bermang. Buni ko'p jihatdan tushuntirish mumkin. Lekin, aslida, ular shunchaki berishmaydi. PostgreSQL tarixi qanday? Ishga tushganda u umumiy xotiraning katta qismini ajratadi. Ular shaffofmi yoki yo'qmi, bu mutlaqo ahamiyatsiz. Ularning boshida ajralib turishi hamma narsani tushuntiradi. Va agar xotira juda ko'p bo'lsa va siz shared_memory segmentini qayta tiklashingiz kerak bo'lsa, shaffof ulkan sahifalar tegishli bo'ladi. PostgreSQL-da, u boshida oddiygina katta bo'lakka ajratilgan va tamom, keyin u erda hech qanday maxsus narsa bo'lmaydi. Siz, albatta, undan foydalanishingiz mumkin, lekin u biror narsani qayta taqsimlaganda shared_memory-ning buzilishi ehtimoli bor. PostgreSQL bu haqda bilmaydi.

Manba: www.habr.com