Андрей Сальниковын 2016 оны эхнээс гаргасан "Postgresql-д хавагнахад хүргэдэг програмын ердийн алдаа" тайлангийн хуулбарыг уншихыг танд санал болгож байна.
Энэ тайланд би програмын кодыг боловсруулах, бичих үе шатанд гарч ирдэг програмуудын гол алдаануудад дүн шинжилгээ хийх болно. Би зөвхөн Postgresql дээр бөөгнөрөлд хүргэдэг алдаануудыг л авна. Дүрмээр бол энэ нь таны системийн гүйцэтгэлийн төгсгөлийн эхлэл юм, гэхдээ эхэндээ үүнд ямар ч урьдчилсан нөхцөл харагдахгүй байсан.
Бүгдийг угтан авахдаа баяртай байна! Энэ тайлан нь миний мэргэжил нэгт хүний өмнөх тайлан шиг техникийн шинж чанартай биш юм. Энэ тайлан нь ихэвчлэн арын системийн хөгжүүлэгчдэд зориулагдсан болно, учир нь бид маш олон үйлчлүүлэгчтэй байдаг. Мөн тэд бүгд адилхан алдаа гаргадаг. Би тэдний тухай танд хэлье. Эдгээр алдаа нь ямар аюултай, муу зүйлд хүргэдэг болохыг би тайлбарлах болно.
Яагаад алдаа гаргадаг вэ? Тэдгээрийг хоёр шалтгаанаар хийдэг: санамсаргүй байдлаар, магадгүй энэ нь ажиллах болно, мөн мэдээллийн сан ба програмын хооронд, мөн мэдээллийн санд тохиолддог зарим механизмыг мэдэхгүйгээс болж.
Хэрхэн муу болсныг харуулсан аймшигт зураг бүхий гурван жишээг би танд хэлье. Тэнд тохиолддог механизмын талаар би товчхон хэлье. Тэдэнтэй хэрхэн харьцах, хэзээ тохиолдсон, алдаанаас урьдчилан сэргийлэхийн тулд ямар урьдчилан сэргийлэх арга хэрэглэх вэ. Би танд туслах хэрэгслүүдийн талаар хэлж, хэрэгтэй холбоосуудыг өгөх болно.
Би хоёр хүснэгттэй тестийн мэдээллийн санг ашигласан. Нэг хавтан нь харилцагчийн данстай, нөгөө нь эдгээр дансны гүйлгээтэй. Мөн зарим давтамжтайгаар бид эдгээр дансны үлдэгдлийг шинэчилдэг.
Хавтангийн анхны өгөгдөл: энэ нь нэлээд жижиг, 2 МБ. Мэдээллийн сан, ялангуяа тэмдгийн хариу өгөх хугацаа маш сайн байна. Мөн нэлээд сайн ачаалал - хавтангийн дагуу секундэд 2 үйлдэл хийдэг.
Энэ тайлангаар дамжуулан би танд юу болж байгааг тодорхой ойлгохын тулд графикуудыг үзүүлэх болно. Үргэлж графиктай 2 слайд байх болно. Эхний слайд нь сервер дээр ерөнхийдөө юу болж байгааг харуулж байна.
Мөн энэ нөхцөл байдалд бид үнэхээр жижиг тэмдэгтэй байгааг харж байна. Индекс нь 2 МБ хэмжээтэй жижиг хэмжээтэй. Энэ бол зүүн талын эхний график юм.
Сервер дээрх хариу өгөх дундаж хугацаа бас тогтвортой, богино байна. Энэ бол баруун дээд талын график юм.
Зүүн доод талын график нь хамгийн урт гүйлгээг харуулж байна. Гүйлгээ хурдан хийгдэж байгааг бид харж байна. Автовакуум энд хараахан ажиллахгүй байна, учир нь энэ нь эхлэлийн туршилт байсан. Цаашид ч ажиллаж, бидэнд хэрэгтэй байх болно.
Хоёрдахь слайд нь үргэлж туршиж буй хавтанд зориулагдсан болно. Ийм нөхцөлд бид үйлчлүүлэгчийн дансны үлдэгдлийг байнга шинэчилж байдаг. Мөн шинэчлэлтийн үйлдлийн хариу өгөх дундаж хугацаа нэлээд сайн, нэг миллисекунд хүрэхгүй байгааг бид харж байна. Бид процессорын нөөцийг (энэ бол баруун дээд график) жигд бөгөөд бага хэмжээгээр зарцуулж байгааг харж байна.
Баруун доод график нь шинэчлэхээсээ өмнө хүссэн шугамаа хайж олохын тулд хичнээн үйлдлийн болон дискний санах ойг зарцуулж байгааг харуулж байна. Тэгээд тэмдгийн дагуу хийгдэх үйлдлүүдийн тоо эхэнд хэлсэнчлэн секундэд 2 байна.
Тэгээд одоо бид эмгэнэлтэй байна. Яагаад ч юм мартагдсан гүйлгээ байдаг. Шалтгаан нь ихэвчлэн улиг болсон байдаг:
- Хамгийн түгээмэл зүйл бол бид програмын кодоор гадны үйлчилгээнд нэвтэрч эхэлсэн явдал юм. Мөн энэ үйлчилгээ бидэнд хариу өгөхгүй байна. Өөрөөр хэлбэл, бид гүйлгээ нээгээд, мэдээллийн санд өөрчлөлт оруулаад программаас шуудан унших эсвэл дэд бүтцийнхээ өөр үйлчилгээ рүү явсан ч ямар нэг шалтгааны улмаас бидэнд хариу өгөхгүй байна. Тэгээд ч манай чуулган хэзээ шийдэгдэх нь тодорхойгүй гацаад байна.
- Хоёрдахь нөхцөл байдал бол ямар нэг шалтгаанаар манай кодонд онцгой тохиолдол гарсан явдал юм. Мөн онцгой тохиолдолд бид гүйлгээний хаалтыг боловсруулаагүй. Тэгээд бид нээлттэй гүйлгээ бүхий өлгөөтэй сессийг дуусгасан.
- Сүүлийнх нь бас нэлээд түгээмэл тохиолдол юм. Энэ бол чанар муутай код юм. Зарим хүрээ нь гүйлгээг нээдэг. Энэ нь өлгөгдсөн бөгөөд та програм дээр өлгөөтэй байгааг мэдэхгүй байж магадгүй юм.
Ийм зүйл хаашаа хөтөлдөг вэ?
Бидний хүснэгтүүд болон индексүүд огцом өсч эхэлдэг. Энэ нь яг л хавдах нөлөө юм. Өгөгдлийн сангийн хувьд энэ нь өгөгдлийн сангийн хариу өгөх хугацаа маш огцом нэмэгдэж, мэдээллийн сангийн серверийн ачаалал нэмэгдэнэ гэсэн үг юм. Үүний үр дүнд бидний өргөдөл хохирох болно. Учир нь хэрэв та өгөгдлийн санд хандах хүсэлтэд 10 миллисекунд кодоо зарцуулсан бол логик дээрээ 10 миллисекунд зарцуулсан бол таны функцийг дуусгахад 20 миллисекунд шаардлагатай болно. Одоо таны нөхцөл байдал маш гунигтай байх болно.
Тэгээд юу болохыг харцгаая. Зүүн доод графикаас харахад бид урт удаан хугацааны гүйлгээтэй байна. Хэрэв бид зүүн дээд графикийг харвал манай хүснэгтийн хэмжээ гэнэт хоёр мегабайтаас 300 мегабайт болтлоо өссөн байна. Үүний зэрэгцээ хүснэгтийн өгөгдлийн хэмжээ өөрчлөгдөөгүй, өөрөөр хэлбэл тэнд нэлээд их хэмжээний хог хаягдал байна.
Серверийн хариу өгөх дундаж хугацааны ерөнхий нөхцөл байдал мөн хэд хэдэн дарааллаар өөрчлөгдсөн. Өөрөөр хэлбэл сервер дээрх бүх хүсэлтүүд бүрмөсөн буурч эхэлсэн. Үүний зэрэгцээ дотоод Postgres процессыг ямар нэгэн зүйл хийхийг оролдож, нөөцийг зарцуулж буй автовакуум хэлбэрээр эхлүүлсэн.
Манай тэмдэг юу болж байна вэ? Үүнтэй адил. Тэмдгийн дагуу бидний хариу өгөх дундаж хугацаа хэд хэдэн удаа өссөн байна. Ялангуяа хэрэглэсэн нөөцийн хувьд процессорын ачаалал ихээхэн нэмэгдсэнийг бид харж байна. Энэ бол баруун дээд талын график юм. Процессор хэрэгтэй нэгийг хайж олохын тулд олон тооны хэрэггүй мөрүүдийг ялгах шаардлагатай болсон тул энэ нь нэмэгдсэн. Энэ бол баруун доод талын график юм. Үүний үр дүнд мэдээллийн сан ижил тооны хүсэлтийг боловсруулах цаг байхгүй байсан тул секундэд бидний дуудлагын тоо мэдэгдэхүйц буурч эхлэв.
Бид амьдралдаа эргэж орох хэрэгтэй. Бид интернетэд орж, урт хугацааны гүйлгээ нь асуудалд хүргэдэг болохыг олж мэдэв. Бид энэ гүйлгээг олж, устгадаг. Мөн бидний хувьд бүх зүйл хэвийн болж байна. Бүх зүйл байх ёстой шигээ ажилладаг.
Бид тайвширсан боловч хэсэг хугацааны дараа програм нь яаралтай тусламжийн өмнөхтэй адил ажиллахгүй байгааг анзаарч эхлэв. Хүсэлтийг удаан боловсруулж, мэдэгдэхүйц удаашруулсан хэвээр байна. Миний жишээн дээр нэгээс хагасаас хоёр дахин удаан. Сервер дээрх ачаалал мөн ослын өмнөх үеийнхээс өндөр байна.
Мөн асуулт: "Одоо бааз юу болж байна вэ?" Мөн суурьтай холбоотой дараах нөхцөл байдал үүсдэг. Гүйлгээний график дээр энэ нь зогссон, урт хугацааны гүйлгээ үнэхээр байхгүй байгааг харж болно. Гэвч ослын үеэр тэмдгийн хэмжээ эрс нэмэгджээ. Түүнээс хойш тэд буураагүй. Суурь дээрх дундаж хугацаа тогтворжсон. Хариултууд нь бидний хүлээн зөвшөөрөгдсөн хурдаар хангалттай ирж байх шиг байна. Автовакуум илүү идэвхтэй болж, тэмдгээр ямар нэг зүйл хийж эхлэв, учир нь энэ нь илүү их өгөгдлийг шигших шаардлагатай болдог.
Тодруулбал, бид үлдэгдлийг өөрчилдөг данстай тестийн хавтангийн дагуу: хүсэлтэд хариу өгөх хугацаа хэвийн болсон бололтой. Гэвч бодит байдал дээр энэ нь нэгээс хагас дахин их байна.
Процессорын ачааллаас харахад процессорын ачаалал сүйрэхээс өмнө шаардлагатай хэмжээнд эргэж ирээгүй байна. Шалтгаанууд нь баруун доод графикт яг таг оршдог. Тэнд тодорхой хэмжээний санах ойг хайж байгаа нь харагдаж байна. Өөрөөр хэлбэл, шаардлагатай мөрийг олохын тулд бид ашиггүй өгөгдлийг эрэмбэлэх явцад мэдээллийн сангийн серверийн нөөцийг үрдэг. Секундэд хийх гүйлгээний тоо тогтворжсон.
Ерөнхийдөө сайн, гэхдээ нөхцөл байдал өмнөхөөсөө дор байна. Энэхүү мэдээллийн сантай ажилладаг манай програмын үр дагавар болох мэдээллийн сангийн доройтлыг арилгана уу.
Тэнд юу болж байгааг ойлгохын тулд хэрэв та өмнөх тайланд оролцоогүй бол одоо жаахан онол авч үзье. Дотоод үйл явцын тухай онол. Яагаад машины тоос сорогч, энэ нь юу хийдэг вэ?
Ойлгох үүднээс товчхондоо. Хэзээ нэгэн цагт бид ширээтэй болно. Хүснэгтэнд бидэнд мөр бий. Эдгээр мөрүүд нь идэвхтэй, амьд, одоо бидэнд хэрэгтэй зүйл байж болно. Зурган дээр тэдгээрийг ногооноор тэмдэглэсэн байна. Мөн аль хэдийн боловсруулсан, шинэчлэгдсэн, шинэ оруулгууд гарч ирсэн үхсэн мөрүүд байдаг. Мөн тэд мэдээллийн санд сонирхолтой байхаа больсон гэж тэмдэглэсэн байна. Гэхдээ Postgres функцийн улмаас тэд хүснэгтэд байна.
Та яагаад машины тоос сорогч хэрэгтэй байна вэ? Хэзээ нэгэн цагт автомат вакуум ирж, мэдээллийн санд нэвтэрч, "Өгөгдлийн санд одоогоор нээлттэй байгаа хамгийн эртний гүйлгээний ID-г надад өгөөч" гэж асууна. Өгөгдлийн сан нь энэ ID-г буцаана. Автовакуум нь түүн дээр тулгуурлан хүснэгтийн мөрүүдийг эрэмбэлдэг. Хэрэв тэр зарим мөрийг илүү хуучин гүйлгээгээр өөрчилсөн гэж үзвэл тэр тэдгээрийг шинэ өгөгдөл бичих замаар ирээдүйд дахин ашиглах мөр болгон тэмдэглэх эрхтэй. Энэ бол суурь процесс юм.
Энэ үед бид мэдээллийн сантай үргэлжлүүлэн ажиллаж, хүснэгтэд зарим өөрчлөлтийг үргэлжлүүлэн хийж байна. Дахин ашиглах боломжтой эдгээр мөрөнд бид шинэ өгөгдөл бичдэг. Тиймээс бид мөчлөгийг олж авдаг, өөрөөр хэлбэл тэнд үргэлж үхсэн хуучин мөрүүд гарч ирдэг бөгөөд үүний оронд бидэнд хэрэгтэй шинэ мөрүүдийг бичдэг. Энэ нь PostgreSQL-д ажиллах хэвийн төлөв юм.
Ослын үеэр юу болсон бэ? Энэ үйл явц тэнд хэрхэн өрнөсөн бэ?
Бидэнд ямар нэг нөхцөлд тэмдэг байсан, зарим нь амьд, зарим нь үхсэн шугамтай байсан. Машины тоос сорогч ирлээ. Тэр мэдээллийн сангаас манай хамгийн эртний гүйлгээ гэж юу вэ, түүний ID гэж юу болохыг асуув. Би энэ ID-г хүлээн авсан бөгөөд энэ нь олон цагийн өмнө, магадгүй арван минутын өмнө байж болох юм. Энэ нь таны мэдээллийн санд хэр их ачаалал өгөхөөс хамаарна. Тэгээд тэр дахин ашигласан гэж тэмдэглэж болох мөрүүдийг хайж явсан. Манай хүснэгтээс би ийм мөр олдсонгүй.
Гэхдээ энэ үед бид хүснэгттэй үргэлжлүүлэн ажиллаж байна. Бид үүнд ямар нэгэн зүйл хийж, шинэчилж, өгөгдлийг өөрчилдөг. Энэ үед мэдээллийн сан юу хийх ёстой вэ? Түүнд одоо байгаа хүснэгтийн төгсгөлд шинэ мөр нэмэхээс өөр сонголт байхгүй. Тиймээс бидний ширээний хэмжээ хавдаж эхэлдэг.
Бодит байдал дээр ажиллахын тулд ногоон шугам хэрэгтэй. Гэхдээ ийм асуудлын үед бүх хүснэгтэд ногоон шугамын хувь маш бага байгаа нь харагдаж байна.
Бид асуулга гүйцэтгэх үед мэдээллийн сан нь хүссэн мөрийг олохын тулд улаан, ногоон гэсэн бүх мөрийг дамжих ёстой. Хүснэгтийг хэрэгцээгүй өгөгдөлөөр дүүргэх үр нөлөөг "блоат" гэж нэрлэдэг бөгөөд энэ нь бидний дискний зайг бас идэж байна. Санаж байна уу, 2 МБ байсан, 300 МБ болсон уу? Одоо мегабайтыг гигабайт болгон сольсноор та бүх дискний нөөцөө хурдан алдах болно.
Бидний хувьд ямар үр дагавар гарч болох вэ?
- Миний жишээн дээр хүснэгт, индекс 150 дахин өссөн. Манай үйлчлүүлэгчдийн зарим нь зүгээр л дискний зай дуусч эхлэхэд үхлийн аюултай тохиолдол гарч байсан.
- Хүснэгтүүдийн хэмжээ өөрөө хэзээ ч буурахгүй. Автовакуум нь зарим тохиолдолд зөвхөн үхсэн шугам байгаа тохиолдолд ширээний сүүлийг таслах боломжтой. Гэхдээ байнгын эргэлт байдаг тул нэг ногоон шугам эцэст нь хөлдөж, шинэчлэгдэхгүй байж болох бөгөөд бусад нь хавтангийн эхэнд хаа нэгтээ бичигдэх болно. Гэхдээ энэ нь таны ширээ өөрөө багасах магадлал багатай үйл явдал тул та үүнд найдаж болохгүй.
- Өгөгдлийн сан нь ашиггүй мөрүүдийг бүхэлд нь эрэмбэлэх хэрэгтэй. Мөн бид дискний нөөцийг дэмий үрж, процессорын нөөц, цахилгааныг үрдэг.
- Энэ нь бидний хэрэглээнд шууд нөлөөлдөг, учир нь хэрэв бид хүсэлтэнд 10 миллисекунд зарцуулсан бол кодонд 10 миллисекунд зарцуулсан бол сүйрлийн үед бид хүсэлтэд нэг секунд, код дээр 10 миллисекунд зарцуулж эхэлсэн. хэрэглээний гүйцэтгэлийн хэмжээ буурсан. Тэгээд ослыг шийдсэний дараа бид хүсэлтэд 20 миллисекунд, кодонд 10 миллисекунд зарцуулж эхэлсэн. Энэ нь бид бүтээмжээрээ нэгээс хагас дахин буурсан гэсэн үг. Энэ бүхэн бидний буруугаас болж царцсан нэг гүйлгээний улмаас болсон.
- "Бид бүх зүйлийг яаж буцааж авах вэ?" Гэсэн асуулт бидний хувьд бүх зүйл хэвийн байгаа бөгөөд ослын өмнөх шиг хүсэлтүүд хурдан ирдэг.
Үүний тулд тодорхой ажлын мөчлөгийг хийдэг.
Эхлээд бид хавдсан асуудалтай хүснэгтүүдийг олох хэрэгтэй. Зарим хүснэгтэд бичлэг илүү идэвхтэй, заримд нь бага идэвхтэй байгааг бид ойлгож байна. Үүний тулд бид өргөтгөлийг ашигладаг . Энэ өргөтгөлийг суулгаснаар та нэлээд томорсон хүснэгтүүдийг олоход туслах асуулга бичих боломжтой.
Эдгээр хүснэгтүүдийг олсны дараа тэдгээрийг шахах хэрэгтэй. Үүнд зориулсан хэрэгслүүд аль хэдийн бий. Манай компанид бид гурван хэрэгслийг ашигладаг. Эхнийх нь суурилуулсан VACUUM FULL юм. Тэр харгис хэрцгий, хатуу ширүүн, өршөөлгүй боловч заримдаа маш их хэрэгтэй байдаг. и - Эдгээр нь хүснэгтийг шахах гуравдагч талын хэрэгслүүд юм. Мөн тэд мэдээллийн санд илүү болгоомжтой ханддаг.
Танд илүү тохиромжтой зүйлээс хамааран тэдгээрийг ашигладаг. Гэхдээ би хамгийн сүүлд энэ тухай танд хэлэх болно. Хамгийн гол нь гурван хэрэгсэл байдаг. Сонгох олон зүйл бий.
Бид бүх зүйлийг засч, бүх зүйл хэвийн байгаа эсэхийг шалгасны дараа ирээдүйд ийм нөхцөл байдлаас хэрхэн сэргийлэх талаар мэдэх ёстой.
- Үүнийг маш амархан урьдчилан сэргийлэх боломжтой. Та Мастер сервер дээрх сешнүүдийн үргэлжлэх хугацааг хянах хэрэгтэй. Гүйлгээний төлөвт идэвхгүй байгаа, ялангуяа аюултай сессүүд. Дөнгөж гүйлгээ нээгээд, юм хийчихээд яваад өгсөн, эсвэл зүгээр л өлгөчихсөн, кодонд төөрсөн хүмүүс.
- Хөгжүүлэгчийн хувьд эдгээр нөхцөл байдал үүссэн үед кодыг туршиж үзэх нь чухал юм. Үүнийг хийхэд хэцүү биш. Энэ нь ашигтай шалгалт байх болно. Та урт хугацааны гүйлгээтэй холбоотой олон тооны "хүүхдийн" асуудлаас зайлсхийх болно.
Эдгээр графикууд дээр би энэ тохиолдолд VACUUM FULL тэмдэгээр дамжсаны дараа мэдээллийн сангийн тэмдэг, зан төлөв хэрхэн өөрчлөгдсөнийг харуулахыг хүссэн. Энэ бол миний хувьд үйлдвэрлэл биш.
Хүснэгтийн хэмжээ нэн даруй хоёр мегабайтын хэвийн үйл ажиллагааны төлөвтөө буцаж ирэв. Энэ нь серверийн хариу өгөх дундаж хугацаанд төдийлөн нөлөөлөөгүй.
Гэхдээ бид дансны үлдэгдлийг шинэчилсэн туршилтын тэмдгийн хувьд тэмдэг дээрх өгөгдлийг шинэчлэх хүсэлтийн хариу өгөх дундаж хугацаа яаралтай тусламжийн өмнөх түвшинд хүртэл буурсан болохыг бид харж байна. Энэ хүсэлтийг биелүүлэхийн тулд процессорын зарцуулсан нөөц бас сүйрлийн өмнөх түвшинд хүртэл буурсан. Баруун доод графикаас харахад ширээг шахахаас өмнө овоо байсан үхсэн зураасыг тойруулалгүйгээр бид яг хэрэгтэй шугамаа шууд олдог. Хүсэлтийн дундаж хугацаа ойролцоогоор ижил түвшинд хэвээр байна. Гэхдээ энд миний техник хангамжид алдаа гарсан байна.
Энд эхний түүх дуусна. Энэ нь хамгийн түгээмэл юм. Үйлчлүүлэгчийн туршлага, програмистууд хэр зэрэг чадвартай байхаас үл хамааран энэ нь хүн бүрт тохиолддог. Эрт орой хэзээ нэгэн цагт ийм зүйл тохиолддог.
Хоёр дахь түүх, бид ачааллыг хуваарилж, серверийн нөөцийг оновчтой болгодог
- Бид аль хэдийн том болоод нухацтай залуус болсон. Бидэнд хуулбар байгаа гэдгийг ойлгож байгаа бөгөөд ачааллыг тэнцвэржүүлэх нь бидэнд сайн байх болно: Мастер руу бичиж, хуулбараас уншаарай. Бид зарим тайлан эсвэл ETL бэлтгэхийг хүсэх үед ихэвчлэн ийм нөхцөл байдал үүсдэг. Мөн бизнес эрхлэгчид үүнд маш их баяртай байна. Тэрээр маш олон нарийн төвөгтэй аналитик бүхий олон төрлийн тайлангуудыг үнэхээр хүсч байна.
- Нарийн төвөгтэй аналитикийг миллисекундээр тооцоолох боломжгүй тул тайлан гаргахад олон цаг зарцуулдаг. Бид зоригтой залуус шиг код бичдэг. Оруулах програм дээр бид Мастер дээр бичлэг хийж, хуулбар дээр тайлангуудыг гүйцэтгэдэг.
- Ачааллыг хуваарилах.
- Бүх зүйл төгс ажилладаг. Бид мундаг.
Мөн энэ байдал ямар харагдаж байна вэ? Ялангуяа эдгээр графикууд дээр би мөн хуулбараас гүйлгээний үргэлжлэх хугацааг нэмсэн. Бусад бүх графикууд нь зөвхөн Мастер серверт хамаарна.
Энэ үед миний тайлангийн самбар томорсон. Тэднээс илүү олон байдаг. Серверийн хариу өгөх дундаж хугацаа тогтвортой байгааг бид харж байна. Хуулбар дээр бид 2 цагийн турш үргэлжилсэн урт хугацааны гүйлгээтэй байгааг харж байна. Үхсэн шугамыг боловсруулдаг автовакуумын чимээгүй ажиллагааг бид харж байна. Мөн бидний хувьд бүх зүйл сайхан байна.
Тодруулбал, туршсан таблетыг ашиглан бид дансны үлдэгдлийг тэнд үргэлжлүүлэн шинэчилдэг. Мөн бид хүсэлтэд тогтвортой хариу өгөх хугацаа, нөөцийн тогтвортой хэрэглээтэй байдаг. Бидэнд бүх зүйл сайхан байна.
Хуулбарлахтай зөрчилдсөний улмаас эдгээр тайлангууд буцаж эхлэх хүртэл бүх зүйл хэвийн байна. Мөн тэд тодорхой давтамжтайгаар хариу бууддаг.
Бид интернетэд орж, яагаад ийм зүйл болж байгааг уншиж эхэлдэг. Тэгээд бид шийдлийг олдог.
Эхний шийдэл бол хуулбарлах хоцролтыг нэмэгдүүлэх явдал юм. Манай тайлан 3 цагийн турш явагддаг гэдгийг бид мэднэ. Бид хуулбарлах саатлыг 3 цаг болгож тохируулсан. Бид бүх зүйлийг эхлүүлж байгаа ч заримдаа тайлангуудыг цуцлахтай холбоотой асуудал гарсаар байна.
Бид бүх зүйл төгс байгаасай гэж хүсдэг. Бид цаашаа авирна. Мөн бид интернетээс гайхалтай тохиргоог олсон - hot_standby_feedback. Үүнийг асаацгаая. Hot_standby_feedback нь Мастер дээрх автовакуумыг саатуулах боломжийг бидэнд олгодог. Тиймээс бид хуулбарлах зөрчлөөс бүрэн ангижрах болно. Мөн тайлангуудын хувьд бидний хувьд бүх зүйл сайн ажилладаг.
Энэ үед Мастер серверт юу болж байна вэ? Мөн бид Мастер сервертэй холбоотой асуудалд орлоо. Одоо би эдгээр хоёр тохиргоог идэвхжүүлсэн үед бид графикуудыг харж байна. Манай хуулбар дээрх сесс ямар нэгэн байдлаар Мастер серверийн нөхцөл байдалд нөлөөлж эхэлснийг бид харж байна. Үхсэн шугамыг арилгадаг автовакуумыг түр зогсоосон учраас тэр үнэхээр нөлөө үзүүлдэг. Манай ширээний хэмжээ дахиад л огцом өссөн. Өгөгдлийн сан дахь асуулгын гүйцэтгэлийн дундаж хугацаа мөн огцом өссөн. Автовакуумууд бага зэрэг чангарав.
Тодруулбал, бидний тавагнаас түүн дээрх мэдээллийн шинэчлэлтүүд мөн тэнгэрт үсэрсэн болохыг бид харж байна. CPU-ийн хэрэглээ мөн адил их хэмжээгээр нэмэгдсэн. Бид дахин олон тооны үхсэн, хэрэггүй шугамаар явж байна. Мөн энэ тэмдгийн хариу өгөх хугацаа, гүйлгээний тоо буурсан байна.
Өмнө нь миний юу ярьж байсныг бид мэдэхгүй бол ямар харагдах бол?
- Бид асуудал хайж эхэлдэг. Хэрэв бид эхний хэсэгт асуудалтай тулгарсан бол энэ нь удаан хугацааны гүйлгээтэй холбоотой байж магадгүй гэдгийг мэдэж, Мастер руу очно. Бидэнд Мастертай холбоотой асуудал байна. Түүнийг хиам. Энэ нь халдаг, түүний ачааллын дундаж нь зуу орчим байна.
- Хүсэлтүүд удаашралтай байгаа ч бид тэнд удаан үргэлжилсэн гүйлгээг олж харахгүй байна. Тэгээд бид юу болоод байгааг ойлгохгүй байна. Бид хаашаа хайхаа ойлгохгүй байна.
- Бид серверийн тоног төхөөрөмжийг шалгадаг. Магадгүй бидний дайралт сүйрсэн байх. Магадгүй бидний санах ой шатсан байх. Тийм ээ, юу ч тохиолдож болно. Гэхдээ үгүй, серверүүд шинэ, бүх зүйл хэвийн ажиллаж байна.
- Бүгд л гүйж байна: администраторууд, хөгжүүлэгчид, захирал. Юу ч тус болохгүй.
- Тэгээд хэзээ нэгэн цагт бүх зүйл гэнэт өөрийгөө засаж эхэлдэг.
Энэ үед манай хуулбар дээрх хүсэлтийг боловсруулж, орхисон. Бид тайланг хүлээн авсан. Бизнес аз жаргалтай хэвээр байна. Таны харж байгаагаар бидний тэмдэг дахин томорч, буурахгүй байна. Сеанс бүхий график дээр би энэ урт гүйлгээний нэг хэсгийг хуулбараас үлдээсэн бөгөөд ингэснээр нөхцөл байдал тогтворжих хүртэл хэр хугацаа шаардагдахыг тооцоолох боломжтой болно.
Хурал дууслаа. Хэсэг хугацааны дараа л сервер илүү их эсвэл бага дарааллаар ирдэг. Мастер сервер дээрх хүсэлтэд хариу өгөх дундаж хугацаа хэвийн байдалдаа орно. Учир нь эцэст нь автовакуум нь эдгээр үхсэн шугамыг цэвэрлэж, тэмдэглэх боломжтой байдаг. Тэгээд тэр ажлаа хийж эхлэв. Тэр үүнийг хэр хурдан хийдэг бол бид маш хурдан эмх цэгцтэй болно.
Бид дансны үлдэгдлийг шинэчилдэг туршилтын таблетын дагуу бид яг ижил дүр зургийг харж байна. Дансны шинэчлэлтийн дундаж хугацаа мөн аажмаар хэвийн болж байна. Процессорын зарцуулсан нөөц бас багасдаг. Мөн секундэд хийх гүйлгээний тоо хэвийн байдалдаа орно. Гэхдээ бид дахин хэвийн байдалдаа орсон, ослын өмнөх шигээ биш.
Ямар ч тохиолдолд бид гүйцэтгэлийн бууралтыг эхний тохиолдол шиг нэг хагасаас хоёр дахин, заримдаа түүнээс ч их хэмжээгээр авдаг.
Бид бүгдийг зөв хийсэн бололтой. Ачааллыг хуваарилах. Тоног төхөөрөмж сул зогсдоггүй. Бид хүсэлтийг оюун ухаанаараа хуваасан ч бүх зүйл муу болсон.
- Hot_standby_feedback-г идэвхжүүлэхгүй байна уу? Тиймээ, онцгой хүчтэй шалтгаангүйгээр үүнийг асаахыг зөвлөдөггүй. Учир нь энэ эргэлт нь Мастер серверт шууд нөлөөлж, тэндхийн автовакуумын ажиллагааг түр зогсоодог. Зарим хуулбар дээр үүнийг идэвхжүүлж, мартсанаар та Мастерыг устгаж, програмтай холбоотой томоохон асуудал үүсгэж болно.
- Хүлээлтийн_дамалтын_хамгийн их саатлыг нэмэгдүүлэх үү? Тийм ээ, тайлангийн хувьд энэ нь үнэн юм. Хэрэв танд гурван цагийн тайлан байгаа бөгөөд хуулбарлах зөрчлөөс болж гацахыг хүсэхгүй байгаа бол хойшлуулах хугацааг нэмэгдүүлээрэй. Урт хугацааны тайланд яг одоо мэдээллийн санд ирсэн өгөгдлийг хэзээ ч шаарддаггүй. Хэрэв танд гурван цагийн турш байгаа бол та үүнийг хуучин өгөгдлийн хугацаанд ажиллуулж байна. Мөн таны хувьд гурван цаг саатсан уу, зургаан цагийн хоцролт байгаа эсэх нь ямар ч ялгаагүй, гэхдээ та тайланг тогтмол хүлээн авч, унахад ямар ч асуудал гарахгүй.
- Мэдээжийн хэрэг, та хуулбар дээр удаан хугацааны сессүүдийг хянах хэрэгтэй, ялангуяа хэрэв та хуулбар дээр hot_standby_feedback-г идэвхжүүлэхээр шийдсэн бол. Учир нь юу ч тохиолдож болно. Бид энэ хуулбарыг хөгжүүлэгчид өгсөн бөгөөд ингэснээр тэр асуултуудыг шалгах боломжтой болно. Тэр галзуу хүсэлт бичсэн. Тэр үүнийг хөөргөж, цай уухаар явсан бөгөөд бид байгуулагдсан Мастерыг авав. Эсвэл бид энд буруу програм оруулсан байж магадгүй. Нөхцөл байдал нь янз бүр байна. Хуулбар дээрх хичээлүүдийг Мастер дээрх шиг анхааралтай хянах ёстой.
- Хэрэв танд хуулбар дээр хурдан бөгөөд урт асуулт байгаа бол энэ тохиолдолд ачааллыг хуваарилахын тулд тэдгээрийг хуваах нь дээр. Энэ бол streaming_delay-ийн холбоос юм. Хурдан хүмүүсийн хувьд хуулбарлах хугацаа багатай нэг хуулбартай байх хэрэгтэй. Урт хугацааны тайлагнах хүсэлтийн хувьд 6 цаг эсвэл нэг өдрөөр хоцорч болох хуулбартай байх хэрэгтэй. Энэ бол туйлын хэвийн нөхцөл байдал юм.
Бид үр дагаврыг дараах байдлаар арилгадаг.
- Бид хавдсан ширээ олдог.
- Мөн бид үүнийг өөртөө тохирсон хамгийн тохиромжтой хэрэгслээр шахдаг.
Хоёр дахь түүх энд дуусна. Гурав дахь түүх рүүгээ орцгооё.
Мөн шилжилт хөдөлгөөн хийдэг бидний хувьд нэлээд түгээмэл байдаг.
- Аливаа програм хангамжийн бүтээгдэхүүн өсөж байна. Үүнд тавигдах шаардлага өөрчлөгдөж байна. Ямар ч байсан хөгжмөөр байна. Мөн бид хүснэгтэд байгаа өгөгдлийг шинэчлэх, тухайлбал бидний хөгжлийн нэг хэсэг болгон нэвтрүүлж буй шинэ функцийг шилжүүлэхийн тулд шинэчлэлт хийх шаардлагатай болдог.
- Хуучин өгөгдлийн формат хангалтгүй байна. Одоо бид эдгээр дансаар гүйлгээ хийдэг хоёр дахь хүснэгтэд хандлаа гэж бодъё. Тэд рубльтэй байсан гэж бодъё, бид нарийвчлалыг нэмэгдүүлж, копейкээр хийхээр шийдсэн. Үүний тулд бид шинэчлэлт хийх хэрэгтэй: гүйлгээний дүн бүхий талбарыг зуугаар үржүүлнэ.
- Өнөөгийн ертөнцөд бид мэдээллийн баазын хувилбарыг хянах автомат хэрэгслийг ашигладаг. гэж хэлье . Бид шилжилт хөдөлгөөнөө тэнд бүртгэдэг. Бид үүнийг туршилтын бааз дээрээ туршиж үздэг. Бүх зүйл сайхан байна. Шинэчлэлт явагдаж байна. Энэ нь ажлыг хэсэг хугацаанд блоклодог ч бид шинэчилсэн мэдээллийг авдаг. Мөн бид үүн дээр шинэ функцийг эхлүүлэх боломжтой. Бүгдийг нь шалгаж, шалгасан. Бүх зүйл батлагдсан.
- Төлөвлөсөн ажлаа хийж, шилжилт хөдөлгөөн хийсэн.
Таны өмнө танилцуулсан шинэчлэлт бүхий шилжилтийг энд харуулав. Эдгээр нь миний дансны гүйлгээ учраас хавтан нь 15 GB байсан. Бид мөр бүрийг шинэчилдэг тул мөр бүрийг дахин бичсэн тул шинэчлэлтийн хамт хүснэгтийн хэмжээг хоёр дахин нэмэгдүүлсэн.
Шилжилтийн явцад бид энэ хавтангаар юу ч хийж чадсангүй, учир нь түүнд ирсэн бүх хүсэлтүүд дараалалд орж, шинэчлэлт дуусах хүртэл хүлээсэн. Гэхдээ энд би босоо тэнхлэгт байгаа тоонуудад анхаарлаа хандуулахыг хүсч байна. Өөрөөр хэлбэл, шилжихээс өмнөх хүсэлтийн дундаж хугацаа 5 миллисекунд, процессор ачаалагдахаас өмнө дискний санах ойг унших блокийн үйлдлийн тоо 7,5-аас бага байна.
Бид шилжилт хөдөлгөөн хийж, дахин асуудал гарлаа.
Шилжилт амжилттай болсон боловч:
- Хуучин функцийг дуусгахад удаан хугацаа шаардагдана.
- Ширээ дахин томорчээ.
- Сервер дээрх ачаалал өмнөхөөсөө дахин нэмэгдэв.
- Мэдээжийн хэрэг, бид сайн ажиллаж байсан функцтэй холбоотой хэвээр байгаа бөгөөд бид үүнийг бага зэрэг сайжруулсан.
Энэ бол дахин хавдаж, бидний амьдралыг дахин сүйтгэж байна.
Өмнөх хоёр тохиолдлын нэгэн адил хүснэгт нь өмнөх хэмжээс рүүгээ буцаж очихгүй гэдгийг би энд харуулж байна. Серверийн дундаж ачаалал хангалттай байх шиг байна.
Хэрэв бид данстай хүснэгт рүү эргэвэл энэ хүснэгтэд хүсэлт гаргах дундаж хугацаа хоёр дахин нэмэгдсэнийг харах болно. Процессорын ачаалал болон санах ойд эрэмбэлэгдсэн мөрүүдийн тоо 7,5-аас дээш гарсан боловч бага байв. Процессорын хувьд энэ нь 2 дахин, блокийн үйлдлийн хувьд 1,5 дахин өссөн, өөрөөр хэлбэл серверийн гүйцэтгэл муудсан. Үүний үр дүнд - бидний хэрэглээний гүйцэтгэл муудаж байна. Үүний зэрэгцээ дуудлагын тоо ойролцоогоор ижил түвшинд хэвээр байна.
Энд гол зүйл бол ийм шилжилт хөдөлгөөнийг хэрхэн зөв хийхийг ойлгох явдал юм. Мөн тэдгээрийг хийх хэрэгтэй. Бид эдгээр шилжилт хөдөлгөөнийг нэлээд тогтмол хийдэг.
- Ийм их нүүдэл аяндаа болдоггүй. Тэд үргэлж хяналтанд байх ёстой.
- Мэдлэгтэй хүний хяналт шаардлагатай. Хэрэв та өөрийн багт DBA-тай бол DBA-д үүнийг хийхийг зөвшөөр. Түүний ажил. Хэрэв тийм биш бол мэдээллийн сантай хэрхэн ажиллахыг мэддэг хамгийн туршлагатай хүн үүнийг хий.
- Өгөгдлийн сангийн шинэ схемийг бид нэг баганыг шинэчилсэн ч гэсэн бид үргэлж үе шаттайгаар, өөрөөр хэлбэл програмын шинэ хувилбарыг гаргахаас өмнө урьдчилан бэлтгэдэг.
- Бид шинэчлэгдсэн өгөгдлийг бүртгэх шинэ талбарууд нэмэгдсэн.
- Бид өгөгдлийг хуучин талбараас шинэ талбар руу жижиг хэсгүүдэд шилжүүлдэг. Бид яагаад үүнийг хийж байгаа юм бэ? Нэгдүгээрт, бид энэ үйл явцын үйл явцыг үргэлж хянадаг. Бид аль хэдийн өчнөөн багц шилжүүлээд, маш олон үлдсэнийг бид мэднэ.
- Хоёрдахь эерэг үр нөлөө нь ийм багц бүрийн хооронд бид гүйлгээг хааж, шинийг нээдэг бөгөөд энэ нь автовакуумыг хавтангийн дагуу ажиллах, дахин ашиглах үхсэн шугамыг тэмдэглэх боломжийг олгодог.
- Аппликешн ажиллаж байх үед гарч ирэх мөрүүдийн хувьд (бид хуучин програм ажиллаж байгаа хэвээр байгаа) бид шинэ талбарт шинэ утгыг бичих триггер нэмнэ. Манай тохиолдолд энэ нь хуучин утгын нэг зуугаар үржих явдал юм.
- Хэрэв бид бүрэн зөрүүд бөгөөд ижил талбарыг хүсч байвал бүх шилжүүлэлт дууссаны дараа програмын шинэ хувилбарыг гаргахаас өмнө талбаруудын нэрийг өөрчлөхөд хангалттай. Хуучин хэсгүүдэд зарим нэг зохион бүтээсэн нэр өгч, шинэ талбаруудыг хуучин болгон өөрчилдөг.
- Үүний дараа л бид програмын шинэ хувилбарыг эхлүүлнэ.
Үүний зэрэгцээ бид хавдаж, гүйцэтгэлийн хувьд зовохгүй байх болно.
Гурав дахь түүх энд төгсдөг.
Одоо миний эхний өгүүлэлд дурдсан хэрэгслүүдийн талаар бага зэрэг дэлгэрэнгүй ярья.
Bloat хайхаасаа өмнө өргөтгөлийг суулгах ёстой .
Та асуулт гаргах шаардлагагүй тул бид эдгээр асуултуудыг ажилдаа аль хэдийн бичсэн болно. Та тэдгээрийг ашиглаж болно. Энд хоёр хүсэлт байна.
- Эхнийх нь ажиллахад нэлээд удаан хугацаа шаардагддаг боловч энэ нь хүснэгтээс яг тодорхой хэмжээгээр дүүрэх утгыг харуулах болно.
- Хоёрдахь нь илүү хурдан ажилладаг бөгөөд хүснэгтийн дагуу хавдсан эсвэл байхгүй эсэхийг хурдан үнэлэх шаардлагатай үед маш үр дүнтэй байдаг. Postgres хүснэгтэд хавдах нь үргэлж байдаг гэдгийг та бас ойлгох хэрэгтэй. Энэ нь түүний MVCC загварын онцлог юм.
- Ихэнх тохиолдолд ширээн дээр 20% хавдах нь хэвийн үзэгдэл юм. Энэ нь та санаа зовох хэрэггүй бөгөөд энэ хүснэгтийг шахах хэрэгтэй.
Бид ашиггүй мэдээллээр хавдсан хүснэгтүүдийг хэрхэн тодорхойлохыг олж мэдсэн.
Одоо хавдахыг хэрхэн засах талаар:
- Хэрэв бид жижиг таблеттай, сайн дисктэй, өөрөөр хэлбэл гигабайт хүртэлх таблеттай бол VACUUM FULL ашиглах бүрэн боломжтой. Тэр чамаас онцгой түгжээг хэдхэн секундын турш ширээн дээр авах болно, гэхдээ тэр бүгдийг хурдан бөгөөд хатуугаар хийх болно. VACUUM FULL юу хийдэг вэ? Энэ нь ширээн дээр онцгой түгжээ авч, хуучин хүснэгтүүдээс шууд мөрүүдийг шинэ хүснэгт рүү дахин бичдэг. Тэгээд эцэст нь тэр тэднийг орлоно. Энэ нь хуучин файлуудыг устгаж, хуучин файлуудыг шинэ файлаар солино. Гэхдээ ажлынхаа туршид ширээн дээр онцгой түгжээ авдаг. Энэ нь та энэ хүснэгттэй юу ч хийх боломжгүй гэсэн үг юм: түүнд бичих, унших, өөрчлөх боломжгүй. Мөн VACUUM FULL нь өгөгдөл бичихэд нэмэлт дискний зай шаарддаг.
- Дараагийн хэрэгсэл . Зарчмын хувьд энэ нь VACUUM FULL-тэй маш төстэй, учир нь энэ нь хуучин файлаас өгөгдлийг шинээр бичиж, хүснэгтэд орлуулдаг. Гэхдээ үүнтэй зэрэгцэн энэ нь ажлынхаа эхэнд ширээн дээр онцгой түгжээ авдаггүй, харин файлуудыг солихын тулд аль хэдийн бэлэн өгөгдөлтэй байх үед л авдаг. Түүний дискний нөөцийн шаардлага нь VACUUM FULL-тэй төстэй. Танд нэмэлт дискний зай хэрэгтэй бөгөөд хэрэв та терабайт хүснэгттэй бол энэ нь заримдаа чухал байдаг. Мөн энэ нь I/O-тэй идэвхтэй ажилладаг учраас процессор их шаарддаг.
- Гурав дахь хэрэгсэл нь . Энэ нь арай өөр зарчмаар ажилладаг тул нөөцөд илүү болгоомжтой ханддаг. pgcompacttable-ийн гол санаа нь хүснэгтийн шинэчлэлтүүдийг ашиглан бүх мөрүүдийг хүснэгтийн эхэнд шилжүүлэх явдал юм. Тэгээд дараа нь энэ ширээн дээр вакуум ажиллуулдаг, учир нь бид эхэнд нь амьд эгнээ, төгсгөлд нь үхсэн эгнээтэй гэдгийг мэддэг. Мөн вакуум нь өөрөө энэ сүүлийг тасалдаг, өөрөөр хэлбэл дискний нэмэлт зай шаарддаггүй. Үүний зэрэгцээ, энэ нь нөөцийн хувьд шахагдаж болно.
Бүх зүйл багаж хэрэгсэлтэй.
Хэрэв танд энэ сэдвийг илүү гүнзгийрүүлэхийн тулд сонирхолтой гэж үзвэл зарим хэрэгтэй холбоосууд энд байна:
- - Энэ бол миний хамтран зүтгэгчийн илтгэл. Энэ нь Постгресийн орон зай нь ажил, амьдралынхаа туршид хаашаа явдаг тухай ерөнхий юм. Өгөгдлийн сангийн администраторуудад bloat-ийн талаар маш том бөгөөд нарийвчилсан техникийн хэсэг байдаг.
- – Энэ бол мэдээллийн сангийн төлөв байдлыг шалгахад хэрэгтэй олон скриптүүдийг хадгалдаг манай репозиторын холбоос юм. Тэнд та bloat хайх скриптүүдийг олох боломжтой.
- и тэмдгүүдийг багасгахад туслах хэрэгслүүдийн холбоосууд.
- - Энэ бол миний хамтрагчийн бичсэн нийтлэл юм. Тэнд тэрээр администраторуудтай ойролцоо түвшинд bloat-ийг нэлээд нухацтай, техникийн хувьд нарийвчлан шинжилдэг.
Би хөгжүүлэгчдэд зориулж аймшгийн түүхийг харуулахыг илүү хичээсэн, учир нь тэд бидний мэдээллийн сангийн шууд үйлчлүүлэгчид бөгөөд юу, ямар үйлдэлд хүргэж байгааг ойлгох ёстой. Би амжилтанд хүрсэн гэж найдаж байна. Анхаарал тавьсанд баярлалаа!
Асуултууд
Мэдээлэл өгсөнд баярлалаа! Та асуудлыг хэрхэн тодорхойлох талаар ярьсан. Тэдэнд хэрхэн анхааруулах вэ? Өөрөөр хэлбэл, зарим гадны үйлчилгээнд хандсан учраас хүсэлтүүд зогсох нөхцөл байдал надад тохиолдсон. Эдгээр нь зүгээр л хэдэн зэрлэг нэгдлүүд байсан. Өчүүхэн, хор хөнөөлгүй хүсэлтүүд нэг өдрийн турш эргэлдэж, дараа нь ямар нэгэн утгагүй зүйл хийж эхлэв. Энэ нь таны тодорхойлсонтой маш төстэй юм. Үүнийг хэрхэн хянах вэ? Ямар хүсэлт гацаж байгааг байнга харж суугаад байх уу? Үүнээс хэрхэн урьдчилан сэргийлэх вэ?
Энэ тохиолдолд энэ нь DBA-д хийх албагүй танай компанийн администраторуудад зориулсан даалгавар юм.
Би админ хүн.
PostgreSQL нь унжсан асуултуудыг харуулдаг pg_stat_activity гэсэн харагдацтай. Тэгээд тэнд хэр удаан унжсаныг харж болно.
Би 5 минут тутамд орж ирээд харах ёстой юу?
Cron-г тохируулаад шалгана уу. Хэрэв танд урт хугацааны хүсэлт байгаа бол захидал бичээрэй, тэгээд л болоо. Өөрөөр хэлбэл та нүдээрээ харах шаардлагагүй, үүнийг автоматжуулж болно. Та захидал хүлээн авах болно, та түүнд хариу үйлдэл үзүүлэх болно. Эсвэл та автоматаар буудаж болно.
Ийм зүйл тохиолдох тодорхой шалтгаан бий юу?
Би заримыг нь жагсаасан. Бусад илүү төвөгтэй жишээнүүд. Мөн удаан хугацааны туршид харилцан яриа байж болно.
Мэдээлэл өгсөнд баярлалаа! Би pg_repack хэрэгслийн талаар тодруулахыг хүссэн. Хэрэв тэр онцгой түгжээ хийхгүй бол ...
Тэр онцгой цоож хийдэг.
... Дараа нь би өгөгдөл алдаж болзошгүй. Энэ хугацаанд миний өргөдөл юу ч бичихгүй байх ёстой юу?
Үгүй ээ, энэ нь хүснэгттэй жигд ажилладаг, өөрөөр хэлбэл pg_repack эхлээд байгаа бүх шууд шугамыг шилжүүлдэг. Мэдээжийн хэрэг, хүснэгтэд ямар нэгэн зүйл орох нь тэнд тохиолддог. Тэр энэ гэзгээ зүгээр л шидэж байна.
Өөрөөр хэлбэл, тэр эцсийн эцэст үүнийг хийдэг үү?
Эцэст нь тэрээр эдгээр файлуудыг солихын тулд онцгой түгжээ авдаг.
Энэ нь VACUUM FULL-ээс хурдан байх болов уу?
VACUUM FULL, эхэлмэгц тэр даруй онцгой түгжээг авав. Тэгээд тэр бүх зүйлийг хийх хүртэл тэр түүнийг явуулахгүй. Мөн pg_repack нь зөвхөн файл солих үед онцгой түгжээ авдаг. Энэ мөчид та тэнд бичихгүй, гэхдээ өгөгдөл алга болохгүй, бүх зүйл сайхан болно.
Сайн уу? Та машины тоос сорогчийн ажиллагааны талаар ярьсан. Улаан, шар, ногоон бичлэгийн нүднүүдтэй график байсан. Өөрөөр хэлбэл, шар өнгөтэй - тэр тэдгээрийг устгасан гэж тэмдэглэв. Үүний үр дүнд тэдэнд шинэ зүйл бичиж болох уу?
Тиймээ. Postgres мөрүүдийг устгадаггүй. Түүнд ийм онцлог бий. Хэрэв бид мөрийг шинэчилсэн бол хуучин мөрийг устгасан гэж тэмдэглэсэн. Энэ мөрийг өөрчилсөн гүйлгээний ID тэнд гарч ирэх ба бид шинэ мөр бичнэ. Мөн бидэнд тэдгээрийг унших боломжтой сессүүд бий. Хэзээ нэгэн цагт тэд нэлээд хөгширдөг. Мөн автовакуум хэрхэн ажилладагийн мөн чанар нь эдгээр шугамаар дамжиж, шаардлагагүй гэж тэмдэглэдэг. Мөн та тэнд өгөгдлийг дарж бичиж болно.
Би ойлгож байна. Гэхдээ энэ асуултын тухай биш юм. Би дуусаагүй. Бидэнд ширээ байна гэж бодъё. Энэ нь хувьсах хэмжээтэй талбаруудтай. Хэрэв би ямар нэг шинэ зүйл оруулахыг оролдвол энэ нь хуучин нүдэнд тохирохгүй байж магадгүй юм.
Үгүй ээ, ямар ч тохиолдолд бүх шугам тэнд шинэчлэгддэг. Postgres нь өгөгдөл хадгалах хоёр загвартай. Энэ нь өгөгдлийн төрлөөс сонгоно. Хүснэгтэнд шууд хадгалагддаг өгөгдөл байдаг ба tos өгөгдөл байдаг. Эдгээр нь их хэмжээний өгөгдөл юм: text, json. Тэд тусдаа ялтсуудад хадгалагддаг. Мөн эдгээр шахмалуудын дагуу хавдахтай ижил түүх тохиолддог, өөрөөр хэлбэл бүх зүйл ижил байдаг. Тэдгээрийг зөвхөн тусад нь жагсаасан болно.
Мэдээлэл өгсөнд баярлалаа! Үргэлжлэх хугацааг хязгаарлахын тулд мэдэгдлийн хугацаа дууссаны асуулга ашиглахыг зөвшөөрөх үү?
Маш хүлээн зөвшөөрөгдөхүйц. Бид үүнийг хаа сайгүй ашигладаг. Мөн бид өөрсдийн үйлчилгээгүй тул алсаас дэмжлэг үзүүлдэг, бидэнд маш олон үйлчлүүлэгчид байдаг. Мөн хүн бүр үүнд бүрэн сэтгэл хангалуун байдаг. Энэ нь бид шалгадаг cron ажлуудтай. Хичээлийн үргэлжлэх хугацааг үйлчлүүлэгчтэй зүгээр л тохиролцдог бөгөөд үүнээс өмнө бид санал нийлэхгүй байна. Нэг минут ч болно, 10 минут ч болно. Энэ нь суурийн ачаалал, түүний зорилгоос хамаарна. Гэхдээ бид бүгд pg_stat_activity ашигладаг.
Мэдээлэл өгсөнд баярлалаа! Би таны тайланг өргөдөлдөө ашиглахыг оролдож байна. Мөн бид хаа сайгүй гүйлгээ эхлүүлж, хаа сайгүй тодорхой дуусгаж байх шиг байна. Хэрэв ямар нэг үл хамаарах зүйл байвал буцаах үйл явц хэвээр байна. Тэгээд би бодож эхлэв. Эцсийн эцэст, гүйлгээ нь тодорхой эхлэхгүй байж магадгүй юм. Энэ нь охинд өгсөн сануулга байх. Хэрэв би зүгээр л бичлэгээ шинэчилбэл гүйлгээ PostgreSQL дээр эхэлж, холболт тасарсан үед л дуусах уу?
Хэрэв та одоо програмын түвшний талаар ярьж байгаа бол энэ нь таны ашиглаж буй драйвер, ашиглаж буй ORM-ээс хамаарна. Тэнд маш олон тохиргоо байдаг. Хэрэв та автоматаар баталгаажуулалтыг идэвхжүүлсэн бол гүйлгээ тэнд эхэлж, шууд хаагдана.
Энэ нь шинэчлэлт хийсний дараа шууд хаагддаг гэсэн үг үү?
Энэ нь тохиргооноос хамаарна. Би нэг тохиргоог нэрлэсэн. Энэ бол автоматаар баталгаажуулах явдал юм. Энэ нь нэлээд түгээмэл байдаг. Хэрэв идэвхжүүлсэн бол гүйлгээ нээгдэж, хаагдсан байна. Хэрэв та "гүйлгээг эхлүүлэх" болон "гүйлгээг дуусгах" гэж тодорхой хэлээгүй ч сесс рүү хүсэлт илгээсэн л бол.
Сайн уу? Мэдээлэл өгсөнд баярлалаа! Бид хавдаж, хавдаж, дараа нь сервер дээрх зай дуусч байгаа мэдээллийн сантай гэж төсөөлөөд үз дээ. Энэ байдлыг засах ямар нэг хэрэгсэл бий юу?
Сервер дээрх зайг зөв хянах шаардлагатай.
Жишээлбэл, DBA цай уухаар явсан, амралтын газар байсан гэх мэт.
Файлын системийг үүсгэх үед өгөгдөл бичигдээгүй тохиолдолд ядаж ямар нэгэн нөөцийн орон зай үүсдэг.
Хэрэв энэ нь тэгээс бүрэн доогуур байвал яах вэ?
Тэнд үүнийг нөөцөлсөн орон зай гэж нэрлэдэг, өөрөөр хэлбэл үүнийг чөлөөлж болох бөгөөд хэр том бүтээгдсэнээс хамааран та чөлөөт зай авах болно. Анхдагч байдлаар би хэд байгааг мэдэхгүй байна. Мөн өөр тохиолдолд, сэргээн босгох мэс засал хийх зайтай байхын тулд дискийг илгээнэ үү. Та шаардлагагүй гэсэн баталгаатай зарим хүснэгтийг устгаж болно.
Өөр хэрэгсэл бий юу?
Үргэлж гараар хийдэг. Зарим өгөгдөл чухал, зарим нь чухал биш байдаг тул тэнд юу хийх нь хамгийн сайн арга нь орон нутгийн хувьд тодорхой болно. Мөн мэдээллийн сан болон түүнтэй ажилладаг програм бүрийн хувьд энэ нь бизнесээс хамаарна. Дандаа орон нутагтаа шийддэг.
Мэдээлэл өгсөнд баярлалаа! Надад хоёр асуулт байна. Эхлээд та гүйлгээ гацсан үед хүснэгтийн хэмжээ болон индексийн хэмжээ хоёулаа өсдөгийг харуулсан слайдуудыг үзүүлэв. Мөн тайланд таблетыг багцалсан олон тооны хэрэгслүүд байсан. Индексийн талаар юу хэлэх вэ?
Тэд ч бас савладаг.
Гэхдээ вакуум нь индекст нөлөөлөхгүй юу?
Зарим нь индекстэй ажилладаг. Жишээлбэл, pg_rapack, pgcompacttable. Вакуум нь индексүүдийг дахин үүсгэж, тэдгээрт нөлөөлдөг. VACUUM FULL-ийн тусламжтайгаар бүх зүйлийг дарж бичих, өөрөөр хэлбэл бүх хүнтэй ажиллах санаа юм.
Мөн хоёр дахь асуулт. Хуулбарын талаархи тайлан яагаад хуулбарлахаас маш их хамааралтай болохыг би ойлгохгүй байна. Тайлан уншиж, хуулбарлах нь бичдэг юм шиг надад санагдсан.
Хуулбарлах зөрчил юунд хүргэдэг вэ? Бидэнд үйл явц явагддаг Мастер бий. Манайд машины тоос соруулах ажил явагдаж байна. Автовакуум үнэхээр юу хийдэг вэ? Тэр хэдэн хуучин мөрүүдийг хайчилж байна. Хэрэв энэ үед бид эдгээр хуучин мөрүүдийг уншсан хуулбар дээр хүсэлт байгаа бол Мастер дээр автовакуум эдгээр мөрүүдийг дарж бичих боломжтой гэж тэмдэглэсэн нөхцөл байдал үүссэн бол бид тэдгээрийг дарж бичсэн. Бид өгөгдлийн багцыг хүлээн авсан бөгөөд бид хуулбар дээр хүсэлт гаргах шаардлагатай мөрүүдийг дахин бичих шаардлагатай бол хуулбарлах процесс таны тохируулсан хугацаа дуусахыг хүлээх болно. Дараа нь PostgreSQL түүнд юу илүү чухал болохыг шийдэх болно. Мөн түүний хувьд хүсэлтээс илүү хуулбарлах нь чухал бөгөөд тэр хуулбар дээр эдгээр өөрчлөлтийг хийхийн тулд хүсэлтийг буудна.
Андрей, надад асуулт байна. Танилцуулгын үеэр үзүүлсэн эдгээр гайхалтай графикууд нь таны ямар нэгэн хэрэглүүрийн ажлын үр дүн мөн үү? Графикууд хэрхэн хийгдсэн бэ?
Энэ бол үйлчилгээ юм .
Энэ арилжааны бүтээгдэхүүн мөн үү?
Тиймээ. Энэ бол арилжааны бүтээгдэхүүн юм.
Эх сурвалж: www.habr.com