Илья Космодемьянскийн 2015 оны тайлангийн хуулбар "PostgreSQL-ийн гүйцэтгэлийг сайжруулахын тулд Линуксийн тохиргоо"
Анхааруулга: Энэхүү тайлан нь 2015 оны 4-р сард гарсан гэдгийг би анхаарна уу - 9.4 жил гаруй хугацаа өнгөрч, маш их цаг хугацаа өнгөрчээ. Тайлан дээр хэлэлцсэн 4 хувилбарыг дэмжихээ больсон. Сүүлийн 5 жилийн хугацаанд PostgreSQL-ийн 15 шинэ хувилбар, Линуксийн цөмийн XNUMX хувилбар гарсан. Хэрэв та эдгээр хэсгүүдийг дахин бичвэл өөр тайлан гарах болно. Гэхдээ энд бид PostgreSQL-д зориулсан Linux-ийн үндсэн тохиргоог авч үзсэн бөгөөд энэ нь өнөөг хүртэл хамааралтай хэвээр байна.
Намайг Илья Космодемьянский гэдэг. Би PostgreSQL-Consulting дээр ажилладаг. Одоо би Линуксыг ерөнхийд нь мэдээллийн сан, ялангуяа PostgreSQL-тэй холбоотой юу хийх талаар бага зэрэг ярих болно, учир нь зарчмууд нь нэлээд төстэй юм.
Бид юу ярих вэ? Хэрэв та PostgreSQL-тэй харилцдаг бол тодорхой хэмжээгээр UNIX админ байх шаардлагатай. Энэ нь юу гэсэн үг вэ? Хэрэв бид Oracle болон PostgreSQL-ийг харьцуулж үзвэл Oracle-д та 80% DBA мэдээллийн баазын админ, 20% Linux админ байх шаардлагатай.
PostgreSQL-ийн хувьд энэ нь арай илүү төвөгтэй юм. PostgreSQL-ийн тусламжтайгаар та Линукс хэрхэн ажилладаг талаар илүү сайн ойлголттой байх хэрэгтэй. Үүний зэрэгцээ зүтгүүрийн араас бага зэрэг гүйх хэрэгтэй, учир нь сүүлийн үед бүх зүйл маш сайхан шинэчлэгдсэн. Мөн шинэ цөмүүд гарч, шинэ функцүүд гарч ирэх, гүйцэтгэл сайжирна гэх мэт.
Бид яагаад Линуксийн тухай ярьж байна вэ? Бид Питер Линуксийн бага хуралд оролцож байгаа учраас огтхон ч биш, харин орчин үеийн нөхцөлд ерөнхийдөө мэдээллийн бааз, ялангуяа PostgreSQL ашиглах хамгийн зөвтгөгдсөн үйлдлийн системүүдийн нэг бол Линукс юм. Учир нь FreeBSD харамсалтай нь маш хачирхалтай чиглэлээр хөгжиж байна. Гүйцэтгэл болон бусад олон зүйлд асуудал гарах болно. Windows дээрх PostgreSQL-ийн гүйцэтгэл нь ерөнхийдөө тусдаа ноцтой асуудал бөгөөд Windows нь UNIX-тэй адил хуваалцсан санах ойгүй байдаг бол PostgreSQL нь олон процесст систем учраас бүгд үүнтэй холбоотой байдаг.
Хүн бүр Solaris шиг чамин зүйлсийг бага сонирхдог гэж би бодож байна, тиймээс явцгаая.
Орчин үеийн Linux түгээлт нь цөмийг хэрхэн бүтээхээс хамааран 1 гаруй syctl сонголттой байдаг. Үүний зэрэгцээ, хэрэв бид янз бүрийн самрыг харвал бид ямар нэг зүйлийг олон янзаар тохируулж болно. Тэдгээрийг хэрхэн холбох талаар файлын системийн параметрүүд байдаг. Хэрэв танд үүнийг хэрхэн эхлүүлэх талаар асуулт байвал: BIOS-д юу идэвхжүүлэх, техник хангамжийг хэрхэн тохируулах гэх мэт.
Энэ бол нэг богино тайлан биш, хэд хоногийн турш хэлэлцэж болох маш том хэмжээ юм, гэхдээ одоо би чухал зүйл дээр анхаарлаа төвлөрүүлэх болно, хэрэв та Линукс дээр өөрийн мэдээллийн санг сайн ашиглахаас сэргийлэх баталгаатай тармууруудаас хэрхэн зайлсхийх талаар ярих болно. тэдгээрийг засах хэрэггүй. Үүний зэрэгцээ нэг чухал зүйл бол олон тооны анхдагч параметрүүдийг мэдээллийн санд тохирох тохиргоонд оруулаагүй болно. Өөрөөр хэлбэл, энэ нь анхдагчаар муу эсвэл огт ажиллахгүй болно.
Линукс дээр ямар уламжлалт тааруулах зорилтууд байдаг вэ? Та бүгд Линуксийн удирдлагатай ажиллаж байгаа тул зорилтот зорилго юу болохыг тайлбарлах шаардлагагүй гэж би бодож байна.
Та тааруулж болно:
- CPU-ууд.
- Санах ой.
- Хадгалалт.
- Бусад. Энэ тухай бид төгсгөлд нь зуушаар ярих болно. Жишээлбэл, эрчим хүчний хэмнэлтийн бодлого гэх мэт параметрүүд нь гүйцэтгэлд маш таамаглашгүй, хамгийн тааламжтай байдлаар нөлөөлдөггүй.
PostgreSQL болон ерөнхийдөө мэдээллийн сангийн онцлог юу вэ? Асуудал нь та ямар ч самарыг өөрчлөх боломжгүй бөгөөд бидний гүйцэтгэл мэдэгдэхүйц сайжирч байгааг харж болно.
Тиймээ, ийм хэрэгслүүд байдаг, гэхдээ мэдээллийн сан бол нарийн төвөгтэй зүйл юм. Энэ нь серверт байгаа бүх нөөцтэй харилцаж, бүрэн дүүрэн харилцахыг илүүд үздэг. Хэрэв та Oracle-ийн одоогийн хост үйлдлийн системийг хэрхэн ашиглах талаар зөвлөмжийг харвал энэ нь тэр монгол сансрын нисгэгчийн тухай онигоо шиг байх болно - нохойг хооллож, юунд ч хүрч болохгүй. Мэдээллийн санд бүх нөөцөө өгье, мэдээллийн сан өөрөө бүгдийг цэгцлэх болно.
Зарчмын хувьд нөхцөл байдал ямар нэг хэмжээгээр PostgreSQL-тэй яг ижил байна. Үүний ялгаа нь өгөгдлийн сан нь бүх нөөцийг өөртөө авч чадахгүй байгаа юм, өөрөөр хэлбэл Линукс түвшний хаа нэгтээ та бүгдийг өөрөө цэгцлэх хэрэгтэй.
Гол санаа нь санах ой, CPU гэх мэт ганц зорилтыг сонгоод тааруулж эхлэх биш харин ажлын ачаалалд дүн шинжилгээ хийж, сайн програмистуудын ачааллыг бий болгохын тулд дамжуулах чадварыг аль болох сайжруулахыг хичээх явдал юм. бидний хувьд, түүний дотор манай хэрэглэгчдийн хувьд.
Энэ нь юу болохыг тайлбарлах зураг энд байна. Линукс үйлдлийн системийн буфер, дундын санах ой, PostgreSQL дундын буфер байдаг. PostgreSQL нь Oracle-аас ялгаатай нь зөвхөн цөмийн буферээр дамжуулан шууд ажилладаг, өөрөөр хэлбэл дискний хуудас нь хуваалцсан санах ой руугаа орохын тулд цөмийн буферээр дамжин буцаж, яг ижил нөхцөл байдалд байх ёстой.
Энэ системд дискүүд амьдардаг. Би үүнийг диск хэлбэрээр зурсан. Үнэн хэрэгтээ RAID хянагч гэх мэт байж болно.
Мөн энэ оролт-гаралт нь энэ асуудалд ямар нэгэн байдлаар тохиолддог.
PostgreSQL бол сонгодог мэдээллийн сан юм. Дотор нь хуудас бий. Мөн бүх оролт, гаралт нь хуудас ашиглан тохиолддог. Бид хуудас бүхий блокуудыг санах ойд суулгаж байна. Хэрэв юу ч болоогүй бол бид зүгээр л уншиж, дараа нь аажмаар энэ кэш, хуваалцсан буферээс алга болж, дискэн дээр буцаж ирдэг.
Хэрэв бид хаа нэгтээ ямар нэг зүйлийг солих юм бол бүх хуудсыг бохир гэж тэмдэглэнэ. Би тэднийг энд цэнхэр өнгөөр тэмдэглэв. Энэ нь энэ хуудсыг блок хадгалахтай синхрончлох ёстой гэсэн үг юм. Өөрөөр хэлбэл, бид үүнийг бохир болгохдоо WAL-д оруулга хийсэн. Гайхамшигтай мөчид шалган нэвтрүүлэх цэг гэж нэрлэгддэг үзэгдэл гарч ирэв. Тэгээд тэр ирсэн гэсэн мэдээлэл энэ бүртгэлд бичигдсэн байсан. Энэ нь эдгээр хуваалцсан буфер дотор байсан бүх бохир хуудсыг цөмийн буферээр дамжуулан fsync ашиглан хадгалах дисктэй синхрончлогдсон гэсэн үг юм.
Яагаад үүнийг хийж байна вэ? Хэрэв бид хүчдэлээ алдсан бол бүх өгөгдөл алдагдсан гэсэн нөхцөл байдлыг олж аваагүй болно. Хүн бүр бидэнд хэлж байсан байнгын санах ой нь мэдээллийн сангийн онолын хувьд өнөөг хүртэл байдаг - энэ бол мэдээжийн хэрэг бидний эрмэлзэж байгаа гэрэлт ирээдүй бөгөөд бид үүнд дуртай, гэхдээ одоогоор тэд хасах 20 жил амьдарч байна. Мэдээжийн хэрэг, энэ бүхнийг хянах шаардлагатай.
Мөн дамжуулах чадварыг нэмэгдүүлэхийн тулд эдгээр бүх үе шатуудыг сайтар тааруулж, бүгдийг нь нааш цааш хурдан хөдөлгөх явдал юм. Хуваалцсан санах ой нь үндсэндээ хуудасны кэш юм. PostgreSQL дээр бид сонгох асуулга эсвэл ямар нэгэн зүйл илгээсэн, энэ нь энэ өгөгдлийг дискнээс авсан. Тэд дундын буферт оров. Үүний дагуу үүнийг илүү сайн ажиллуулахын тулд маш их санах ой байх ёстой.
Энэ бүхэн сайн, хурдан ажиллахын тулд та үйлдлийн системийг бүх үе шатанд зөв тохируулах хэрэгтэй. Тэнцвэртэй техник хангамжийг сонго, учир нь хэрэв танд тэнцвэргүй байдал үүссэн бол та маш их санах ойг бий болгож чадна, гэхдээ хангалттай хурдтай ажиллахгүй.
Мөн эдгээр цэг бүрийг авч үзье.
Эдгээр хуудсуудыг нааш цааш хурдан явуулахын тулд та дараах зүйлийг хийх хэрэгтэй.
- Юуны өмнө та санах ойтой илүү үр дүнтэй ажиллах хэрэгтэй.
- Хоёрдугаарт, санах ойноос хуудаснууд диск рүү шилжих энэ шилжилт илүү үр дүнтэй байх ёстой.
- Гуравдугаарт, сайн дискүүд байх ёстой.
Хэрэв таны серверт 512 ГБ RAM байгаа бөгөөд энэ нь ямар ч кэшгүй SATA хатуу диск дээр дуусвал мэдээллийн сангийн сервер бүхэлдээ зөвхөн хулуу биш, харин SATA интерфейстэй хулуу болж хувирна. Та үүнтэй шууд тулгарах болно. Тэгээд юу ч чамайг аврахгүй.
Ой санамжтай холбоотой эхний зүйлийн тухайд, амьдралыг маш хэцүү болгодог гурван зүйл байдаг.
Тэдний эхнийх нь МУИС юм. NUMA бол гүйцэтгэлийг сайжруулахын тулд хийгдсэн зүйл юм. Ажлын ачааллаас хамааран өөр өөр зүйлийг оновчтой болгож болно. Мөн одоогийн шинэ хэлбэрээр энэ нь хуудасны кэш хуваалцсан буферийг эрчимтэй ашигладаг мэдээллийн сан гэх мэт програмуудад тийм ч сайн биш юм.
Самрын ясанд. NUMA-д ямар нэг зүйл буруу байгаа эсэхийг яаж мэдэх вэ? Танд ямар нэгэн таагүй цохилт байна, гэнэт зарим CPU хэт ачаалалтай байна. Үүний зэрэгцээ та PostgreSQL дээрх асуулгад дүн шинжилгээ хийж, тэнд үүнтэй төстэй зүйл байхгүй гэдгийг хараарай. Эдгээр асуулга нь CPU-ийн ачаалал ихтэй байх ёсгүй. Та үүнийг удаан хугацаанд барьж чадна. PostgreSQL-д NUMA-г хэрхэн тохируулах талаар зөв зөвлөмжийг эхнээс нь ашиглах нь илүү хялбар байдаг.
Үнэхээр юу болоод байна аа? NUMA гэдэг нь Non-Uniform Memory Access гэсэн үгийн товчлол юм. Ямар учиртай юм бэ? Танд CPU байгаа, түүний хажууд түүний дотоод санах ой байдаг. Энэхүү санах ойн харилцан холболтууд нь бусад CPU-ээс санах ойг татаж чаддаг.
Хэрэв та гүйвэл numactl --hardware, тэгвэл та ийм том хуудас авах болно. Бусад зүйлсийн дотор зайны талбар байх болно. 10-20 гэх мэт тоонууд байх болно. Эдгээр тоо нь энэ алсын санах ойг авч, дотооддоо ашиглахын тулд хэдэн удаа цохихоос өөр зүйл биш юм. Зарчмын хувьд сайн санаа. Энэ нь янз бүрийн ачааллын дор гүйцэтгэлийг хурдасгадаг.
Одоо танд нэг CPU байгаа гэж төсөөлөөд үз дээ, эхлээд өөрийн дотоод санах ойг ашиглах гэж оролдож, дараа нь өөр санах ойг ямар нэгэн зүйлээр харилцан холболтоор татах гэж оролддог. Энэ CPU таны PostgreSQL хуудасны кэшийг бүхэлд нь авдаг - энэ бол хэдэн гигабайт юм. Та үргэлж хамгийн муу тохиолдолтой тулгардаг, учир нь CPU дээр ихэвчлэн тэр модульд санах ой бага байдаг. Мөн үйлчилгээ үзүүлж буй бүх санах ой нь эдгээр харилцан холболтоор дамждаг. Энэ нь удаан бөгөөд гунигтай болж хувирдаг. Мөн энэ зангилаанд үйлчилдэг таны процессор байнга ачаалалтай байдаг. Мөн энэ санах ойд хандах хугацаа муу, удаан байна. Хэрэв та үүнийг мэдээллийн санд ашиглаж байгаа бол ийм нөхцөл байдлыг хүсэхгүй байна.
Тиймээс мэдээллийн сангийн илүү зөв сонголт бол Линукс үйлдлийн систем тэнд юу болж байгааг огт мэдэхгүй байх явдал юм. Ингэснээр тэр санах ойд ханддаг шигээ ханддаг.
Яагаад тэр вэ? Энэ нь эсрэгээрээ байх ёстой юм шиг санагдаж байна. Энэ нь нэг энгийн шалтгааны улмаас тохиолддог: хуудасны кэшэд маш их санах ой хэрэгтэй - хэдэн арван, хэдэн зуун гигабайт.
Хэрэв бид энэ бүгдийг хуваарилж, тэнд мэдээллээ кэш хийвэл кэш ашиглахаас олох ашиг нь санах ойд ийм төвөгтэй хандалтаас олсон ашгаас хамаагүй их байх болно. Тиймээс бид NUMA-г ашиглан санах ойд илүү үр дүнтэй хандахтай харьцуулшгүй их ашиг хүртэх болно.
Тиймээс, гэрэлт ирээдүй ирэх хүртэл хоёр арга зам байгаа бөгөөд мэдээллийн сан нь аль CPU дээр ажиллаж байгаа, хаанаас ямар нэгэн зүйл татах шаардлагатайг олж мэдэх боломжгүй байна.
Тиймээс NUMA-г бүхэлд нь идэвхгүй болгох нь зөв арга юмжишээлбэл, дахин ачаалах үед. Ихэнх тохиолдолд хожлын хэмжээ маш их байдаг тул аль нь илүү вэ гэсэн асуулт огт гардаггүй.
Өөр сонголт бий. Бид үүнийг эхнийхээсээ илүү олон удаа ашигладаг, учир нь үйлчлүүлэгч бидэн дээр тусламж хүсэх үед серверийг дахин ачаалах нь түүний хувьд маш том асуудал юм. Тэр тэнд бизнестэй. Мөн тэд МУИС-аас болж асуудалтай тулгардаг. Тиймээс бид үүнийг дахин ачаалахаас хамаагүй бага инвазив аргаар идэвхгүй болгохыг хичээж байгаа ч үүнийг идэвхгүй болгосон эсэхийг шалгах хэрэгтэй. Учир нь туршлагаас харахад бид эх PostgreSQL процесс дээр NUMA-г идэвхгүй болгосон нь сайн хэрэг, гэхдээ энэ нь ажиллах шаардлагагүй юм. Тэр үнэхээр унтарсан эсэхийг бид шалгаж үзэх хэрэгтэй.
Роберт Хаасын сайхан бичлэг байна. Энэ бол PostgreSQL коммитеруудын нэг юм. Бүх доод түвшний гиблегийн гол хөгжүүлэгчдийн нэг. Хэрэв та энэ нийтлэлийн холбоосыг дагавал МУИС хүмүүсийн амьдралыг хэрхэн хүндрүүлсэн тухай хэд хэдэн өнгөлөг түүхийг дүрсэлдэг. Манай мэдээллийн баазыг сайн ажиллуулахын тулд сервер дээр юу тохируулах шаардлагатайг системийн администраторын хяналтын хуудсыг судалж үзээрэй. Эдгээр тохиргоог бичиж, шалгах хэрэгтэй, эс тэгвээс энэ нь тийм ч сайн биш байх болно.
Энэ нь миний ярих бүх тохиргоонд хамаарна гэдгийг анхаарна уу. Гэхдээ ихэвчлэн мэдээллийн санг алдааг тэсвэрлэхийн тулд мастер-боол горимд цуглуулдаг. Эдгээр тохиргоог боол дээр хийхээ бүү мартаарай, учир нь та хэзээ нэгэн цагт осолд орж, боол руу шилжих бөгөөд тэр нь эзэн болно.
Яаралтай нөхцөл байдалд бүх зүйл маш муу, таны утас байнга дуугарч, дарга чинь том саваа бариад гүйж ирэхэд танд шалгах талаар бодох зав гарахгүй. Мөн үр дүн нь нэлээд гамшигт хүргэж болзошгүй юм.
Дараагийн цэг бол асар том хуудас юм. Асар том хуудсуудыг тусад нь туршихад хэцүү байдаг бөгөөд үүнийг хийж чадах жишиг үзүүлэлтүүд байдаг ч үүнийг хийх нь утгагүй юм. Тэд Google-д хялбар байдаг.
Ямар учиртай юм бэ? Та маш их хэмжээний RAM-тай, жишээлбэл 30 ГБ-аас дээш хэмжээтэй тийм ч үнэтэй биш сервертэй. Та том хуудас ашигладаггүй. Энэ нь санах ойн ашиглалтын хувьд танд нэмэлт зардал байгаа гэсэн үг юм. Мөн энэ нэмэлт зардал нь хамгийн тааламжтай зүйлээс хол байна.
Яагаад тэр вэ? Тэгэхээр юу болоод байна? Үйлдлийн систем нь санах ойг жижиг хэсгүүдэд хуваарилдаг. Энэ нь маш тохиромжтой, түүхэнд ийм зүйл тохиолдсон юм. Хэрэв бид нарийвчилсан мэдээлэл өгөх юм бол үйлдлийн систем нь виртуал хаягуудыг физик хаяг руу хөрвүүлэх ёстой. Мөн энэ процесс нь хамгийн энгийн зүйл биш тул үйлдлийн систем нь энэ үйлдлийн үр дүнг Translation Lookaside Buffer (TLB) дотор хадгалдаг.
TLB нь кэш учраас кэштэй холбоотой бүх асуудал ийм нөхцөлд үүсдэг. Нэгдүгээрт, хэрэв танд маш их RAM байгаа бөгөөд бүгдийг нь жижиг хэсгүүдэд хуваасан бол энэ буфер маш том болно. Хэрэв кэш том бол түүнийг хайх нь удаан болно. Толгойн ачаалал нь эрүүл бөгөөд өөрөө зай эзэлдэг, өөрөөр хэлбэл RAM-г буруу зүйл хэрэглэж байна. Энэ удаад.
Хоёр - ийм нөхцөлд кэш нэмэгдэх тусам кэш алдагдах магадлал өндөр болно. Мөн энэ кэшийн үр ашиг нь хэмжээ нэмэгдэх тусам хурдан буурдаг. Тиймээс үйлдлийн системүүд энгийн арга барилтай болсон. Энэ нь Линукс дээр удаан хугацаанд ашиглагдаж ирсэн. Энэ нь саяхан FreeBSD дээр гарч ирсэн. Гэхдээ бид Линуксийн тухай ярьж байна. Эдгээр нь асар том хуудаснууд юм.
Маш том хуудсуудыг санаа болгон анх Oracle болон IBM-ийг багтаасан нийгэмлэгүүд түлхсэн, өөрөөр хэлбэл өгөгдлийн сангийн үйлдвэрлэгчид энэ нь өгөгдлийн санд ашигтай байх болно гэж хүчтэй бодож байсныг энд тэмдэглэх нь зүйтэй.
Үүнийг PostgreSQL-тэй хэрхэн нөхөрлөх вэ? Нэгдүгээрт, Линуксийн цөмд асар том хуудсуудыг идэвхжүүлсэн байх ёстой.
Хоёрдугаарт, тэдгээрийг sysctl параметрээр тодорхой зааж өгөх ёстой - хэдэн байна. Энд байгаа тоонууд нь зарим хуучин серверээс ирсэн байна. Та хичнээн хуваалцсан буфер байгааг тооцоолж болох бөгөөд ингэснээр асар том хуудаснууд тэнд багтах болно.
Хэрэв таны сервер бүхэлдээ PostgreSQL-д зориулагдсан бол RAM-ийн 25% -ийг хуваалцсан буферт, эсвэл таны мэдээллийн сан энэ 75% -д багтах болно гэдэгт итгэлтэй байгаа бол 75% -ийг хуваарилах нь сайн эхлэл юм. Эхлэх цэг нэг. Хэрэв танд 256 ГБ RAM байгаа бол 64 ГБ том буфертэй байх болно гэдгийг анхаарч үзээрэй. Ойролцоогоор тодорхой хэмжээний маржингаар тооцоолоорой - энэ тоог юу гэж тохируулах ёстой.
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 байгаа бол оролдоод үзээрэй, энэ нь үргэлж аюулгүй байдаг.
Хэрэв асаалттай бол асар том хуудсуудаас сонгох боломжгүй бол энэ нь зүгээр л эхлэхгүй. Энд аль хэдийн хэн, юу нь илүү сайхан болох тухай юм. Гэхдээ хэрэв та оролдсон бол танд үнэхээр онцолсон зүйл байгаа эсэхийг шалгаарай, учир нь алдаа гаргах зай их байна. Одоогоор энэ функц нь зөвхөн Линукс дээр ажилладаг.
Цааш явахаасаа өмнө бас нэг жижиг тэмдэглэл. Ил тод том хуудсууд нь PostgreSQL-ийн талаар хараахан биш юм. Тэр тэдгээрийг ердийн байдлаар ашиглаж чадахгүй. Ийм ажлын ачаалалд зориулсан Transparent асар том хуудсууд нь их хэмжээний хуваалцсан санах ой хэрэгтэй үед ашиг тус нь зөвхөн маш том хэмжээтэй ирдэг. Хэрэв танд терабайт санах ой байгаа бол энэ нь хэрэгжиж магадгүй юм. Хэрэв бид өдөр тутмын хэрэглээний талаар ярьж байгаа бол таны машин дээр 32, 64, 128, 256 ГБ санах ой байгаа бол ердийн том хуудсууд нь "OK" бөгөөд бид зүгээр л Transparent-ийг идэвхгүй болгодог.
Тэгээд санах ойн тухай хамгийн сүүлийн зүйл бол fruitut шууд холбоотой биш юм, Энэ нь үнэхээр таны амьдралыг сүйрүүлж болно. Сервер байнга солигдож байгаа нь бүх дамжуулах чадварт ихээхэн нөлөөлнө.
Мөн энэ нь хэд хэдэн талаараа маш тааламжгүй байх болно. Хамгийн гол асуудал бол орчин үеийн цөмүүд хуучин Линуксийн цөмүүдээс арай өөр ажилладаг. Энэ зүйл дээр гишгэх нь маш тааламжгүй юм, учир нь бид своп хийх зарим төрлийн ажлын талаар ярихад энэ нь OOM алуурчин цаг тухайд нь ирээгүйгээс дуусдаг. Цаг тухайд нь ирээгүй, PostgreSQL-ийг унагасан OOM-алуурчин нь тааламжгүй юм. Хүн бүр энэ талаар, өөрөөр хэлбэл сүүлчийн хэрэглэгч хүртэл мэдэх болно.
Юу болоод байна? Танд маш их хэмжээний RAM байгаа, бүх зүйл сайн ажилладаг. Гэхдээ ямар нэг шалтгааны улмаас сервер своп-д гацаж, үүнээс болж удааширдаг. Санах ой маш их байгаа юм шиг санагддаг, гэхдээ ийм зүйл тохиолддог.
Өмнө нь бид vm.swappiness-ийг тэг болгох, өөрөөр хэлбэл swap-г идэвхгүй болгохыг зөвлөж байсан. Өмнө нь 32 ГБ RAM болон холбогдох хуваалцсан буфер нь асар их хэмжээ юм шиг санагдаж байсан. Свопын гол зорилго нь хэрэв бид унавал царцдасыг хаях газартай байх явдал юм. Мөн энэ нь ялангуяа биелэгдэхээ больсон. Тэгээд та энэ царцдасыг яах гэж байна вэ? Энэ бол яагаад своп хэрэгтэй байгаа нь тийм ч тодорхойгүй ажил юм, ялангуяа ийм хэмжээтэй.
Гэхдээ илүү орчин үеийн, өөрөөр хэлбэл цөмийн гурав дахь хувилбаруудад зан байдал өөрчлөгдсөн. Хэрэв та свопыг тэг болгож, өөрөөр хэлбэл үүнийг унтраавал эрт орой хэзээ нэгэн цагт RAM үлдсэн байсан ч хамгийн эрчимтэй хэрэглэгчдийг устгахын тулд OOM алуурчин танд ирэх болно. Учир нь тэр ийм ачаалалтай байхад бидэнд бага зэрэг үлдэж, бид үсрэх болно, өөрөөр хэлбэл системийн үйл явцыг хаахын тулд биш, харин бага ач холбогдолтой зүйлийг хаах болно гэж бодох болно. Энэ чухал ач холбогдол багатай нь хуваалцсан санах ойн эрчимтэй хэрэглэгч, тухайлбал шуудангийн мастер байх болно. Үүний дараа суурийг сэргээх шаардлагагүй бол сайн байх болно.
Тиймээс, одоо миний санаж байгаагаар анхдагчаар ихэнх түгээлтүүд 6 орчим байдаг, өөрөөр хэлбэл хэр санах ой үлдсэнээс хамаарч свопыг аль үед ашиглаж эхлэх ёстой вэ. Одоо бид vm.swappiness = 1-ийг тохируулахыг санал болгож байна, учир нь энэ нь үүнийг бараг унтраадаг ч санамсаргүйгээр ирж, бүх зүйлийг устгасан OOM алуурчинтай адил нөлөө үзүүлэхгүй.
Дараа нь юу юм? Өгөгдлийн сангийн гүйцэтгэлийн талаар ярьж, аажмаар диск рүү шилжихэд хүн бүр толгойгоо барьж эхэлдэг. Учир нь диск нь удаан, санах ой нь хурдан гэдэг үнэнийг хүн бүр багаасаа мэддэг. Мөн өгөгдлийн сан нь дискний гүйцэтгэлийн асуудалтай тулгардаг гэдгийг хүн бүр мэддэг.
Шалгах цэгийн огцом өсөлттэй холбоотой PostgreSQL-ийн гүйцэтгэлийн гол асуудал нь диск удаан ажилладаг тул үүсдэггүй. Энэ нь санах ой болон дискний зурвасын өргөнийг тэнцвэржүүлээгүйтэй холбоотой байх магадлалтай. Гэсэн хэдий ч тэдгээр нь өөр өөр газар тэнцвэртэй биш байж болно. PostgreSQL тохируулагдаагүй, үйлдлийн систем нь тохируулагдаагүй, техник хангамж тохируулагдаагүй, техник хангамж буруу байна. Бүх зүйл зохих ёсоор болсон, өөрөөр хэлбэл ачаалал байхгүй эсвэл тохиргоо, техник хангамжийг сайн сонгосон тохиолдолд л энэ асуудал гардаггүй.
Энэ юу вэ, ямар харагддаг вэ? PostgreSQL-тэй ажилладаг хүмүүс ихэвчлэн энэ асуудалд нэгээс олон удаа орсон байдаг. Би тайлбарлая. Миний хэлсэнчлэн PostgreSQL нь хуваалцсан санах ойн бохир хуудсыг диск рүү хаяхын тулд үе үе хяналтын цэгүүдийг хийдэг. Хэрэв бид их хэмжээний хуваалцсан санах ойтой бол хяналтын цэг нь эдгээр хуудсыг fsync-ээр устгадаг тул дискэнд эрчимтэй нөлөөлж эхэлдэг. Энэ нь цөмийн буферт ирдэг бөгөөд fsync ашиглан дискэнд бичигддэг. Хэрэв энэ бизнесийн хэмжээ том бол бид таагүй үр дагавар, тухайлбал дискний маш их хэрэглээг ажиглаж болно.
Энд надад хоёр зураг байна. Энэ нь юу болохыг би одоо тайлбарлах болно. Эдгээр нь цаг хугацааны хамааралтай хоёр график юм. Эхний график нь дискний ашиглалт юм. Энэ үед энэ нь бараг 90% хүрч байна. Хэрэв танд RAID хянагч 90% -ийн ашиглалттай физик дискний мэдээллийн санд гэмтэл гарсан бол энэ нь муу мэдээ юм. Энэ нь бага зэрэг ахихад 100 хүрч, I/O зогсоно гэсэн үг.
Хэрэв танд дискний массив байгаа бол энэ нь арай өөр түүх юм. Энэ нь хэрхэн тохируулагдсан, ямар төрлийн массив гэх мэтээс хамаарна.
Үүний зэрэгцээ дотоод postgres харагдацын графикийг энд тохируулсан бөгөөд энэ нь хяналтын цэг хэрхэн явагддагийг харуулж байна. Энд байгаа ногоон өнгө нь синхрончлолд зориулж энэ хяналтын цэг дээр хэдэн буфер, эдгээр бохир хуудаснууд ирснийг харуулж байна. Мөн энэ бол таны мэдэх ёстой гол зүйл юм. Бид энд маш олон хуудастай байгааг харж, хэзээ нэгэн цагт самбар дээр дарж, өөрөөр хэлбэл бид бичиж, бичсэн, энд дискний систем маш завгүй байгаа нь тодорхой байна. Мөн манай хяналтын цэг нь дискэнд маш хүчтэй нөлөө үзүүлдэг. Нөхцөл байдал илүү иймэрхүү харагдах ёстой, өөрөөр хэлбэл энд бид бага бичлэг хийсэн. Цаашид ч ийм хэвээр байхын тулд бид үүнийг тохиргоогоор нь засаж болно. Өөрөөр хэлбэл, дахин боловсруулалт нь бага, гэхдээ хаа нэгтээ бид энд ямар нэг зүйл бичиж байна.
Энэ асуудлыг даван туулахын тулд юу хийх хэрэгтэй вэ? Хэрэв та мэдээллийн баазын дор IO-г зогсоосон бол энэ нь хүсэлтээ биелүүлэхээр ирсэн бүх хэрэглэгчид хүлээх болно гэсэн үг юм.
Хэрэв та Линуксийн өнцгөөс харвал, хэрэв та сайн техник хангамж авч, зөв тохируулж, PostgreSQL-г ердийн байдлаар тохируулсан бөгөөд ингэснээр эдгээр хяналтын цэгүүдийг цөөн болгож, цаг хугацааны явцад хооронд нь тарааж, Debian-ийн анхдагч параметрүүд рүү шилжих болно. Ихэнх Линуксийн түгээлтийн хувьд энэ нь зураг байна: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Энэ нь юу гэсэн үг вэ? Цөм 2.6-аас нэг улайсан чөтгөр гарч ирэв. Pdglush нь хэн аль нь ашиглаж байгаагаас шалтгаалж, цөмийн буферээс бохир хуудсуудыг арын дэвсгэр дээр хаях, бохир хуудсыг юу ч хамаагүй хаях шаардлагатай үед арын хэсгийг хаях нь тус болохгүй.
Арын дэвсгэр хэзээ ирдэг вэ? Сервер дээр байгаа нийт RAM-ийн 10% нь цөмийн буфер дэх бохир хуудсуудаар дүүрсэн тохиолдолд арын дэвсгэр дээр тусгай хасалтын функц дуудагддаг. Яагаад дэвсгэр вэ? Параметрийн хувьд энэ нь хэдэн хуудас хасахыг харгалзан үздэг. Тэгээд тэр N хуудас бичдэг гэж бодъё. Тэгээд хэсэг хугацаанд энэ зүйл унтдаг. Тэгээд тэр дахин ирж, хэдэн хуудас хуулж байна.
Энэ бол туйлын энгийн түүх юм. Энд байгаа асуудал бол усан сантай адил бөгөөд нэг хоолой руу цутгахад нөгөө рүү урсдаг. Манай хяналтын цэг ирсэн бөгөөд хэрэв энэ нь хэдэн бохир хуудсыг хаяхаар илгээсэн бол pgflush цөмийн буферээс бүх зүйл аажмаар шийдэгдэх болно.
Хэрэв эдгээр бохир хуудсууд хуримтлагдсаар байвал 20% хүртэл хуримтлагддаг бөгөөд үүний дараа OS-ийн тэргүүлэх чиглэл бол бүх зүйлийг диск рүү бичих явдал юм, учир нь цахилгаан тасарч, бүх зүйл бидний хувьд муу байх болно. Жишээлбэл, бид энэ өгөгдлийг алдах болно.
Ямар арга заль вэ? Энэхүү заль мэх нь орчин үеийн ертөнцөд эдгээр параметрүүд нь машин дээрх нийт RAM-ийн 20 ба 10% -ийг эзэлдэг бөгөөд тэдгээр нь танд байгаа аливаа дискний системийн нэвтрүүлэх чадварын хувьд үнэхээр аймшигтай юм.
Та 128 ГБ RAM-тай гэж төсөөлөөд үз дээ. 12,8 ГБ таны дискний системд ирнэ. Тэнд ямар ч кэш, ямар ч массив байгаа хамаагүй, тэдгээр нь тийм ч удаан үргэлжлэхгүй.
Тиймээс бид RAID хянагчийнхаа чадавхид тулгуурлан эдгээр тоог нэн даруй тохируулахыг зөвлөж байна. Би нэн даруй 512 MB кэштэй хянагчийг энд санал болгов.
Бүх зүйл маш энгийн гэж тооцогддог. Та vm.dirty_background-г байтаар оруулж болно. Мөн эдгээр тохиргоо нь өмнөх хоёрыг цуцална. Харьцаа нь анхдагчаар эсвэл байттай нь идэвхжсэн бол байттай нь ажиллах болно. Гэхдээ би DBA-ийн зөвлөх бөгөөд өөр өөр үйлчлүүлэгчидтэй ажилладаг тул би сүрэл зурахыг хичээдэг тул хэрэв байтаар бол байтаар зурдаг. Сайн админ серверт нэмэлт санах ой нэмж, дахин ачаалахгүй, тоо нь хэвээр үлдэнэ гэсэн баталгааг хэн ч өгөөгүй. Бүх зүйл баталгаатай байхын тулд эдгээр тоог тооцоол.
Хэрэв та тохирохгүй бол яах вэ? Аливаа улайлтыг үр дүнтэй зогсоодог гэж би бичсэн боловч үнэн хэрэгтээ энэ бол ярианы дүрс юм. Үйлдлийн систем нь маш том асуудалтай байдаг - энэ нь маш олон бохир хуудастай тул таны үйлчлүүлэгчдийн үүсгэсэн IO үр дүнтэй зогссон, өөрөөр хэлбэл програм нь мэдээллийн сан руу sql query илгээхээр ирсэн тул хүлээж байна. Мэдээллийн баазыг шалгах цэг эзэлдэг тул түүнд оруулах аливаа оролт/гаралт хамгийн бага ач холбогдолтой. Тэр хэзээ дуусах нь тодорхойгүй байна. Хэрэв та арын бус улайлтад хүрсэн бол энэ нь таны бүх IO үүнийг эзэлдэг гэсэн үг юм. Тэгээд дуусах хүртэл та юу ч хийхгүй.
Энэ тайлангийн хамрах хүрээнээс давсан хоёр чухал зүйл энд байна. Эдгээр тохиргоонууд нь postgresql.conf дээрх тохиргоотой тохирч байх ёстой, өөрөөр хэлбэл хяналтын цэгийн тохиргоотой. Мөн таны дискний систем зохих ёсоор тохируулагдсан байх ёстой. Хэрэв танд RAID дээр кэш байгаа бол энэ нь зайтай байх ёстой. Хүмүүс зайгүй сайн кэштэй RAID худалдаж авдаг. Хэрэв танд RAID-д SSD байгаа бол тэдгээр нь серверийнх байх ёстой, тэнд конденсаторууд байх ёстой. Нарийвчилсан хяналтын хуудсыг энд оруулав. Энэ холбоос нь PostgreSQL дээр гүйцэтгэлийн дискийг хэрхэн тохируулах тухай миний тайланг агуулдаг. Тэнд энэ бүх шалгах хуудас бий.
Өөр юу амьдралыг маш хэцүү болгож чадах вэ? Эдгээр нь хоёр параметр юм. Тэд харьцангуй шинэ юм. Анхдагч байдлаар, тэдгээрийг өөр өөр програмуудад оруулж болно. Хэрэв тэд буруу асаалттай бол амьдралыг яг л хэцүү болгож чадна.
Харьцангуй шинэ хоёр зүйл бий. Тэд аль хэдийн гурав дахь цөмд гарч ирсэн. Энэ нь нано секундын хуваарьтай шилжих_зардал бөгөөд өгөгдмөлөөр нэг юм.
Тэд таны амьдралыг хэрхэн сүйтгэж байна вэ? Хуваарьт_шилжилтийн_зардал гэж юу вэ? Линукс дээр төлөвлөгч нь процессыг нэг CPU-ээс нөгөөд шилжүүлэх боломжтой. Асуулга гүйцэтгэдэг PostgreSQL-ийн хувьд өөр CPU руу шилжих нь бүрэн тодорхойгүй байна. Үйлдлийн системийн үүднээс цонхоо openoffice болон терминал хооронд солих үед энэ нь сайн байж болох ч мэдээллийн сангийн хувьд энэ нь маш муу. Тиймээс шилжилтийн_зардлыг дор хаяж хэдэн мянган наносекундэд том утгаар тохируулах нь зохистой бодлого юм.
Энэ нь төлөвлөгчийн хувьд юу гэсэн үг вэ? Энэ хугацаанд процесс халуун хэвээр байна гэж үзэх болно. Өөрөөр хэлбэл, хэрэв та удаан хугацааны туршид ямар нэгэн зүйл хийж байсан удаан хугацааны гүйлгээтэй бол хуваарь гаргагч үүнийг ойлгох болно. Энэ хугацаа дуусах хүртэл энэ үйл явцыг хаашаа ч шилжүүлэх шаардлагагүй гэж тэр таамаглах болно. Хэрэв процесс нь нэгэн зэрэг ямар нэг зүйл хийвэл түүнийг хаашаа ч шилжүүлэхгүй, түүнд хуваарилагдсан CPU дээр чимээгүйхэн ажиллах болно. Мөн үр дүн нь маш сайн.
Хоёрдахь цэг бол авто групп юм. Орчин үеийн мэдээллийн сантай холбоогүй тодорхой ажлын ачааллын хувьд сайн санаа байдаг - энэ нь процессуудыг эхлүүлсэн виртуал терминалаар нь бүлэглэх явдал юм. Энэ нь зарим ажилд тохиромжтой. Практикт PostgreSQL нь нэг терминалаас ажилладаг prefork бүхий олон процесст систем юм. Танд түгжигч, хяналтын цэг байгаа бөгөөд таны бүх үйлчлүүлэгчийн хүсэлтийг CPU тус бүрээр нэг хуваарь болгон нэгтгэх болно. Бие биедээ саад болж, түүнийг удаан байлгахын тулд тэд түүнийг чөлөөтэй байхыг хамтдаа хүлээх болно. Энэ бол ийм ачаалалтай үед огт шаардлагагүй түүх бөгөөд тиймээс үүнийг унтраах хэрэгтэй.
Миний хамтран зүтгэгч Алексей Лесовский энгийн pgbench ашиглан туршилт хийж, шилжилтийн_зардлыг дарааллаар нь нэмэгдүүлж, автомат группыг унтраасан. Муу техник хангамжийн ялгаа бараг 10% байсан.. Хүмүүс асуулгын хурдад ижил төстэй өөрчлөлтүүдийн үр дүнг өгдөг postgres захидлын жагсаалтын талаар хэлэлцүүлэг байдаг 50% нөлөөлсөн. Ийм түүх маш олон байдаг.
Эцэст нь эрчим хүч хэмнэх бодлогын талаар. Сайн тал нь Линуксийг зөөврийн компьютер дээр ашиглах боломжтой болсон. Мөн энэ нь батарейг сайн ашиглах болно. Гэхдээ энэ нь сервер дээр ч тохиолдож болох нь гэнэт гарч ирэв.
Түүгээр ч барахгүй, хэрэв та ямар нэгэн хостоос сервер түрээслэх юм бол "сайн" хостууд таныг илүү сайн гүйцэтгэлтэй байна гэж тоохгүй. Тэдний даалгавар бол төмрийг аль болох үр ашигтай ашиглах явдал юм. Тиймээс анхдагчаар тэд үйлдлийн систем дээр зөөврийн компьютерын эрчим хүч хэмнэх горимыг идэвхжүүлж болно.
Хэрэв та энэ зүйлийг их ачаалалтай мэдээллийн сантай сервер дээр ашигладаг бол таны сонголт acpi_cpufreq + permormance болно. Хэдийгээр эрэлт хэрэгцээтэй байсан ч асуудал гарах болно.
Intel_pstate бол арай өөр драйвер юм. Одоо үүнийг илүүд үздэг, учир нь энэ нь хожим бөгөөд илүү сайн ажилладаг.
Үүний дагуу Засаг дарга бол зөвхөн гүйцэтгэл юм. Odemand, powersave болон бусад бүх зүйл таны тухай биш юм.
Хэрэв та эрчим хүчний хэмнэлтийг идэвхжүүлбэл PostgreSQL-ийг тайлбарлах шинжилгээний үр дүн хэд хэдэн дарааллаар ялгаатай байж болно, учир нь таны өгөгдлийн сангийн CPU бараг тааварлашгүй байдлаар ажиллах болно.
Эдгээр зүйлсийг анхдагчаар оруулж болно. Тэд үүнийг анхдагчаар асаасан эсэхийг сайтар ажиглаарай. Энэ нь үнэхээр том асуудал байж болох юм.
Эцэст нь би энэ асуудалд өдөр бүр ахиц дэвшил гаргаж байгаа манай PosgreSQL-Consulting DBA багийн залуус болох Макс Богук, Алексей Лесовский нарт баярлалаа гэж хэлмээр байна. Мөн бид үйлчлүүлэгчдийнхээ төлөө чадах бүхнээ хийхийг хичээдэг бөгөөд энэ бүхэн тэдний төлөө ажиллах болно. Энэ нь нисэхийн аюулгүй байдлын заавартай адил юм. Энд бүх зүйл цусаар бичигдсэн байдаг. Эдгээр самар бүр нь ямар нэгэн асуудлын явцад олддог. Тэдгээрийг тантай хуваалцахдаа баяртай байна.
Асуулт:
Баярлалаа! Жишээлбэл, компани мөнгө хэмнэж, мэдээллийн сан болон програмын логикийг нэг сервер дээр байрлуулахыг хүсч байвал эсвэл PostgreSQL нь контейнерт ажилладаг микро үйлчилгээний архитектурын моод чиг хандлагыг дагаж мөрддөг бол. Ямар арга заль вэ? Sysctl нь дэлхий даяар цөмд бүхэлд нь нөлөөлнө. Системийн системүүдийг ямар нэгэн байдлаар виртуалчлагдсан тул контейнер дээр тусад нь ажилладаг гэж би сонсоогүй. Зөвхөн нэг бүлэг байдаг бөгөөд тэнд хяналтын хэсэг л байдаг. Та үүнтэй яаж амьдрах вэ? Эсвэл та гүйцэтгэлийг хүсч байвал PostgreSQL-г тусдаа техник хангамжийн сервер дээр ажиллуулаад тааруулах уу?
Бид таны асуултанд гурван янзаар хариулсан. Хэрэв бид тохируулах боломжтой техник хангамжийн серверийн тухай яриагүй бол тайвширвал эдгээр тохиргоогүйгээр бүх зүйл хэвийн ажиллах болно. Хэрэв танд ийм ачаалал байгаа бол эдгээр тохиргоог хийх шаардлагатай бол та эдгээр тохиргооноос өмнө төмөр серверт ирэх болно.
Асуудал юу вэ? Хэрэв энэ нь виртуал машин бол та олон асуудалтай тулгарах болно, жишээлбэл, ихэнх виртуал машинууд дээр дискний хоцролт нь хоорондоо зөрчилддөг. Дискний дамжуулалт сайн байсан ч гэсэн нэг удаа бүтэлгүйтсэн оролт гаралтын гүйлгээ нь хяналтын цэгийн үед эсвэл WAL-д бичих үед гарсан дундаж дамжуулалтад төдийлөн нөлөөлдөггүй ч мэдээллийн сан үүнд ихээхэн хохирол учруулах болно. Мөн та эдгээр асуудалтай тулгарахаасаа өмнө үүнийг анзаарах болно.
Хэрэв танд нэг сервер дээр NGINX байгаа бол танд мөн адил асуудал тулгарах болно. Тэрээр хамтын ой санамжийн төлөө тэмцэх болно. Мөн та энд тайлбарласан асуудлууд руу орохгүй.
Гэхдээ нөгөө талаас эдгээр параметрүүдийн зарим нь танд хамааралтай хэвээр байх болно. Жишээлбэл, dirty_ratio-г sysctl-ээр тохируулснаар энэ нь тийм ч галзуу биш юм - ямар ч тохиолдолд энэ нь туслах болно. Ямар нэг байдлаар та дисктэй харьцах болно. Мөн энэ нь буруу хэв маягийн дагуу байх болно. Энэ нь ерөнхийдөө миний үзүүлсэн параметрүүдийн өгөгдмөл юм. Мөн ямар ч тохиолдолд тэдгээрийг өөрчлөх нь дээр.
Гэхдээ МУИС-д асуудал гарч магадгүй. Жишээлбэл, VmWare нь яг эсрэг тохиргоотой NUMA-тай сайн ажилладаг. Энд та төмөр сервер эсвэл төмрийн бус серверийг сонгох хэрэгтэй.
Надад Amazon AWS-тай холбоотой асуулт байна. Тэд урьдчилан тохируулсан зургуудтай. Тэдний нэгийг Amazon RDS гэж нэрлэдэг. Тэдний үйлдлийн системд тохируулсан тохиргоо байдаг уу?
Тэнд тохиргоонууд байдаг, гэхдээ тэдгээр нь өөр өөр тохиргоо юм. Энд бид мэдээллийн сан энэ зүйлийг хэрхэн ашиглах талаар үйлдлийн системийг тохируулна. Мөн бид одоо хаашаа явах ёстойг тодорхойлох параметрүүд байдаг, тухайлбал хэлбэржүүлэх. Өөрөөр хэлбэл, бидэнд маш их нөөц хэрэгтэй байгаа тул бид одоо тэдгээрийг идэх болно. Үүний дараа Amazon RDS эдгээр нөөцийг чангатгаж, гүйцэтгэл нь буурдаг. Хүмүүс энэ асуудалд хэрхэн хутгалдаж эхэлсэн тухай хувь хүний түүх байдаг. Заримдаа бүр нэлээд амжилттай байдаг. Гэхдээ энэ нь үйлдлийн системийн тохиргоотой ямар ч холбоогүй юм. Энэ нь үүлийг хакердсантай адил юм. Энэ бол өөр түүх.
Ил тод том хуудсууд яагаад Huge TLB-тэй харьцуулахад ямар ч нөлөө үзүүлэхгүй байна вэ?
Битгий өг. Үүнийг олон янзаар тайлбарлаж болно. Гэвч үнэндээ тэд зүгээр л өгдөггүй. PostgreSQL-ийн түүх юу вэ? Эхлэх үед энэ нь хуваалцсан санах ойн том хэсгийг хуваарилдаг. Тэд ил тод эсэх нь огт хамаагүй. Тэд эхнээсээ онцгойрч байгаа нь бүх зүйлийг тайлбарладаг. Хэрэв санах ой их байгаа бөгөөд та хуваалцсан_санах ойн сегментийг дахин бүтээх шаардлагатай бол Ил тод том хуудсууд хамааралтай болно. PostgreSQL-д энэ нь зүгээр л эхэндээ асар том хэсэг болгон хуваарилагдсан, тэгээд л болоо, тэгээд тэнд ямар ч онцгой зүйл болохгүй. Мэдээжийн хэрэг та үүнийг ашиглаж болно, гэхдээ энэ нь ямар нэг зүйлийг дахин хуваарилах үед хуваалцсан_санах ойд гэмтэл учруулах магадлал бий. PostgreSQL энэ талаар мэдэхгүй.
Эх сурвалж: www.habr.com