Алексей Лесовскийн Дата Эгретийн "PostgreSQL мониторингийн үндэс" тайлангийн хуулбарыг уншихыг танд зөвлөж байна.
Энэ тайланд Алексей Лесовский postgres статистикийн гол цэгүүд, тэдгээр нь юу гэсэн үг вэ, яагаад хяналтанд хамрагдах ёстой талаар ярих болно; хяналтанд ямар график байх ёстой, тэдгээрийг хэрхэн нэмэх, хэрхэн тайлбарлах талаар. Энэхүү тайлан нь Postgres-ийн алдааг олж засварлахыг сонирхож буй мэдээллийн сангийн администраторууд, системийн администраторууд болон хөгжүүлэгчдэд хэрэгтэй болно.
Намайг Алексей Лесовский гэдэг, би Дата Эгретийг төлөөлдөг.
Өөрийнхөө тухай хэдэн үг. Би системийн администратороор нэлээд эрт ажиллаж эхэлсэн.
Би бүх төрлийн Линуксыг удирдаж, Линукстэй холбоотой янз бүрийн зүйлийг хийсэн, тухайлбал виртуалчлал, хяналт, прокситэй ажиллах гэх мэт. Гэвч зарим үед би мэдээллийн сан, PostgreSQL-д илүү оролцох болсон. Би түүнд үнэхээр таалагдсан. Тэгээд зарим үед би ажлынхаа ихэнх цагийг PostgreSQL-тэй харьцаж эхэлсэн. Тэгээд аажмаар би PostgreSQL DBA болсон.
Би карьерынхаа туршид статистик, мониторинг, телеметрийн сэдвүүдийг үргэлж сонирхож ирсэн. Тэгээд би системийн администратор байхдаа Zabbix дээр маш их ажилласан. гэх мэт жижиг багц скрипт бичсэн . Тэр өөрийн үед нэлээд алдартай байсан. Тэнд зөвхөн Линукс төдийгүй янз бүрийн бүрэлдэхүүн хэсгүүдийг хянах боломжтой байсан.
Одоо би PostgreSQL хийж байна. Би PostgreSQL статистиктай ажиллах боломжтой өөр нэг зүйлийг аль хэдийн бичиж байна. гэж нэрлэдэг (Хабрегийн тухай нийтлэл - ).
Жижигхэн танилцуулга. Манай үйлчлүүлэгчид, үйлчлүүлэгчидтэй холбоотой нөхцөл байдал ямар байна вэ? Мэдээллийн сантай холбоотой ямар нэгэн осол гарсан. Мэдээллийн санг сэргээсэн байхад хэлтсийн дарга юм уу хөгжлийн дарга ирээд: "Найзууд аа, бид мэдээллийн санд хяналт тавих хэрэгтэй, учир нь ямар нэг муу зүйл болсон, цаашид ийм зүйл болохгүй" гэж хэлдэг. Эндээс та PostgreSQL, MySQL болон бусад мэдээллийн баазаа хянах боломжтой мониторингийн системийг сонгох эсвэл одоо байгаа хяналтын системийг тохируулах сонирхолтой үйл явц эхэлж байна. Мөн хамт ажиллагсад нь "Ийм ийм мэдээллийн сан байдаг гэж сонссон. Үүнийг ашиглацгаая." Хамт ажиллагсад хоорондоо маргаж эхэлдэг. Эцэст нь бид ямар нэгэн мэдээллийн баазыг сонгох нь тодорхой болсон боловч PostgreSQL-ийн хяналт үүнд маш сул байдаг тул бид үргэлж ямар нэг зүйлийг дуусгах хэрэгтэй болдог. GitHub-аас зарим репозиторуудыг авч, клон хийж, скриптүүдийг тохируулж, ямар нэгэн байдлаар тохируулаарай. Тэгээд эцэст нь энэ нь ямар нэгэн гар аргаар унадаг.
Тиймээс энэ тайланд би танд зөвхөн PostgreSQL төдийгүй мэдээллийн баазын мониторингийг хэрхэн сонгох талаар мэдлэг олгохыг хичээх болно. Мөн танд ямар нэгэн үр өгөөжийг хүртэхийн тулд хяналтаа дуусгах, ингэснээр та удалгүй тохиолдож болох онцгой байдлын нөхцөл байдлаас урьдчилан сэргийлэхийн тулд мэдээллийн сандаа хяналт тавих боломжийг олгоно.
Мөн энэ тайланд тусгагдсан санаануудыг DBMS эсвэл noSQL гэх мэт ямар ч мэдээллийн санд шууд тохируулах боломжтой. Тиймээс энд зөвхөн PostgreSQL биш, PostgreSQL дээр үүнийг хэрхэн хийх талаар олон жор байх болно. PostgreSQL-д хяналт тавихад зориулагдсан асуулгын жишээ, аж ахуйн нэгжүүдийн жишээ байх болно. Хэрэв таны DBMS нь танд хяналт тавих боломжийг олгодог ижил зүйлтэй бол тэдгээрийг дасан зохицож, нэмж оруулбал зүгээр байх болно.
Би мэдээлэхгүй
хэмжигдэхүүнийг хэрхэн хүргэх, хадгалах талаар ярилц. Мэдээллийн дараах боловсруулалт, хэрэглэгчдэд өгөх талаар би юу ч хэлэхгүй. Мөн би анхааруулах талаар юу ч хэлэхгүй.
Гэхдээ түүхийн явцад би одоо байгаа мониторингийн янз бүрийн дэлгэцийн агшинг харуулах болно, ямар нэгэн байдлаар би тэднийг шүүмжлэх болно. Гэсэн хэдий ч би эдгээр бүтээгдэхүүний сурталчилгаа эсвэл эсрэг сурталчилгаа үүсгэхгүйн тулд брэндүүдийг нэрлэхгүй байхыг хичээх болно. Тиймээс бүх тохиолдлууд санамсаргүй бөгөөд таны төсөөлөлд үлддэг.
Эхлээд мониторинг гэж юу болохыг ойлгоцгооё. Хяналт тавих нь маш чухал зүйл юм. Үүнийг хүн бүр ойлгож байгаа. Гэхдээ үүнтэй зэрэгцэн хяналт нь бизнесийн бүтээгдэхүүнтэй холбоогүй бөгөөд компанийн ашиг орлогод шууд нөлөөлдөггүй тул хяналтад үргэлж үлдэгдэл хэлбэрээр хугацаа өгдөг. Хэрэв бидэнд цаг байгаа бол бид хяналт тавьж байна, цаг байхгүй бол бид үүнийг хоцрогдолд оруулж, хэзээ нэгэн цагт бид эдгээр ажлуудад буцаж очих болно.
Тиймээс, бидний туршлагаас харахад бид үйлчлүүлэгчид дээр ирэхэд мониторинг нь ихэвчлэн хөгжөөгүй, мэдээллийн баазтай ажиллахад бидэнд туслах сонирхолтой зүйл байдаггүй. Тиймээс хяналтыг үргэлж дуусгах шаардлагатай байдаг.
Өгөгдлийн сан нь мэдээллийн агуулах учраас та бас хянах хэрэгтэй маш нарийн төвөгтэй зүйлүүд юм. Мөн мэдээлэл нь компанийн хувьд маш чухал бөгөөд үүнийг ямар ч байдлаар алдаж болохгүй. Гэхдээ үүний зэрэгцээ мэдээллийн сан нь маш нарийн төвөгтэй програм хангамж юм. Тэдгээр нь олон бүрэлдэхүүн хэсгүүдээс бүрддэг. Мөн эдгээр бүрэлдэхүүн хэсгүүдийн ихэнхийг хянах шаардлагатай.
Хэрэв бид PostgreSQL-ийн талаар тусгайлан ярьж байгаа бол үүнийг олон тооны бүрэлдэхүүн хэсгүүдээс бүрдэх ийм схемээр төлөөлж болно. Эдгээр бүрэлдэхүүн хэсгүүд нь хоорондоо харилцан үйлчилдэг. Үүний зэрэгцээ PostgreSQL нь Статистик цуглуулагч дэд системтэй бөгөөд энэ нь эдгээр дэд системүүдийн үйл ажиллагааны статистик мэдээллийг цуглуулж, администратор эсвэл хэрэглэгчдэд эдгээр статистикийг харах боломжтой интерфейсээр хангах боломжийг олгодог.
Энэхүү статистикийг зарим функц, үзэл баримтлалын багц хэлбэрээр (харах) үзүүлэв. Тэдгээрийг мөн хүснэгт гэж нэрлэж болно. Өөрөөр хэлбэл, ердийн psql клиент ашиглан та мэдээллийн санд холбогдож, эдгээр функц, харагдацыг сонгож, PostgreSQL дэд системүүдийн үйл ажиллагааны талаар тодорхой тоонуудыг авах боломжтой.
Та эдгээр тоонуудыг дуртай хяналтын системдээ нэмж, график зурж, функцуудыг нэмж, урт хугацаанд аналитик авах боломжтой.
Гэхдээ энэ тайланд би эдгээр бүх функцийг үл тоомсорлохгүй, учир нь энэ нь бүтэн өдөр шаардагдах болно. Би шууд утгаараа хоёр, гурав, дөрвөн зүйлийг дурдаж, хяналтыг сайжруулахад хэрхэн тусалдаг талаар танд хэлэх болно.
Мөн мэдээллийн санд хяналт тавих тухай ярих юм бол юуг хянах ёстой вэ? Юуны өмнө бид бэлэн байдалд хяналт тавих хэрэгтэй, учир нь мэдээллийн сан нь үйлчлүүлэгчдэд өгөгдөлд нэвтрэх боломжийг олгодог үйлчилгээ бөгөөд бид бэлэн байдалд хяналт тавихаас гадна түүний чанарын болон тоон шинж чанарыг хангах шаардлагатай байдаг.
Мөн манай мэдээллийн санд холбогдож буй үйлчлүүлэгчдийг хянах шаардлагатай, учир нь тэдгээр нь ердийн үйлчлүүлэгч болон мэдээллийн санд хор хөнөөл учруулж болзошгүй хортой үйлчлүүлэгчид байж болно. Тэднийг бас хянаж, хянаж байх хэрэгтэй.
Үйлчлүүлэгчид өгөгдлийн санд холбогдох үед тэд манай өгөгдөлтэй ажиллаж эхэлдэг нь тодорхой тул бид үйлчлүүлэгчид өгөгдөлтэй хэрхэн ажилладагийг хянах хэрэгтэй: аль хүснэгтүүдтэй, бага хэмжээгээр аль индекстэй. Өөрөөр хэлбэл, бид үйлчлүүлэгчдийнхээ бий болгож буй ажлын ачааллыг үнэлэх хэрэгтэй.
Гэхдээ ажлын ачаалал нь мэдээж хүсэлтээс бүрддэг. Програмууд нь мэдээллийн санд холбогдож, асуулга ашиглан өгөгдөлд ханддаг тул мэдээллийн санд ямар асуулга байгааг үнэлэх, тэдгээрийн хүрэлцээг хянах, муруй бичээгүй, зарим сонголтыг дахин бичиж, хурдан ажиллахын тулд хийх шаардлагатай байна. мөн илүү сайн гүйцэтгэлтэй.
Мөн бид мэдээллийн сангийн тухай ярьж байгаа тул мэдээллийн сан нь үргэлж суурь процессууд юм. Суурь процессууд нь өгөгдлийн сангийн гүйцэтгэлийг сайн түвшинд байлгадаг тул тэдгээрийг ажиллуулахын тулд тодорхой хэмжээний нөөц шаарддаг. Үүний зэрэгцээ тэдгээр нь үйлчлүүлэгчийн хүсэлтийн нөөцтэй давхцаж болох тул суурь процессуудын шуналтай ажил нь үйлчлүүлэгчийн хүсэлтийн гүйцэтгэлд шууд нөлөөлдөг. Тиймээс тэдгээрийг мөн хянах, хянах шаардлагатай бөгөөд ингэснээр суурь үйл явцын хувьд гажуудал байхгүй болно.
Системийн хэмжигдэхүүн дэх мэдээллийн сангийн мониторингийн хувьд энэ нь бүх зүйл юм. Гэхдээ ихэнх тохиолдолд манай дэд бүтэц бүхэлдээ үүлэнд шилждэг тул бие даасан хостын системийн хэмжүүрүүд үргэлж ар тал руугаа ордог. Гэхдээ мэдээллийн санд тэдгээр нь хамааралтай хэвээр байгаа бөгөөд мэдээжийн хэрэг системийн хэмжүүрийг хянах шаардлагатай.
Системийн хэмжүүрийн хувьд бүх зүйл илүү их эсвэл бага байна, орчин үеийн бүх хяналтын системүүд эдгээр хэмжигдэхүүнийг аль хэдийн дэмждэг боловч ерөнхийдөө зарим бүрэлдэхүүн хэсгүүд хангалтгүй хэвээр байгаа бөгөөд зарим зүйлийг нэмэх шаардлагатай байна. Би бас тэдэнд хүрэх болно, тэдний тухай хэд хэдэн слайд байх болно.
Төлөвлөгөөний эхний зүйл бол хүртээмж юм. Хүртээмж гэж юу вэ? Миний ойлголтоор хүртээмжтэй байх нь суурийн холболтод үйлчлэх чадвар, өөрөөр хэлбэл суурь нь дээшилсэн, үйлчилгээний хувьд үйлчлүүлэгчдийн холболтыг хүлээн авдаг. Мөн энэ хүртээмжийг зарим шинж чанараар үнэлж болно. Эдгээр шинж чанарууд нь хяналтын самбар дээр харуулахад маш тохиромжтой.
Хяналтын самбар гэж юу болохыг хүн бүр мэддэг. Энэ бол шаардлагатай мэдээллийг нэгтгэн харуулсан дэлгэцийг нэг удаа харахад юм. Мэдээллийн санд асуудал байгаа эсэхийг та тэр даруй тодорхойлох боломжтой.
Үүний дагуу мэдээллийн сангийн бэлэн байдал болон бусад гол шинж чанаруудыг хяналтын самбарт байнга байрлуулж байх ёстой бөгөөд ингэснээр энэ мэдээлэл үргэлж тантай хамт байх болно. Гэнэтийн ослын мөрдөн байцаалт, зарим онцгой байдлын мөрдөн байцаалтын явцад аль хэдийн тусалдаг зарим нэмэлт мэдээллийг хоёрдогч хяналтын самбар дээр байрлуулах эсвэл гуравдагч этгээдийн хяналтын системд хүргэдэг өрөмдлөгийн холбоосууд дээр нуусан байх шаардлагатай.
Нэг мэдэгдэж байгаа хяналтын системийн жишээ. Энэ бол маш гайхалтай хяналтын систем юм. Энэ нь маш их мэдээлэл цуглуулдаг боловч миний бодлоор хяналтын самбар гэсэн хачирхалтай ойлголттой байдаг. "Хяналтын самбар үүсгэх" гэсэн холбоос байна. Гэхдээ та хяналтын самбар үүсгэхдээ хоёр багана бүхий жагсаалт, диаграмын жагсаалтыг үүсгэдэг. Мөн та ямар нэг зүйлийг харах шаардлагатай бол хулганаар товшиж, гүйлгэж, хүссэн графикаа хайж эхэлдэг. Энэ нь цаг хугацаа шаарддаг, өөрөөр хэлбэл, ийм хяналтын самбар байхгүй. Зөвхөн графикуудын жагсаалт байдаг.
Эдгээр хяналтын самбарт юу нэмэх ёстой вэ? Та хариу өгөх хугацаа гэх мэт шинж чанараас эхэлж болно. PostgreSQL нь pg_stat_statements харагдацтай. Энэ нь анхдагчаар идэвхгүй, гэхдээ энэ нь үргэлж идэвхжүүлж, ашиглах ёстой системийн чухал үзвэрүүдийн нэг юм. Энэ нь мэдээллийн санд гүйцэтгэсэн бүх асуулгын талаархи мэдээллийг хадгалдаг.
Үүний дагуу бид бүх хүсэлтийн гүйцэтгэлийн нийт хугацааг авч, дээрх талбаруудыг ашиглан хүсэлтийн тоогоор хувааж болно гэдгээс эхэлж болно. Гэхдээ энэ бол эмнэлэгт ийм дундаж температур юм. Бид бусад талбарууд дээр бүтээн байгуулалт хийх боломжтой - асуулга гүйцэтгэх хамгийн бага хугацаа, хамгийн их ба медиан. Мөн бид хувь хэмжээг ч бий болгож чадна, PostgreSQL үүнд тохирох функцуудтай. Бид өгөгдлийн сангийн аль хэдийн дууссан хүсэлтийн хариу өгөх хугацааг тодорхойлдог тоонуудыг авч болно, өөрөөр хэлбэл бид "1-ийг сонгох" гэсэн хуурамч хүсэлтийг гүйцэтгэдэггүй бөгөөд хариу өгөх хугацааг хардаггүй, харин аль хэдийн дууссан хүсэлтийн хариу өгөх хугацааг шинжилж, аль нэгийг нь зурдаг. тусдаа зураг эсвэл бид түүн дээр үндэслэн график байгуулдаг.
Мөн систем нь одоо үүсгэж буй алдааны тоог хянах нь чухал юм. Үүний тулд та pg_stat_database харагдацыг ашиглаж болно. Бид xact_rollback талбарыг онилж байна. Энэ талбар нь мэдээллийн санд гарч буй буцаалтын тоог харуулахаас гадна алдааны тоог харгалзан үздэг. Харьцангуйгаар хэлбэл, бид энэ зургийг хяналтын самбартаа харуулж, одоогоор хичнээн алдаа байгааг харж болно. Хэрэв маш олон алдаа байгаа бол энэ нь бүртгэлийг судалж, ямар төрлийн алдаа, яагаад гарч байгааг олж мэдээд дараа нь хөрөнгө оруулалт хийж, шийдвэрлэх сайн шалтгаан юм.
Та тахометр гэх мэт зүйлийг нэмж болно. Эдгээр нь секундэд хийгдэх гүйлгээний тоо, секундэд хийх хүсэлтийн тоо юм. Харьцангуйгаар хэлбэл, та эдгээр тоонуудыг өгөгдлийн сангийнхаа одоогийн гүйцэтгэл болгон ашиглаж, хүсэлтийн оргил үе, гүйлгээний оргил үе байгаа эсэх, эсвэл эсрэгээр ямар нэгэн төрлийн backend унасан тул мэдээллийн сан бага ачаалалтай байгаа эсэхийг ажиглаж болно. Энэ зургийг үргэлж харж, манай төслийн хувьд ийм гүйцэтгэл хэвийн гэдгийг санах нь чухал бөгөөд дээрх болон доорх утгууд нь аль хэдийн асуудалтай, ойлгомжгүй байдаг тул яагаад ийм тоо гарч байгааг олж мэдэх хэрэгтэй гэсэн үг юм. .
Гүйлгээний тоог тооцоолохын тулд бид pg_stat_database харагдац руу дахин хандаж болно. Бид секундэд хийх гүйлгээний тоог авахын тулд амлалтын тоо болон буцаалтын тоог нэмж болно.
Нэг гүйлгээнд хэд хэдэн хүсэлт багтах боломжтой гэдгийг хүн бүр ойлгож байна уу? Тиймээс TPS болон QPS нь арай өөр юм.
Секундэд ирэх хүсэлтийн тоог pg_stat_statements-аас авч, гүйцэтгэсэн бүх хүсэлтийн нийлбэрийг тооцоолоход хангалттай. Бид одоогийн утгыг өмнөхтэй нь харьцуулж, хасаж, дельта авч, дүнг авдаг нь тодорхой байна.
Хэрэв та хүсвэл нэмэлт хэмжигдэхүүнүүдийг нэмэх боломжтой бөгөөд энэ нь манай мэдээллийн сангийн бэлэн байдлыг үнэлэх, сул зогсолт байгаа эсэхийг хянахад тусална.
Эдгээр үзүүлэлтүүдийн нэг нь ажиллах хугацаа юм. Гэхдээ PostgreSQL дээр ажиллах хугацаа нь жаахан төвөгтэй байдаг. Яагаад гэдгийг нь хэлье. PostgreSQL ажиллаж эхлэхэд ашиглалтын хугацааг тайлагнаж эхэлдэг. Гэхдээ, жишээлбэл, шөнийн цагаар ямар нэг ажил хийгдэж байсан бол OOM-алуурчин ирж, PostgreSQL-ийн хүүхдийн процессыг хүчээр зогсоосон бол энэ тохиолдолд PostgreSQL бүх үйлчлүүлэгчдийн холболтыг зогсоож, санах ойн хэсгийг дахин тохируулж, сэргээх ажлыг эхлүүлнэ. сүүлчийн хяналтын цэг. Шалгах цэгээс сэргээх ажиллагаа үргэлжилж байгаа ч мэдээллийн сан холболтыг хүлээн авдаггүй, өөрөөр хэлбэл энэ нөхцөл байдлыг сул зогсолт гэж үнэлж болно. Гэхдээ энэ нь ажиллах цагийн тоолуурыг дахин тохируулахгүй, учир нь энэ нь шуудангийн менежерийг эхний мөчөөс эхлүүлсэн цагийг харгалзан үздэг. Тиймээс ийм нөхцөл байдлыг алгасаж болно.
Та мөн вакуум ажилчдын тоог хянах хэрэгтэй. PostgreSQL дээр автовакуум гэж юу болохыг хүн бүр мэддэг үү? Энэ бол PostgreSQL-ийн сонирхолтой дэд систем юм. Энэ талаар олон нийтлэл бичсэн, олон илтгэл тавигдсан. Вакуум, энэ нь хэрхэн ажиллах талаар олон хэлэлцүүлэг. Олон хүмүүс үүнийг зайлшгүй муу зүйл гэж үздэг. Гэхдээ тийм байна. Энэ бол ямар ч гүйлгээнд шаардлагагүй мөрүүдийн хуучирсан хувилбаруудыг цэвэрлэж, шинэ мөрүүдэд хүснэгт, индексийн зайг чөлөөлдөг нэг төрлийн хог цуглуулагч юм.
Үүнийг яагаад хянах ёстой вэ? Учир нь вакуум заримдаа маш их өвддөг. Энэ нь их хэмжээний нөөцийг зарцуулдаг бөгөөд үйлчлүүлэгчийн хүсэлтүүд үүнээс болж зовж эхэлдэг.
Үүнийг pg_stat_activity харагдацаар хянах ёстой бөгөөд энэ талаар би дараагийн хэсэгт ярих болно. Энэ харагдац нь мэдээллийн сан дахь одоогийн үйл ажиллагааг харуулдаг. Мөн энэ үйл ажиллагаагаар бид яг одоо ажиллаж байгаа вакуумуудын тоог хянах боломжтой. Бид тоос сорогчийг хянаж, хэрэв бид хязгаараас хэтэрсэн бол энэ нь PostgreSQL тохиргоог судалж, вакуумын ажиллагааг ямар нэгэн байдлаар оновчтой болгох боломж юм гэдгийг харж болно.
PostgreSQL-ийн өөр нэг онцлог нь PostgreSQL нь урт гүйлгээнд маш их өвддөг. Ялангуяа, удаан хугацаагаар гацсан, юу ч хийдэггүй гүйлгээнээс. Эдгээр нь гүйлгээний зогсолт гэж нэрлэгддэг статистик юм. Ийм гүйлгээ нь цоожтой бөгөөд энэ нь вакуум ажиллахаас сэргийлдэг. Үүний үр дүнд хүснэгтүүд хавдаж, хэмжээ нь нэмэгддэг. Мөн эдгээр хүснэгтүүдтэй ажилладаг асуулга нь илүү удаан ажиллаж эхэлдэг, учир нь та бүх хуучин хувилбаруудыг санах ойгоос диск рүү, буцааж авах хэрэгтэй. Тиймээс хамгийн урт гүйлгээний хугацаа, үргэлжлэх хугацаа, хамгийн урт вакуум хүсэлтийг хянах шаардлагатай. Хэрэв бид маш удаан хугацаанд, OLTP ачааллын хувьд 10-20-30 минутаас дээш хугацаанд ажиллаж байгаа зарим процессуудыг олж харвал бид тэдэнд анхаарлаа хандуулж, дуусгах, эсвэл програмыг оновчтой болгох хэрэгтэй. тэднийг дууддаггүй бөгөөд тийм ч удаан унждаггүй. Аналитик ачааллын хувьд 10-20-30 минут хэвийн, урт нь бас байдаг.
Дараа нь бид холбогдсон үйлчлүүлэгчидтэй сонголт хийх боломжтой. Бид аль хэдийн хяналтын самбар үүсгэж, үүн дээр хүртээмжтэй байдлын гол хэмжигдэхүүнүүдийг байршуулсан үед бид тэнд холбогдсон үйлчлүүлэгчдийн талаар нэмэлт мэдээллийг нэмж болно.
PostgreSQL-ийн үүднээс авч үзвэл өөр өөр төрлийн үйлчлүүлэгчид байдаг тул холбогдсон үйлчлүүлэгчдийн талаарх мэдээлэл чухал юм. Сайн үйлчлүүлэгч ч байна, муу үйлчлүүлэгч ч байна.
Энгийн жишээ. Үйлчлүүлэгч гэж би програмыг хэлж байна. Аппликейшн нь мэдээллийн санд холбогдсон бөгөөд тэр даруй хүсэлтээ тэнд илгээж эхэлдэг бөгөөд мэдээллийн сан нь тэдгээрийг боловсруулж, гүйцэтгэж, үр дүнг үйлчлүүлэгч рүү буцаадаг. Эдгээр нь сайн, зөв үйлчлүүлэгчид юм.
Үйлчлүүлэгч холбогдсон нөхцөл байдал байдаг, энэ нь холболтыг хадгалж байдаг, гэхдээ юу ч хийхгүй. Энэ нь идэвхгүй байдалд байна.
Гэхдээ муу үйлчлүүлэгчид байдаг. Жишээлбэл, ижил үйлчлүүлэгч холбогдож, гүйлгээ нээгээд, мэдээллийн санд ямар нэг зүйл хийж, дараа нь код руу орж, жишээлбэл, гадаад эх сурвалж руу хандах эсвэл хүлээн авсан өгөгдлийг тэнд боловсруулах. Гэхдээ тэр үед тэр гүйлгээг хаагаагүй. Мөн гүйлгээ нь мэдээллийн санд өлгөгдсөн бөгөөд цоожыг шугаман дээр хадгалдаг. Энэ бол муу улс. Хэрэв гэнэт програм доторх хаа нэгтээ онцгой тохиолдол (Үл хамаарах) тохиолдвол гүйлгээ нь маш удаан хугацаанд нээлттэй хэвээр үлдэж болно. Энэ нь PostgreSQL-ийн гүйцэтгэлд шууд нөлөөлдөг. PostgreSQL илүү удаан ажиллах болно. Тиймээс ийм үйлчлүүлэгчдийг цаг тухайд нь хянаж, ажлыг нь албадан зогсоох нь чухал юм. Ийм нөхцөл байдал гарахгүйн тулд та програмаа оновчтой болгох хэрэгтэй.
Бусад муу үйлчлүүлэгчид үйлчлүүлэгчээ хүлээж байна. Гэвч нөхцөл байдлын улмаас тэд муу болдог. Жишээлбэл, энгийн сул гүйлгээ: энэ нь гүйлгээг нээж, зарим мөрөнд түгжигдэх боломжтой, дараа нь кодын хаа нэгтээ унаж, өлгөгдсөн гүйлгээг үлдээх болно. Өөр үйлчлүүлэгч ирж, ижил өгөгдлийг хүсэх боловч түгжээтэй тулгарах болно, учир нь тэр өлгөгдсөн гүйлгээ нь шаардлагатай зарим эгнээнд түгжээтэй байдаг. Хоёрдахь гүйлгээ нь эхний гүйлгээ дуусах эсвэл түүний администратор түүнийг хүчээр хаах үед хүлээгдэж байх болно. Тиймээс хүлээгдэж буй гүйлгээ нь мэдээллийн сангийн холболтын хязгаарыг хуримтлуулж, хэтрүүлж болно. Мөн хязгаар дүүрсэн үед програм нь мэдээллийн сантай ажиллах боломжгүй болно. Энэ нь төслийн хувьд аль хэдийн онцгой нөхцөл байдал юм. Тиймээс муу үйлчлүүлэгчдийг цаг тухайд нь хянаж, хариу өгөх хэрэгтэй.
Хяналтын өөр нэг жишээ. Мөн энд зохистой хяналтын самбар байна. Дээрээс холболтын мэдээлэл байна. DB холболт - 8 ширхэг. Тэгээд энэ бүгд. Бидэнд ямар үйлчлүүлэгч идэвхтэй, ямар үйлчлүүлэгч юу ч хийхгүй зүгээр л сул ажиллаж байгаа талаар мэдээлэл алга. Өгөгдсөн гүйлгээ, хүлээгдэж буй холболтын талаар ямар ч мэдээлэл байхгүй, өөрөөр хэлбэл энэ нь холболтын тоог харуулсан ийм тоо юм, тэгээд л болоо. Тэгээд өөрөө таах хэрэгтэй.
Үүний дагуу хяналтад энэ мэдээллийг нэмэхийн тулд pg_stat_activity системийн харагдацыг үзэх шаардлагатай. Хэрэв та PostgreSQL-д маш их цаг зарцуулдаг бол энэ нь PostgreSQL-ийн одоогийн үйл ажиллагаа, өөрөөр хэлбэл түүн дээр юу болж байгааг харуулдаг тул таны найз болох ёстой маш сайн үзэл бодол юм. Процесс бүрийн хувьд энэ үйл явцын талаарх мэдээллийг харуулдаг тусдаа мөр байдаг: аль хостоос холболт хийгдсэн, ямар хэрэглэгч, ямар нэрээр, хэзээ гүйлгээг эхлүүлсэн, одоогоор ямар хүсэлт хийгдэж байгаа, хамгийн сүүлд ямар хүсэлтийг гүйцэтгэсэн. Үүний дагуу бид үйлчлүүлэгчийн төлөв байдлыг статистикийн талбараар үнэлж болно. Харьцангуйгаар хэлбэл, бид энэ талбараар бүлэглэж, одоо мэдээллийн санд байгаа статистикууд болон өгөгдлийн сан дахь энэ статтай холбогдсон холболтын тоог авах боломжтой. Мөн бид аль хэдийн хүлээн авсан тоонуудыг хяналтандаа илгээж, график зурж болно.
Мөн гүйлгээний үргэлжлэх хугацааг үнэлэх нь чухал юм. Вакуум үргэлжлэх хугацааг үнэлэх нь чухал гэдгийг би аль хэдийн хэлсэн, гэхдээ гүйлгээг мөн адил үнэлдэг. Xact_start болон query_start талбарууд байдаг. Тэд харьцангуйгаар гүйлгээ эхлэх цаг болон хүсэлтийн эхлэх цагийг харуулдаг. Бид одоогийн цагийн тэмдгийг харуулдаг now() функцийг авч, гүйлгээ болон хүсэлтийн цагийн тэмдгийг хасна. Мөн бид гүйлгээний үргэлжлэх хугацаа, хүсэлтийн үргэлжлэх хугацааг авдаг.
Хэрэв бид урт хугацааны гүйлгээг харвал тэдгээрийг аль хэдийн дуусгах ёстой. OLTP ачааллын хувьд урт гүйлгээ нь аль хэдийн 1-2-3 минутаас илүү байдаг. OLAP ачааллын хувьд урт хугацааны гүйлгээ нь хэвийн зүйл боловч хоёр цагаас илүү хугацаанд үргэлжилдэг бол энэ нь бас хаа нэгтээ хазайсан шинж тэмдэг юм.
Үйлчлүүлэгчид мэдээллийн санд холбогдсоны дараа тэд манай өгөгдөлтэй ажиллаж эхэлдэг. Тэд хүснэгтэд хандаж, хүснэгтээс өгөгдөл авахын тулд индекст ханддаг. Мөн үйлчлүүлэгчид энэ өгөгдөлтэй хэрхэн ажилладагийг үнэлэх нь чухал юм.
Энэ нь бидний ажлын ачааллыг үнэлэх, ямар хүснэгтүүд "хамгийн халуун" байгааг ойлгоход зайлшгүй шаардлагатай. Жишээлбэл, бид ямар нэгэн хурдан SSD санах ойн дээр "халуун" ширээ байрлуулахыг хүсч байгаа нөхцөлд энэ нь зайлшгүй шаардлагатай. Жишээлбэл, бидний удаан хугацаанд ашиглаагүй зарим архивын хүснэгтүүдийг ямар нэгэн "хүйтэн" архив, SATA диск рүү шилжүүлж, тэндээ амьдруулах боломжтой, шаардлагатай бол тэдгээрт хандах болно.
Энэ нь аливаа хувилбар болон байршуулалтын дараа гажиг илрүүлэхэд тустай. Төсөл зарим шинэ функцийг нэвтрүүлсэн гэж бодъё. Жишээлбэл, бид мэдээллийн сантай ажиллах шинэ функцийг нэмсэн. Хэрэв бид хүснэгтийг ашиглах графикийг бүтээвэл эдгээр график дээрх эдгээр гажигийг хялбархан илрүүлж чадна. Жишээлбэл, тэсрэлтүүдийг шинэчлэх эсвэл тэсрэлтүүдийг устгах. Энэ нь маш тод харагдах болно.
Мөн "хөвөгч" статистикийн гажиг илрүүлэх боломжтой. Энэ нь юу гэсэн үг вэ? PostgreSQL нь маш хүчтэй, маш сайн асуулга төлөвлөгчтэй. Хөгжүүлэгчид үүнийг хөгжүүлэхэд маш их цаг зарцуулдаг. Тэр яаж ажилладаг вэ? Сайн төлөвлөгөө гаргахын тулд PostgreSQL нь хүснэгтэд өгөгдөл түгээх статистикийг тодорхой хугацааны интервалтайгаар, тодорхой давтамжтайгаар цуглуулдаг. Эдгээр нь хамгийн түгээмэл утгууд юм: өвөрмөц утгуудын тоо, хүснэгт дэх NULL-ийн талаарх мэдээлэл, маш их мэдээлэл.
Эдгээр статистик тоон дээр үндэслэн төлөвлөгч хэд хэдэн асуулга үүсгэж, хамгийн оновчтойг нь сонгон, уг асуулгын төлөвлөгөөг ашиглан асуулгаа өөрөө гүйцэтгэж, өгөгдлийг буцаана.
Статистикууд "хөвөгч" байдаг. Хүснэгтэнд чанар, тоо хэмжээний мэдээлэл ямар нэгэн байдлаар өөрчлөгдсөн боловч статистик мэдээлэл цуглуулаагүй байна. Мөн боловсруулсан төлөвлөгөө нь оновчтой биш байж магадгүй юм. Хүснэгтийн дагуу цуглуулсан мониторингийн хувьд бидний төлөвлөгөө оновчтой биш бол бид эдгээр гажуудлыг харах боломжтой болно. Жишээлбэл, хаа нэгтээ өгөгдөл чанарын хувьд өөрчлөгдөж, индексийн оронд хүснэгтээр дамжуулан дараалсан дамжуулалтыг ашиглаж эхэлсэн, өөрөөр хэлбэл. хэрэв асуулгад зөвхөн 100 мөрийг буцаах шаардлагатай бол (100-ийн хязгаартай) энэ асуулгад бүрэн тооллого хийх болно. Мөн энэ нь үргэлж гүйцэтгэлд маш муу нөлөө үзүүлдэг.
Мөн бид үүнийг хяналтаас харж болно. Мөн энэ асуулгыг аль хэдийн харж, тайлбарлаж, статистик цуглуулж, шинэ нэмэлт индекс үүсгэ. Мөн энэ асуудалд аль хэдийн хариу өгсөн. Тиймээс энэ нь чухал юм.
Хяналтын өөр нэг жишээ. Тэр маш алдартай учраас олон хүн түүнийг таньдаг гэж бодож байна. Төсөлдөө хэн ашигладаг ? Мөн хэн энэ бүтээгдэхүүнийг Prometheus-тай хамт хэрэглэдэг вэ? Баримт нь энэхүү мониторингийн стандарт агуулахад PostgreSQL-тэй ажиллах хяналтын самбар байдаг - Прометей. Гэхдээ энд нэг муу зүйл байна.
Хэд хэдэн график байдаг. Мөн байтыг нэгдмэл байдлаар тодорхойлсон, өөрөөр хэлбэл 5 график байна. Үүнд: Өгөгдөл оруулах, Өгөгдлийг шинэчлэх, Өгөгдлийг устгах, Өгөгдлийг татах, Өгөгдлийг буцаах. Байтыг нэгж хэмжээс гэж заасан. Гэхдээ PostgreSQL дэх статистик нь өгөгдлийг tuple (мөр) хэлбэрээр буцаадаг явдал юм. Үүний дагуу эдгээр графикууд нь таны ажлын ачааллыг хэд хэдэн удаа, хэдэн арван удаа дутуу үнэлэх маш сайн арга юм, учир нь tuple нь байт биш, tuple нь мөр, энэ нь маш олон байт бөгөөд үргэлж хувьсах урттай байдаг. Өөрөөр хэлбэл, ажлын ачааллыг tuple ашиглан байтаар тооцоолох нь бодит бус ажил эсвэл маш хэцүү ажил юм. Тиймээс, та хяналтын самбар эсвэл суурилуулсан хяналтыг ашиглахдаа энэ нь зөв ажиллаж, зөв үнэлэгдсэн өгөгдлийг танд буцааж өгдөг гэдгийг ойлгох нь үргэлж чухал юм.
Эдгээр хүснэгтийн статистик мэдээллийг хэрхэн авах вэ? Үүнийг хийхийн тулд PostgreSQL нь гэр бүлийн үзэл бодолтой байдаг. Мөн гол үзэл бодол нь . User_tables - энэ нь хүснэгтийг хэрэглэгчийн нэрийн өмнөөс үүсгэсэн гэсэн үг юм. Үүний эсрэгээр, PostgreSQL өөрөө ашигладаг системийн үзэл бодол байдаг. Мөн систем болон хэрэглэгчийг багтаасан Alltables хураангуй хүснэгт байдаг. Та хамгийн их таалагдсан аль нэгээс нь эхэлж болно.
Дээрх талбаруудыг оруулах, шинэчлэх, устгах тоог тооцоолоход ашиглаж болно. Миний ашигласан жишээ самбар нь эдгээр талбаруудыг ажлын ачааллын шинж чанарыг үнэлэхэд ашигладаг. Тиймээс бид ч бас тэдгээр дээр тулгуурлаж болно. Гэхдээ эдгээр нь байт биш харин tuples гэдгийг санах нь зүйтэй, тиймээс бид үүнийг авч, байт болгож чадахгүй.
Эдгээр өгөгдөл дээр үндэслэн бид TopN-хүснэгтүүдийг үүсгэж болно. Тухайлбал, Топ-5, Топ-10. Мөн та бусдаас илүү ашигладаг халуун ширээг хянах боломжтой. Жишээлбэл, оруулах 5 "халуун" хүснэгт. Эдгээр TopN-хүснэгтүүдийн дагуу бид ажлын ачааллаа үнэлж, аливаа хувилбар, шинэчлэлт, байршуулалтын дараа ажлын ачааллыг үнэлэх боломжтой.
Хүснэгтийн хэмжээг үнэлэх нь бас чухал юм, учир нь заримдаа хөгжүүлэгчид шинэ функцийг гаргаж ирдэг бөгөөд манай хүснэгтүүд том хэмжээтэй болж эхэлдэг, учир нь тэд нэмэлт хэмжээний өгөгдөл нэмэхээр шийдсэн боловч энэ нь хэрхэн өөрчлөгдөхийг урьдчилан таамаглаагүй байна. мэдээллийн сангийн хэмжээнд нөлөөлнө. Ийм тохиолдлууд ч бидэнд гэнэтийн зүйл болдог.
Одоо танаас бяцхан асуулт асууя. Өгөгдлийн сангийн сервер ачааллыг анзаарсан үед ямар асуулт гарч ирдэг вэ? Таны дараагийн асуулт юу вэ?
Гэхдээ жинхэнэ асуулт бол дараах асуулт юм. Ачаалал нь ямар хүсэлтийг үүсгэдэг вэ? Өөрөөр хэлбэл, ачааллаас үүдэлтэй үйл явцыг ажиглах нь тийм ч сонирхолтой биш юм. Хэрэв хост нь өгөгдлийн сантай бол мэдээллийн сан тэнд ажиллаж байгаа бөгөөд зөвхөн мэдээллийн санг устгах нь тодорхой байна. Хэрэв бид Топыг нээх юм бол ямар нэг зүйл хийж байгаа PostgreSQL процессуудын жагсаалтыг харах болно. Дээрээс тэд юу хийж байгаа нь тодорхойгүй байх болно.
Үүний дагуу та хамгийн их ачаалал үүсгэдэг асуултуудыг олох хэрэгтэй, учир нь асуулга тааруулах нь дүрмээр бол PostgreSQL тохиргоо эсвэл үйлдлийн системийн тохируулга, тэр ч байтугай техник хангамжийн тохируулгаас илүү их ашиг өгдөг. Миний тооцоогоор 80-85-90 орчим хувьтай байна. Мөн энэ нь илүү хурдан хийгддэг. Хүсэлтийг засах нь тохиргоог засах, дахин эхлүүлэх хуваарь, ялангуяа мэдээллийн баазыг дахин эхлүүлэх боломжгүй эсвэл техник хангамж нэмэхээс илүү хурдан юм. Энэ асуулгаас илүү сайн үр дүнд хүрэхийн тулд хайлтыг хаа нэгтээ дахин бичих эсвэл индекс нэмэх нь илүү хялбар байдаг.
Үүний дагуу хүсэлт, тэдгээрийн хүрэлцээнд хяналт тавих шаардлагатай байна. Хяналтын өөр нэг жишээг авч үзье. Энд ч гэсэн маш сайн хяналттай байх шиг байна. Хуулбарлах тухай мэдээлэл, дамжуулах чадвар, хаах, нөөцийн ашиглалтын талаархи мэдээлэл байдаг. Бүх зүйл сайн байгаа ч хүсэлтийн талаар мэдээлэл алга байна. Манай мэдээллийн санд ямар асуулга ажиллаж байгаа, хэр удаан ажилладаг, эдгээр асуулгын хэд нь тодорхойгүй байна. Бид энэ мэдээллийг байнга хяналтанд байлгах хэрэгтэй.
Мөн энэ мэдээллийг авахын тулд бид pg_stat_statements модулийг ашиглаж болно. Үүний үндсэн дээр та янз бүрийн графикийг бүтээх боломжтой. Жишээлбэл, та хамгийн их ирдэг хүсэлтүүдийн талаар, өөрөөр хэлбэл хамгийн олон удаа хийгддэг хүсэлтүүдийн талаар мэдээлэл авах боломжтой. Тиймээ, байршуулсны дараа үүнийг харж, хүсэлтийн өсөлт байгаа эсэхийг ойлгох нь маш хэрэгтэй.
Та хамгийн урт хүсэлтийг хянах боломжтой, өөрөөр хэлбэл хамгийн удаан гүйцэтгүүлэх хүсэлтүүдийг. Тэд процессор дээр ажилладаг, I/O-г хэрэглэдэг. Мөн бид үүнийг нийт_цаг, дундаж_цаг, blk_write_time, blk_унших_цаг гэсэн талбараар үнэлж болно.
Бид нөөцийн ашиглалт, дискнээс уншдаг, санах ойтой ажилладаг, эсвэл эсрэгээр ямар нэгэн бичих ачааллыг бий болгодог хамгийн хүнд хүсэлтийг үнэлж, хянаж болно.
Бид хамгийн өгөөмөр хүсэлтийг үнэлж чадна. Эдгээр нь олон тооны мөрүүдийг буцаадаг асуулга юм. Жишээлбэл, энэ нь хязгаар тогтоохоо мартсан зарим төрлийн хүсэлт байж болно. Мөн энэ нь хүссэн хүснэгтүүд дээрх хүснэгт эсвэл асуулгын бүх агуулгыг буцаана.
Мөн та түр зуурын файл эсвэл түр хүснэгт ашигладаг асуулгад хяналт тавьж болно.
Мөн бидэнд суурь процессууд байсаар байна. Суурь үйл явц нь үндсэндээ хяналтын цэгүүд эсвэл тэдгээрийг хяналтын цэг гэж нэрлэдэг бөгөөд эдгээр нь автовакуум ба хуулбар юм.
Хяналтын өөр нэг жишээ. Зүүн талд "Засвар үйлчилгээ" таб байгаа бөгөөд түүн рүү очоод хэрэгтэй зүйл харна гэж найдаж байна. Гэхдээ энд зөвхөн вакуум цаг хугацаа, статистикийн цуглуулга, өөр юу ч биш. Энэ бол маш муу мэдээлэл тул та манай мэдээллийн санд суурь процессууд хэрхэн ажилладаг, тэдгээрийн ажилд ямар нэгэн асуудал гарсан эсэх талаар үргэлж мэдээлэлтэй байх шаардлагатай.
Шалгах цэгүүдийг үзэхэд манай хяналтын цэгүүд "бохир" хуудсыг хэсэгчилсэн санах ойн хэсгээс диск рүү угааж, дараа нь хяналтын цэг үүсгэдэг гэдгийг санах нь зүйтэй. Хэрэв PostgreSQL яаралтай тусламжийн үед гэнэт хаагдсан бол энэ хяналтын цэгийг сэргээх үед ашиглах боломжтой.
Үүний дагуу бүх "бохир" хуудсыг диск рүү угаахын тулд та тодорхой хэмжээний бичих хэрэгтэй. Дүрмээр бол их хэмжээний санах ойтой системүүд дээр энэ нь маш их юм. Хэрэв бид богино хугацаанд шалган нэвтрүүлэх цэгүүдийг байнга хийдэг бол дискний гүйцэтгэл маш их буурдаг. Мөн үйлчлүүлэгчийн хүсэлт нь нөөцийн хомсдолоос болж зовж шаналах болно. Тэд нөөцийн төлөө өрсөлдөж, бүтээмжгүй болно.
Үүний дагуу, заасан талбарууд дээр pg_stat_bgwriter-аар дамжуулан бид гарч буй хяналтын цэгүүдийн тоог хянах боломжтой. Хэрэв бид тодорхой хугацаанд (10-15-20 минут, хагас цагийн турш), жишээлбэл, 3-4-5 хүртэл олон хяналтын цэгүүдтэй бол энэ нь аль хэдийн асуудал болж магадгүй юм. Мөн та аль хэдийн мэдээллийн баазыг хайж, тохиргоог нь харах хэрэгтэй, ийм олон тооны хяналтын цэгүүд юу болж байгааг харах хэрэгтэй. Магадгүй ямар нэгэн том рекорд гарч ирэх байх. Бид аль хэдийн ажлын ачааллыг тооцож болно, учир нь бид ажлын ачааллын графикийг аль хэдийн нэмсэн. Бид таслах цэгийн параметрүүдийг аль хэдийн тохируулж, тэдгээр нь асуулгын гүйцэтгэлд төдийлөн нөлөөлөхгүй эсэхийг шалгах боломжтой.
Би дахин автовакуум руу буцах гэж байна, учир нь энэ нь миний хэлсэнчлэн диск болон асуулгын гүйцэтгэлийг хоёуланг нь хялбархан нэмж чаддаг тул автовакуумын хэмжээг хэмжих нь үргэлж чухал байдаг.
Мэдээллийн сан дахь автовакуум ажилчдын тоо хязгаарлагдмал. Анхдагч байдлаар, тэдгээрийн гурав нь байдаг тул хэрэв бид мэдээллийн санд байнга ажилладаг гурван ажилтантай бол энэ нь манай автовакуум дутуу тохируулагдсан байна гэсэн үг бөгөөд бид хязгаарлалтыг нэмэгдүүлж, автовакуум тохиргоог дахин хянаж, тохиргоонд аль хэдийн орох хэрэгтэй болно.
Манайд ямар вакуумчин ажиллаж байгааг үнэлэх нь чухал. Нэг бол хэрэглэгчээс эхлүүлсэн, DBA орж ирээд гараараа ямар нэгэн вакуум үүсгэсэн бөгөөд энэ нь ачаалал үүсгэсэн. Бидэнд асуудал байна. Эсвэл энэ нь гүйлгээний тоолуурыг задлах вакуумуудын тоо юм. PostgreSQL-ийн зарим хувилбаруудын хувьд эдгээр нь маш хүнд вакуум юм. Тэд хүснэгтийг бүхэлд нь хасаж, энэ хүснэгтийн бүх блокуудыг сканнердаж байгаа тул гүйцэтгэлийг хялбархан нэмж болно.
Мэдээжийн хэрэг, вакуумуудын үргэлжлэх хугацаа. Хэрэв бид маш удаан хугацаанд ажилладаг урт вакуумтай бол энэ нь вакуумын тохиргоонд дахин анхаарлаа хандуулж, тохиргоог нь эргэн харах хэрэгтэй гэсэн үг юм. Вакуум нь ширээн дээр удаан хугацаагаар (3-4 цаг) ажиллах үед нөхцөл байдал үүсч болзошгүй тул вакуум ажиллаж байх хугацаанд дахин их хэмжээний үхсэн эгнээ ширээн дээр хуримтлагдаж чадсан. Тэгээд вакуум дуусмагц тэр энэ ширээг дахин сорох хэрэгтэй. Тэгээд бид нөхцөл байдалд ирдэг - хязгааргүй вакуум. Мөн энэ тохиолдолд вакуум нь түүний ажлыг даван туулж чаддаггүй бөгөөд хүснэгтүүд нь аажмаар томорч эхэлдэг, гэхдээ доторх ашигтай мэдээллийн хэмжээ хэвээр байна. Тиймээс, урт вакуумд бид тохиргоог үргэлж харж, оновчтой болгохыг хичээдэг, гэхдээ тэр үед үйлчлүүлэгчийн хүсэлтийн гүйцэтгэл мууддаггүй.
Одоо шууд дамжуулалтыг хуулбарлаагүй PostgreSQL суулгац бараг байхгүй байна. Хуулбарлах гэдэг нь өгөгдлийг мастераас хуулбар руу шилжүүлэх үйл явц юм.
PostgreSQL дахь хуулбарыг гүйлгээний бүртгэлээр дамжуулан зохион байгуулдаг. Мастер нь гүйлгээний бүртгэлийг үүсгэдэг. Сүлжээний холболт дээрх гүйлгээний бүртгэл хуулбар руу орж, дараа нь хуулбар дээр хуулбарлагдана. Бүх зүйл энгийн.
Үүний дагуу pg_stat_replication view нь хуулбарлалтын хоцролтыг хянахад ашиглагддаг. Гэхдээ энэ нь түүнд амаргүй. 10-р хувилбарт харагдах байдал нь хэд хэдэн өөрчлөлтийг хийсэн. Нэгдүгээрт, зарим талбайн нэрийг өөрчилсөн. Мөн зарим талбарууд нэмэгдсэн. 10-р хувилбарт хуулбарлах хоцролтыг секундын дотор үнэлэх боломжийг олгодог талбарууд гарч ирэв. Энэ нь маш тухтай байдаг. 10-р хувилбараас өмнө хуулбарлах хоцролтыг байтаар тооцоолох боломжтой байсан. Энэ функц нь 10-р хувилбарт хэвээр үлдсэн бөгөөд өөрөөр хэлбэл та өөрт илүү тохиромжтой зүйлийг сонгох боломжтой - хоцролтыг байтаар үнэлэх эсвэл хоцролтыг секундын дотор үнэлэх боломжтой. Олон хүн хоёуланг нь хийдэг.
Гэхдээ хуулбарлах хоцролтыг үнэлэхийн тулд гүйлгээний бүртгэлийн байршлыг мэдэх хэрэгтэй. Гүйлгээний бүртгэлийн эдгээр байрлалууд нь pg_stat_replication харагдацад л байна. Харьцангуйгаар бид pg_xlog_location_diff() функцийг ашиглан гүйлгээний бүртгэлээс хоёр оноо авч болно. Тэдгээрийн хоорондох дельтаг тооцоолж, хуулбарлах хоцролтыг байтаар авна уу. Энэ нь маш тохиромжтой бөгөөд энгийн зүйл юм.
10-р хувилбарт энэ функцийг pg_wal_lsn_diff() болгон өөрчилсөн. Ерөнхийдөө "xlog" гэсэн үгтэй таарч байсан бүх функц, үзэл бодол, хэрэгслүүдэд үүнийг "wal" гэсэн утгаар сольсон. Энэ нь үзэл бодол, функцийн аль алинд нь байдаг. Энэ бол ийм шинэлэг зүйл юм.
Дээрээс нь 10-р хувилбарт хоцролтыг тусгайлан харуулсан мөрүүдийг нэмсэн. Эдгээр нь бичих хоцрогдол, флэш хоцролт, дахин тоглуулах хоцрогдол юм. Энэ нь эдгээр зүйлсийг хянах нь чухал юм. Хэрэв бид хуулбарлах хоцрогдолтой байгааг олж харвал яагаад үүссэн, хаанаас ирснийг судалж, асуудлыг засах хэрэгтэй.
Системийн хэмжүүрээр бараг бүх зүйл эмх цэгцтэй байна. Аливаа мониторинг төрөхөд системийн хэмжүүрээс эхэлдэг. Энэ нь процессор, санах ой, своп, сүлжээ, дискний хэрэглээ юм. Гэсэн хэдий ч олон параметрүүд анхдагч байдлаар байдаггүй.
Хэрэв процессыг устгахад бүх зүйл эмх цэгцтэй байвал дискийг устгахад асуудал гардаг. Дүрмээр бол мониторингийн хөгжүүлэгчид зурвасын өргөний мэдээллийг нэмдэг. Энэ нь iop эсвэл байт байж болно. Гэхдээ тэд хоцролт, дискний төхөөрөмжийн ашиглалтын талаар мартдаг. Эдгээр нь бидний дискүүд хэр ачаалалтай, хэр зэрэг удааширч байгааг үнэлэх боломжийг олгодог илүү чухал параметрүүд юм. Хэрэв бид өндөр хоцрогдолтой бол энэ нь дискэнд зарим асуудал байгаа гэсэн үг юм. Хэрэв бид өндөр хэрэглээтэй бол энэ нь дискийг даван туулж чадахгүй гэсэн үг юм. Эдгээр нь зурвасын өргөнөөс илүү чанарын шинж чанарууд юм.
Гэхдээ эдгээр статистикийг процессорыг дахин боловсруулахтай адил /proc файлын системээс авч болно. Яагаад энэ мэдээллийг хяналтанд нэмдэггүй юм бэ, би мэдэхгүй. Гэхдээ үүнийг хяналтандаа байлгах нь чухал хэвээр байна.
Сүлжээний интерфейсийн хувьд ч мөн адил. Сүлжээний зурвасын өргөнийг багцаар, байтаар илэрхийлсэн мэдээлэл байдаг ч хоцрогдлын тухай мэдээлэл байхгүй, ашиглалтын тухай мэдээлэл байхгүй ч энэ нь бас хэрэгтэй мэдээлэл юм.
Аливаа хяналт нь сул талтай байдаг. Мөн та ямар төрлийн хяналт тавихаас үл хамааран тодорхой шалгуурыг хангахгүй байх болно. Гэсэн хэдий ч тэд хөгжиж, шинэ боломжууд нэмэгдэж, шинэ зүйлүүд нэмэгддэг тул ямар нэг зүйлийг сонгоод дуусга.
Мөн дуусгахын тулд та өгөгдсөн статистик нь юу гэсэн үг вэ, үүнтэй холбоотой асуудлыг хэрхэн шийдвэрлэх талаар үргэлж санаатай байх ёстой.
Мөн цөөн хэдэн гол санаа:
- Та үргэлж бэлэн байдлыг хянаж, хяналтын самбартай байх хэрэгтэй бөгөөд ингэснээр бүх зүйл үндсэндээ тохирсон эсэхийг хурдан үнэлэх боломжтой.
- Муу үйлчлүүлэгчдийг устгаж, устгахын тулд та ямар үйлчлүүлэгчид таны мэдээллийн сантай ажиллаж байгаа талаар үргэлж санаатай байх хэрэгтэй.
- Эдгээр үйлчлүүлэгчид өгөгдөлтэй хэрхэн ажиллаж байгааг үнэлэх нь чухал юм. Та ажлын ачааллын талаар ойлголттой байх хэрэгтэй.
- Энэ ачааллыг ямар асуултын тусламжтайгаар хэрхэн бүрдүүлж байгааг үнэлэх нь чухал юм. Та асуулгад үнэлгээ өгч, тэдгээрийг оновчтой болгож, дахин засварлаж, индекс үүсгэж болно. Энэ нь маш чухал юм.
- Суурь үйл явц нь үйлчлүүлэгчийн хүсэлтэд сөргөөр нөлөөлж болзошгүй тул хэт их нөөц ашиглахгүй байх нь чухал юм.
- Системийн хэмжүүрүүд нь серверийнхээ хүчин чадлыг нэмэгдүүлэх, өргөтгөх төлөвлөгөө гаргах боломжийг олгодог тул тэдгээрийг хянах, үнэлэх нь чухал юм.
Хэрэв та энэ сэдвийг сонирхож байгаа бол эдгээр холбоосыг дагаж болно.
нь статистик цуглуулагчийн албан ёсны баримт бичиг юм. Бүх статистик үзэл бодлын тодорхойлолт, бүх талбарын тайлбар байдаг. Та тэдгээрийг уншиж, ойлгож, дүн шинжилгээ хийх боломжтой. Тэдгээрийн үндсэн дээр өөрийн графикийг бүтээж, хяналтандаа нэмээрэй.
Хүсэлтийн жишээ:
Энэ бол манай байгууллагын болон миний өөрийнх юм. Тэдэнд дээжийн хүсэлт байна. Цувралаас сонгогдсон* асуусан зүйл байхгүй. Түүхий тооноос уншигдахуйц, тохиромжтой утгууд, өөрөөр хэлбэл эдгээр нь байт, цаг хугацаа юм. Та тэдгээрийг сонгож, үзэж, дүн шинжилгээ хийж, хяналтандаа нэмж, түүн дээр тулгуурлан өөрийн хяналтыг үүсгэж болно.
Асуултууд
Асуулт: Та брэндийг сурталчлахгүй гэж хэлсэн, гэхдээ би одоо ч гэсэн гайхаж байна - та төслүүддээ ямар хяналтын самбар ашигладаг вэ?
Хариулт: Янз бүрийн аргаар. Бид үйлчлүүлэгч дээр ирдэг бөгөөд тэр аль хэдийн өөрийн хяналттай байдаг. Мөн бид үйлчлүүлэгчид хяналтандаа юу нэмэх шаардлагатайг зөвлөж байна. Хамгийн муу нөхцөл бол Заббикс юм. Учир нь энэ нь TopN-график бүтээх чадваргүй юм. Бид өөрсдөө хэрэглэдэг Учир нь бид эдгээр залуустай хяналт тавих талаар зөвлөлдсөн. Тэд манай TOR дээр үндэслэн PostgreSQL мониторинг хийсэн. Би Prometheus-ээр дамжуулан мэдээлэл цуглуулж, түүнийгээ татдаг өөрийн тэжээвэр амьтны төслийг бичиж байна . Миний даалгавар бол Прометейд өөрийн экспортлогч болгож, дараа нь Графана дээр бүх зүйлийг зурах явдал юм.
Асуулт: AWR тайлангийн аналогууд эсвэл ... нэгтгэлүүд байдаг уу? Та иймэрхүү зүйлийг мэддэг үү?
Хариулт: Тийм ээ, би AWR гэж юу болохыг мэднэ, энэ бол гайхалтай зүйл. Одоогийн байдлаар ойролцоогоор дараах загварыг хэрэгжүүлдэг олон төрлийн унадаг дугуй байдаг. Тодорхой хугацааны интервалд зарим суурь үзүүлэлтүүдийг ижил PostgreSQL эсвэл тусдаа хадгалах сан руу бичдэг. Та тэднийг интернетээс google-ээс хайж болно, тэд байна. Ийм зүйлийг бүтээгчдийн нэг нь PostgreSQL урсгал дахь sql.ru форум дээр суудаг. Та түүнийг тэнд барьж болно. Тийм ээ, ийм зүйл байдаг, тэдгээрийг ашиглаж болно. нэмэх нь түүний дотор Би ч бас танд үүнийг хийх боломжийг олгодог зүйл бичдэг.
PS1 Хэрэв та postgres_exporter ашиглаж байгаа бол ямар хяналтын самбар ашиглаж байна вэ? Тэдгээрийн хэд хэдэн нь байдаг. Тэд аль хэдийн хуучирсан. Нийгэмлэг шинэчлэгдсэн загвар үүсгэж чадах уу?
PS2 Энэ нь гүйцэтгэлийн хяналт, автомат тохируулгын саналд төвлөрдөг өмчийн SaaS санал учраас pganalyze-ийг устгасан.
Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. , гуйя.
Таны бодлоор аль нь өөрөө зохион байгуулсан postgresql мониторинг (хяналтын самбартай) хамгийн шилдэг нь вэ?
-
30,0%Zabbix + Алексей Лесовский эсвэл zabbix 4.4 эсвэл libzbxpgsql + zabbix libzbxpgsql + zabbix3-ийн нэмэлтүүд
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%pganalyze бол өмчийн SaaS - устгах боломжгүй1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
10 хэрэглэгч санал өгсөн. 26 хэрэглэгч түдгэлзсэн.
Эх сурвалж: www.habr.com