AWR: Өгөгдлийн сангийн гүйцэтгэл хэр “мэргэжилтэн” вэ?

Энэхүү богино нийтлэлээр би Oracle Exadata дээр ажиллаж байгаа AWR мэдээллийн сангийн шинжилгээтэй холбоотой нэг үл ойлголцлыг арилгахыг хүсч байна. Бараг 10 жилийн турш би Exadata програм хангамжийн бүтээмжид ямар хувь нэмэр оруулдаг вэ гэсэн асуулттай байнга тулгарсаар ирсэн. Эсвэл шинээр зохиосон үгсийг ашиглан: тодорхой мэдээллийн сангийн ажил хэр "мэргэжилтэн" вэ?

AWR: Өгөгдлийн сангийн гүйцэтгэл хэр “мэргэжилтэн” вэ?

Ихэнхдээ энэ зөв асуултад миний бодлоор AWR статистикийн мэдээлэлд үндэслэн буруу хариулдаг. Энэ нь хариу өгөх хугацааг процессоруудын (DB CPU) ажиллах хугацаа болон янз бүрийн ангиллын хүлээх хугацааны нийлбэр гэж үздэг системийн хүлээх аргыг танилцуулж байна.

Exadata гарч ирснээр Exadata програм хангамжийн үйл ажиллагаатай холбоотой системийн тодорхой хүлээлтүүд AWR статистикт гарч ирэв. Дүрмээр бол ийм хүлээлгийн нэр нь "нүд" гэсэн үгээр эхэлдэг (Exadata Storage серверийг нүд гэж нэрлэдэг) эдгээрээс хамгийн түгээмэл нь "cell smart table scan", "cell multiblock" гэсэн өөрөө тайлбартай хүлээлтүүд юм. физик унших" болон "нүдний нэг блок физик унших".

Ихэнх тохиолдолд ийм Exadata хүлээлтийн нийт хариу өгөх хугацаанд эзлэх хувь бага байдаг тул тэд нийт хүлээлтийн хугацаанд хамгийн шилдэг 10 үйл явдалд багтдаггүй (энэ тохиолдолд та тэдгээрийг урд талын хүлээлтээс хайх хэрэгтэй. Үйл явдлын хэсэг). Бид үйлчлүүлэгчдийнхээ өдөр тутмын AWR-ийн жишээг маш их бэрхшээлтэй тулгарсан бөгөөд Exadata-ийн хүлээлтийг Топ10 хэсэгт багтаасан бөгөөд нийтдээ 5% орчим байна.

үйл явдал

Хүлээж байна

Нийт хүлээх хугацаа (сек)

Дундаж хүлээх

%DB цаг

Хүлээгээрэй анги

DB CPU

115.2K

70.4

SQL*Dblink-аас илүү их мэдээлэл авах

670,196

5471.5

8.16ms

3.3

Сүлжээний

эсийн нэг блок физик унших

5,661,452

3827.6

676.07us хувилбар

2.3

Хэрэглэгчийн I/O

ASM дахин тэнцвэржүүлэх синк хийх

4,350,012

3481.3

800.30us хувилбар

2.1

Бусад

эсийн олон блок физик унших

759,885

2252

2.96ms

1.4

Хэрэглэгчийн I/O

шууд замыг уншина

374,368

1811.3

4.84ms

1.1

Хэрэглэгчийн I/O

Dblink-аас SQL*Net мессеж

7,983

1725

216.08ms

1.1

Сүлжээний

эсийн ухаалаг ширээний сканнер

1,007,520

1260.7

1.25ms

0.8

Хэрэглэгчийн I/O

шууд зам унших температур

520,211

808.4

1.55ms

0.5

Хэрэглэгчийн I/O

enq: TM - маргаан

652

795.8

1220.55ms

0.5

Програмын

Ийм AWR статистик мэдээллээс дараахь дүгнэлтийг ихэвчлэн гаргадаг.

1. Өгөгдлийн сангийн гүйцэтгэлд Exadata ид шидийн оруулсан хувь нэмэр тийм ч өндөр биш - энэ нь 5% -иас хэтрэхгүй, мэдээллийн сан муу "exadatize" байдаг.

2. Хэрэв ийм мэдээллийн санг Exadata-аас сонгодог "сервер + массив" архитектур руу шилжүүлбэл гүйцэтгэл нь тийм ч их өөрчлөгдөхгүй. Учир нь энэ массив нь Exadata хадгалах системээс гурав дахин удаан (орчин үеийн бүх Flash массивын хувьд бараг боломжгүй) байсан ч 5% -ийг гурваар үржүүлбэл оролт/гаралтын эзлэх хувь 15% болж өснө. - мэдээллийн сан үүнийг даван туулах нь гарцаагүй!

Эдгээр хоёр дүгнэлт нь буруу бөгөөд үүнээс гадна Exadata програм хангамжийн цаадах санааны ойлголтыг гажуудуулж байна. Exadata нь зүгээр л хурдан оролт гаралтыг хангаад зогсохгүй сонгодог сервер + массив архитектуртай харьцуулахад үндсээрээ өөрөөр ажилладаг. Хэрэв өгөгдлийн сангийн үйл ажиллагаа үнэхээр "зассан" бол SQL логикийг хадгалах систем рүү шилжүүлнэ. Хадгалах серверүүд нь хэд хэдэн тусгай механизмын ачаар (ялангуяа Exadata Storage Indexs, гэхдээ зөвхөн биш) шаардлагатай өгөгдлийг өөрсдөө олж, DB-г серверүүд рүү илгээдэг. Тэд үүнийг нэлээд үр дүнтэй хийдэг тул хариу өгөх нийт хугацаанд ердийн Exadata-ийн хүлээх эзлэх хувь бага байна. 

Энэ хувьцаа Exadata-аас гадуур хэрхэн өөрчлөгдөх вэ? Энэ нь мэдээллийн сангийн гүйцэтгэлд бүхэлд нь хэрхэн нөлөөлөх вэ? Туршилт нь эдгээр асуултанд хамгийн сайн хариулах болно. Жишээлбэл, Exadata-аас гадуур "ухаалаг ширээний сканнер"-ийг хүлээх нь маш хүнд Хүснэгтийн бүрэн скан болж хувирдаг тул I/O нь хариу өгөх хугацааг бүхэлд нь авч, гүйцэтгэл нь эрс мууддаг. Тийм ч учраас AWR-д дүн шинжилгээ хийхдээ Exadata-ийн хүлээлтийн нийт хувийг түүний ид шидийн гүйцэтгэлд оруулсан хувь нэмэр гэж үзэх нь буруу бөгөөд үүнээс гадна Exadata-аас гадуур гүйцэтгэлийг таамаглахад энэ хувийг ашиглах нь буруу юм. Мэдээллийн сангийн ажил хэр "яг" болохыг ойлгохын тулд "Инстанцийн үйл ажиллагааны статистик" хэсгийн AWR статистикийг судалж (өөрийгөө тайлбарласан олон тооны статистикууд байдаг) тэдгээрийг хооронд нь харьцуулах хэрэгтэй.

Exadata-аас гадуурх өгөгдлийн сан ямар санагдахыг ойлгохын тулд зорилтот архитектур дээрх нөөц хуулбараас мэдээллийн баазыг клон хийж, ачааллын үед энэ клоны гүйцэтгэлд дүн шинжилгээ хийх нь хамгийн сайн арга юм. Эксадата эзэмшигчид дүрмээр бол ийм боломж байдаг.

Зохиогч: Jet Infosystems мэдээллийн сангийн хэлтсийн дарга Алексей Струченко

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх