Zabbix бол хяналтын систем юм. Бусад системийн нэгэн адил энэ нь бүх хяналтын системийн гурван үндсэн асуудалтай тулгардаг: өгөгдөл цуглуулах, боловсруулах, түүхийг хадгалах, цэвэрлэх.
Мэдээллийг хүлээн авах, боловсруулах, бүртгэх үе шатууд нь цаг хугацаа шаарддаг. Тийм ч их биш, гэхдээ том системийн хувьд энэ нь их хэмжээний сааталд хүргэж болзошгүй юм. Хадгалах асуудал нь өгөгдөлд хандах асуудал юм. Тэдгээрийг тайлан, шалгалт, триггерүүдэд ашигладаг. Өгөгдлийн хандалтын хоцрогдол нь гүйцэтгэлд нөлөөлдөг. Өгөгдлийн сан өсөхөд хамааралгүй өгөгдлийг устгах шаардлагатай болдог. Устгах нь зарим нөөцийг иддэг хэцүү ажил юм.
Zabbix-д цуглуулах, хадгалах явцад саатал гарах асуудлыг кэш хийх замаар шийддэг: хэд хэдэн төрлийн кэш, мэдээллийн сан дахь кэш. Гурав дахь асуудлыг шийдэхийн тулд кэш хийх нь тохиромжгүй тул Zabbix TimescaleDB ашигласан. Тэр танд энэ тухай хэлэх болно Андрей Гущин - техникийн туслах инженер . Андрей Zabbix-ийг 6 жил гаруй дэмжиж ирсэн бөгөөд гүйцэтгэлийн шууд туршлагатай.
TimescaleDB хэрхэн ажилладаг вэ, энэ нь ердийн PostgreSQL-тэй харьцуулахад ямар гүйцэтгэлийг өгч чадах вэ? Zabbix нь TimescaleDB мэдээллийн санд ямар үүрэг гүйцэтгэдэг вэ? Хэрхэн эхнээс нь эхлэх, PostgreSQL-ээс хэрхэн шилжих вэ, аль тохиргоо нь илүү сайн гүйцэтгэлтэй вэ? Энэ бүхний тухай захын дор.
Бүтээмжийн сорилтууд
Хяналтын систем бүр гүйцэтгэлийн тодорхой сорилтуудтай тулгардаг. Би тэдгээрийн гурвын тухай ярих болно: мэдээлэл цуглуулах, боловсруулах, хадгалах, түүхийг цэвэрлэх.
Хурдан мэдээлэл цуглуулах, боловсруулах. Сайн хяналтын систем нь бүх өгөгдлийг хурдан хүлээн авч, триггер илэрхийллийн дагуу, шалгуурын дагуу боловсруулах ёстой. Боловсруулсны дараа систем нь энэ өгөгдлийг дараа нь ашиглахын тулд мэдээллийн санд хурдан хадгалах ёстой.
Түүхийн хадгалалт. Сайн хяналтын систем нь түүхийг мэдээллийн санд хадгалж, хэмжигдэхүүнд хялбар хандах боломжийг олгоно. Түүхийг тайлан, график, триггер, босго, тооцоолсон дохиоллын өгөгдлийн зүйлд ашиглах шаардлагатай.
Түүхийг цэвэрлэж байна. Заримдаа хэмжүүр хадгалах шаардлагагүй өдөр ирдэг. Яагаад танд 5 жилийн өмнө, нэг эсвэл хоёр сарын өмнө цуглуулсан өгөгдөл хэрэгтэй байна вэ: зарим зангилаа устгагдсан, зарим хостууд эсвэл хэмжигдэхүүнүүд хуучирсан, цуглуулагдахаа больсон. Сайн хяналтын систем нь мэдээллийн сан өсөхгүйн тулд түүхийн мэдээллийг хадгалж, үе үе устгаж байх ёстой.
Хуучирсан өгөгдлийг цэвэрлэх нь мэдээллийн сангийн гүйцэтгэлд ихээхэн нөлөөлдөг чухал асуудал юм.
Zabbix дээр кэш хийх
Zabbix-д эхний болон хоёр дахь дуудлагыг кэш ашиглан шийддэг. RAM нь өгөгдөл цуглуулах, боловсруулахад ашиглагддаг. Хадгалалтын хувьд - триггер, график, тооцоолсон өгөгдлийн элементүүд дэх түүх. Өгөгдлийн сангийн тал дээр үндсэн сонголтууд, жишээлбэл, графикуудын зарим кэш байдаг.
Zabbix серверийн хажуу талд кэш хийх нь өөрөө:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Тэдгээрийг илүү нарийвчлан авч үзье.
ConfigurationCache
Энэ бол бидний хэмжигдэхүүн, хостууд, өгөгдлийн элементүүд, триггерүүд - Урьдчилан боловсруулах болон өгөгдөл цуглуулахад шаардлагатай бүх зүйлийг хадгалдаг гол кэш юм.
Мэдээллийн санд шаардлагагүй асуулга үүсгэхгүйн тулд энэ бүгдийг ConfigurationCache-д хадгалдаг. Сервер ажиллаж эхэлсний дараа бид энэ кэшийг шинэчилж, тохиргоог үүсгэж, үе үе шинэчилдэг.
Өгөгдөл цуглуулах
Диаграм нь нэлээд том боловч гол зүйл нь юм сонгогчид. Эдгээр нь янз бүрийн "санал асуулга" - угсрах үйл явц юм. Тэд янз бүрийн төрлийн угсралтыг хариуцдаг: тэд SNMP, IPMI-ээр дамжуулан өгөгдлийг цуглуулж, бүгдийг нь PreProcessing руу шилжүүлдэг.
Цуглуулагчдыг улбар шар өнгөөр дүрсэлсэн.
Zabbix нь шалгалтыг нэгтгэхэд шаардлагатай нэгтгэх зүйлсийг тооцоолсон. Хэрэв бидэнд байгаа бол бид тэдгээрийн өгөгдлийг ValueCache-ээс шууд татаж авдаг.
Урьдчилан боловсруулалтын түүхийн кэш
Бүх цуглуулагчид ажил хүлээн авахдаа ConfigurationCache ашигладаг. Дараа нь тэдгээрийг PreProcessing руу шилжүүлнэ.
PreProcessing нь ConfigurationCache ашиглан Урьдчилан боловсруулах алхмуудыг хүлээн авдаг. Энэ өгөгдлийг янз бүрийн аргаар боловсруулдаг.
PreProcessing ашиглан өгөгдлийг боловсруулсны дараа бид HistoryCache-д боловсруулалт хийхээр хадгалдаг. Энэ нь мэдээлэл цуглуулах ажлыг дуусгаж, бид Zabbix-ийн үндсэн процесс руу шилждэг. түүхийн синхрончлол, учир нь энэ нь цул архитектур юм.
Тайлбар: Урьдчилан боловсруулах нь нэлээд хэцүү ажиллагаа юм. v 4.2-тэй энэ нь прокси руу шилжсэн. Хэрэв танд олон тооны өгөгдлийн элемент, цуглуулах давтамж бүхий маш том Zabbix байгаа бол энэ нь ажлыг ихээхэн хөнгөвчлөх болно.
ValueCache, түүх, чиг хандлагын кэш
Түүхийн синхрончлол нь өгөгдлийн элемент бүрийг, өөрөөр хэлбэл утгыг атомаар боловсруулдаг гол процесс юм.
Түүхийн синхронч нь HistoryCache-ээс утгуудыг авч, тооцоололд триггер байгаа эсэхийг Тохиргоог шалгадаг. Хэрэв тэд байгаа бол тооцоолно.
Түүхийн синхрончлол нь үйл явдал үүсгэх, тохиргоонд шаардлагатай бол сэрэмжлүүлэг үүсгэх хурдатгал болон бичлэгүүдийг үүсгэдэг. Хэрэв дараагийн боловсруулалт хийх өдөөгч байгаа бол түүхийн хүснэгтэд хандахгүйн тулд энэ утгыг ValueCache-д хадгалдаг. Ийм байдлаар ValueCache нь триггер болон тооцоолсон элементүүдийг тооцоолоход шаардлагатай мэдээллээр дүүрдэг.
Түүхийн синхрончлол нь бүх өгөгдлийг мэдээллийн санд бичиж, диск рүү бичдэг. Боловсруулах процесс энд дуусна.
Өгөгдлийн санд кэш хийх
Өгөгдлийн сангийн тал дээр та үйл явдлын график эсвэл тайланг үзэхийг хүсвэл янз бүрийн кэшүүд байдаг.
Innodb_buffer_poolMySQL тал дээр;shared_buffersPostgreSQL тал дээр;effective_cache_sizeOracle талд;shared_poolDB2 талд.
Өөр олон кэшүүд байдаг ч эдгээр нь бүх мэдээллийн сангийн гол зүйлүүд юм. Эдгээр нь асуулгад ихэвчлэн шаардлагатай өгөгдлийг RAM-д хадгалах боломжийг олгодог. Тэд үүнд зориулж өөрийн гэсэн технологитой.
Өгөгдлийн сангийн гүйцэтгэл маш чухал
Zabbix сервер нь байнга мэдээлэл цуглуулж бичдэг. Дахин эхлүүлэх үед энэ нь ValueCache-г дүүргэхийн тулд түүхээс уншина. Скрипт болон тайланг ашигладаг Zabbix API, вэб интерфэйс дээр бүтээгдсэн. Zabbix API нь мэдээллийн санд нэвтэрч, график, тайлан, үйл явдлын жагсаалт болон сүүлийн үеийн асуудлуудад шаардлагатай өгөгдлийг татаж авдаг.
Дүрслэхийн тулд - Графана. Энэ бол манай хэрэглэгчдийн дунд түгээмэл шийдэл юм. Энэ нь Zabbix API болон мэдээллийн сан руу шууд хүсэлт илгээх боломжтой бөгөөд өгөгдөл хүлээн авах тодорхой өрсөлдөөнийг бий болгодог. Тиймээс үр дүн, туршилтыг хурдан шуурхай хүргэхийн тулд мэдээллийн санг илүү нарийн, сайн тохируулах шаардлагатай.
Гэрийн ажилтан
Zabbix дахь гүйцэтгэлийн гурав дахь сорилт бол Housekeeper ашиглан түүхийг цэвэрлэх явдал юм. Энэ нь бүх тохиргоог дагаж мөрддөг - өгөгдлийн элементүүд нь өөрчлөлтийн динамикийг хэдэн өдрийн дотор (трэнд) хадгалахыг заадаг.
Бид TrendsCache-г шууд тооцдог. Мэдээлэл ирэхэд бид үүнийг нэг цагийн турш нэгтгэж, чиг хандлагын өөрчлөлтийн динамикийг хүснэгтэд тэмдэглэнэ.
Гэрийн үйлчлэгч нь ердийн "сонгодог" ашиглан мэдээллийн сангаас мэдээллийг эхлүүлж устгадаг. Энэ нь үргэлж үр дүнтэй байдаггүй, үүнийг дотоод үйл явцын гүйцэтгэлийн графикаас харж болно.
Улаан график нь History syncer байнга завгүй байгааг харуулж байна. Дээд талд байгаа улбар шар график нь байнгын ажиллаж байгаа Housekeeper юм. Тэрээр мэдээллийн санг өөрийн заасан бүх мөрийг устгахыг хүлээж байна.
Гэрийн үйлчлэгчийг хэзээ идэвхгүй болгох вэ? Жишээлбэл, "Зүйлийн ID" байдаг бөгөөд та сүүлийн 5 мянган мөрийг тодорхой хугацаанд устгах хэрэгтэй. Мэдээжийн хэрэг, энэ нь индексээр явагддаг. Гэхдээ ихэвчлэн өгөгдлийн багц нь маш том бөгөөд мэдээллийн сан нь дискнээс уншиж, кэш рүү оруулдаг. Энэ нь өгөгдлийн сангийн хувьд үргэлж маш үнэтэй ажиллагаа бөгөөд мэдээллийн сангийн хэмжээнээс хамааран гүйцэтгэлийн асуудалд хүргэж болзошгүй юм.
Гэрийн үйлчлэгчийг идэвхгүй болгоход хялбар байдаг. Вэб интерфэйс дээр гэрийн үйлчлэгч нарт зориулсан "Захиргааны ерөнхий" тохиргоо байдаг. Бид дотоод чиг хандлагын түүхэнд зориулж дотоод цэвэрлэгээг идэвхгүй болгосон бөгөөд үүнийг удирдахаа больсон.
Гэрийн үйлчлэгчийг унтраасан, графикуудыг тэгшитгэсэн - энэ тохиолдолд ямар асуудал гарч болох вэ, гүйцэтгэлийн гурав дахь сорилтыг шийдвэрлэхэд юу туслах вэ?
Хуваалт - хуваалт эсвэл хуваалт
Ерөнхийдөө хуваалтыг миний жагсаасан өгөгдлийн сан бүр дээр өөр өөр аргаар тохируулдаг. Тус бүр өөрийн гэсэн технологитой боловч ерөнхийдөө ижил төстэй байдаг. Шинэ хуваалт үүсгэх нь ихэвчлэн тодорхой асуудалд хүргэдэг.
Ихэвчлэн хуваалтыг "тохируулга" -аас хамааран тохируулдаг - нэг өдрийн дотор үүсгэсэн өгөгдлийн хэмжээ. Дүрмээр бол хуваалтыг нэг өдрийн дотор гаргадаг бөгөөд энэ нь хамгийн бага хэмжээ юм. Шинэ багцын чиг хандлагын хувьд - 1 сар.
Хэрэв "тохируулга" нь маш том бол утгууд өөрчлөгдөж болно. Хэрэв жижиг "тохируулга" нь 5 nvps (секундэд шинэ утга), дунд нь 000-аас 5 хүртэл байвал том нь 000 nvps-ээс дээш байна. Эдгээр нь мэдээллийн сангийн нарийн тохиргоог шаарддаг том бөгөөд маш том суулгацууд юм.
Маш том суурилуулалтанд нэг өдрийн хугацаа оновчтой биш байж магадгүй юм. Би өдөрт 40 ГБ ба түүнээс дээш хэмжээтэй MySQL хуваалтыг харсан. Энэ бол асуудал үүсгэж болох маш их хэмжээний өгөгдөл бөгөөд багасгах шаардлагатай.
Хуваалт нь юу өгдөг вэ?
Хуваах хүснэгтүүд. Ихэнхдээ эдгээр нь диск дээрх тусдаа файлууд байдаг. Асуулгын төлөвлөгөө нь нэг хуваалтыг илүү оновчтойгоор сонгоно. Ихэвчлэн хуваалтыг мужид ашигладаг - энэ нь Zabbix-д бас хамаатай. Бид тэнд "цаг хугацааны тамга" ашигладаг - эриний эхэн үеэс хойш. Эдгээр нь бидний хувьд энгийн тоо юм. Та өдрийн эхлэл ба төгсгөлийг тохируулдаг - энэ бол хуваалт юм.
Түргэн арилгах - DELETE. Устгах мөрийн сонголтоос илүү нэг файл/дэд хүснэгтийг сонгосон.
Өгөгдөл хайлтыг мэдэгдэхүйц хурдасгадаг SELECT - хүснэгтийг бүхэлд нь биш харин нэг буюу хэд хэдэн хуваалтыг ашигладаг. Хэрэв та хоёр хоногийн хугацаатай өгөгдөлд хандаж байгаа бол мэдээллийн сангаас хурдан татаж авах болно, учир нь та кэш рүү зөвхөн нэг файлыг ачаалж, том хүснэгт биш буцааж өгөх хэрэгтэй.
Ихэнхдээ олон мэдээллийн санг бас хурдасгадаг INSERT - хүүхдийн хүснэгтэд оруулах.
Цагийн хуваарь DB
v 4.2-ийн хувьд бид TimescaleDB руу анхаарлаа хандуулсан. Энэ бол уугуул интерфейстэй PostgreSQL-д зориулсан өргөтгөл юм. Өргөтгөл нь харилцааны өгөгдлийн сангийн ашиг тусыг алдалгүйгээр цагийн цувааны өгөгдөлтэй үр дүнтэй ажилладаг. TimescaleDB нь мөн автоматаар хуваагддаг.
TimescaleDB нь ойлголттой байдаг ихсэх чадвартай (hypertable) таны үүсгэсэн. Үүнд агуулагддаг хэсгүүд - хуваалтууд. Хэсэг хэсгүүд нь бусад фрагментуудад нөлөөлдөггүй автоматаар удирддаг гипертаблицын фрагментүүд юм. Хэсэг бүр өөрийн гэсэн хугацааны хязгаартай байдаг.
TimescaleDB ба PostgreSQL
TimescaleDB үнэхээр үр дүнтэй ажилладаг. Өргөтгөлийн үйлдвэрлэгчид асуулга боловсруулах илүү зөв алгоритм, ялангуяа inserts ашигладаг гэж мэдэгджээ. Өгөгдлийн багцын оруулах хэмжээ нэмэгдэхийн хэрээр алгоритм нь тогтмол гүйцэтгэлийг хадгалж байдаг.
200 сая мөрийн дараа PostgreSQL ихэвчлэн унадаг ба гүйцэтгэлийг 0 хүртэл алддаг. TimescaleDB нь танд ямар ч хэмжээний өгөгдөлд "оруулах" үр дүнтэй оруулах боломжийг олгодог.
тохиргоо
TimescaleDB суулгах нь ямар ч багцад маш хялбар байдаг. IN бүх зүйлийг нарийвчлан тайлбарласан - энэ нь албан ёсны PostgreSQL багцуудаас хамаарна. TimescaleDB-г гараар бүтээж, эмхэтгэх боломжтой.
Zabbix мэдээллийн сангийн хувьд бид зүгээр л өргөтгөлийг идэвхжүүлдэг:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Та идэвхжүүлнэ үү extension мөн Zabbix мэдээллийн санд зориулж үүсгэнэ үү. Сүүлийн алхам бол гипер хүснэгт үүсгэх явдал юм.
Түүхийн хүснэгтүүдийг TimescaleDB руу шилжүүлж байна
Үүний тулд тусгай функц байдаг create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Функц нь гурван параметртэй. Эхлээд - мэдээллийн сан дахь хүснэгт, үүний тулд та hypertable үүсгэх хэрэгтэй. Хоёрдугаарт - талбар, үүний дагуу та үүсгэх хэрэгтэй chunk_time_interval — ашиглах хуваалтын хэсгүүдийн интервал. Миний хувьд интервал нь нэг өдөр - 86.
Гурав дахь параметр - migrate_data. Хэрэв та тохируулсан бол true, дараа нь одоогийн бүх өгөгдлийг урьдчилан үүсгэсэн хэсгүүдэд шилжүүлнэ. Би өөрөө үүнийг ашигласан migrate_data. Би ойролцоогоор 1 TB-тэй байсан бөгөөд энэ нь нэг цаг гаруй болсон. Зарим тохиолдолд туршилтын явцад би хадгалахад шаардлагагүй тэмдэгтүүдийн түүхэн өгөгдлийг устгасан бөгөөд тэдгээрийг шилжүүлэхгүй байх болно.
Сүүлийн алхам - UPDATE: дээр db_extension тавих timescaledbИнгэснээр мэдээллийн сан энэ өргөтгөл байгаа гэдгийг ойлгох болно. Zabbix нь үүнийг идэвхжүүлж, TimescaleDB-д шаардлагатай синтакс болон өгөгдлийн сангийн асуулгыг зөв ашигладаг.
Техник хангамжийн тохиргоо
Би хоёр сервер ашигласан. Эхлээд - VMware машин. Энэ нь нэлээд жижиг: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz процессор, 16 ГБ RAM, 200 ГБ SSD.
Би PostgreSQL 10.8-г Debian 10.8-1.pgdg90+1 үйлдлийн систем болон xfs файлын системээр суулгасан. Би энэ мэдээллийн санг ашиглахын тулд бүх зүйлийг хамгийн бага хэмжээгээр тохируулсан ба Zabbix өөрөө ашиглахыг хассан.
Нэг машин дээр Zabbix сервер, PostgreSQL болон байсан ачааллын агентууд. Надад ашиглаж байсан 50 идэвхтэй агент байсан LoadableModuleянз бүрийн үр дүнг маш хурдан гаргахын тулд: тоо, мөр. Би мэдээллийн санг маш их мэдээллээр дүүргэсэн.
Эхэндээ тохиргоог агуулж байсан 5 элемент хост бүрт өгөгдөл. Бараг бүх элемент нь бодит суурилуулалттай төстэй болгох гохыг агуулсан байдаг. Зарим тохиолдолд нэгээс олон гох байсан. Нэг сүлжээний зангилааны хувьд тэнд байсан 3-000 өдөөгч.
Өгөгдлийн зүйлийг шинэчлэх интервал − 4-7 секунд. Би ачааллыг өөрөө зохицуулж, зөвхөн 50 агентийг ашиглаад зогсохгүй, нэмж оруулав. Мөн өгөгдлийн элементүүдийг ашиглан би ачааллыг динамикаар тохируулж, шинэчлэх интервалыг 4 секунд хүртэл бууруулсан.
PostgreSQL. 35 nvps
Энэ техник хангамж дээр миний анхны гүйлт нь цэвэр PostgreSQL дээр байсан - секундэд 35 мянган утга. Таны харж байгаагаар өгөгдөл оруулахад секундын хэдэн хэсэг шаардлагатай - бүх зүйл сайн, хурдан байна. Цорын ганц зүйл бол 200 GB SSD диск хурдан дүүрдэг.
Энэ бол стандарт Zabbix серверийн гүйцэтгэлийн хяналтын самбар юм.
Эхний цэнхэр график нь секундэд байгаа утгын тоо юм. Баруун талд байгаа хоёр дахь график нь бүтээх процессуудын ачаалал юм. Гурав дахь нь дотоод бүтээх процессуудыг ачаалж байна: түүхийн синхрончлолууд болон энд нэлээд удаан ажиллаж байгаа Housekeeper.
Дөрөв дэх график нь HistoryCache ашиглалтыг харуулж байна. Энэ нь мэдээллийн санд оруулахаас өмнө нэг төрлийн буфер юм. Ногоон тав дахь график нь ValueCache-ийн хэрэглээг, өөрөөр хэлбэл триггерүүдэд хэдэн ValueCache цохиж байгааг харуулж байна - энэ нь секундэд хэдэн мянган утгыг илэрхийлдэг.
PostgreSQL. 50 nvps
Дараа нь би ижил тоног төхөөрөмж дээрх ачааллыг секундэд 50 мянган утга хүртэл нэмэгдүүлсэн.
Гэрийн үйлчлэгчээс ачаалах үед 10 мянган утгыг оруулахад 2-3 секунд зарцуулсан.
Гэрийн үйлчлэгч аль хэдийн ажилд саад болж эхэлжээ.
Гурав дахь графикаас харахад ерөнхийдөө траппер болон түүхийн синхерүүдийн ачаалал 60% хэвээр байна. Дөрөв дэх график дээр HistoryCache нь Housekeeper-ийн үйл ажиллагааны явцад аль хэдийн идэвхтэй дүүргэж эхэлж байна. Энэ нь 20% дүүрсэн бөгөөд энэ нь ойролцоогоор 0,5 ГБ юм.
PostgreSQL. 80 nvps
Дараа нь би ачааллыг секундэд 80 мянган утга болгон нэмэгдүүлсэн. Энэ нь ойролцоогоор 400 мянган өгөгдлийн элемент, 280 мянган триггер юм.
Гучин түүхий синхерийн ачаалах зардал аль хэдийн нэлээд өндөр байна.
Би мөн янз бүрийн параметрүүдийг нэмэгдүүлсэн: түүхийн синхрончлол, кэш.
Миний техник хангамж дээр түүхийн синхрончлолын ачаалал дээд зэргээр нэмэгдсэн. HistoryCache хурдан мэдээллээр дүүрсэн - боловсруулах өгөгдөл буферт хуримтлагдсан.
Энэ бүх хугацаанд би процессор, RAM болон бусад системийн параметрүүдийг хэрхэн ашиглаж байгааг ажиглаж, дискний ашиглалт хамгийн дээд хэмжээнд байгааг олж мэдсэн.
Би хэрэглээнд хүрсэн хамгийн их дискний хүчин чадал Энэ техник хангамж болон энэ виртуал машин дээр. Ийм эрчимтэй PostgreSQL нь өгөгдлийг нэлээд идэвхтэй угааж эхэлсэн бөгөөд диск бичих, унших цаг байхгүй болсон.
Хоёр дахь сервер
Би 48 процессортой, 128 ГБ RAM-тай өөр сервер авсан. Би үүнийг тохируулсан - 60 түүх синхрончлолд тохируулж, зөвшөөрөгдсөн гүйцэтгэлд хүрсэн.
Үнэн хэрэгтээ энэ нь ямар нэгэн зүйл хийх шаардлагатай бүтээмжийн хязгаар юм.
TimescaleDB. 80 nvps
Миний гол ажил бол TimescaleDB-ийн чадварыг Zabbix ачааллын эсрэг турших явдал юм. Секундэд 80 мянган утга нь маш их, хэмжигдэхүүн цуглуулах давтамж (мэдээж Yandex-ээс бусад) ба нэлээд том "тохиргоо" юм.
График болгонд уналт байдаг - энэ бол өгөгдлийн шилжилт хөдөлгөөн юм. Zabbix серверт алдаа гарсны дараа түүхийн синхрончлолыг ачаалах профайл маш их өөрчлөгдсөн - энэ нь гурван удаа буурсан.
TimescaleDB нь танд өгөгдлийг бараг 3 дахин хурдан оруулах, HistoryCache бага ашиглах боломжийг олгодог.
Үүний дагуу та мэдээллийг цаг тухайд нь хүлээн авах болно.
TimescaleDB. 120 nvps
Дараа нь би өгөгдлийн элементүүдийн тоог 500 мянга болгон нэмэгдүүлсэн гол ажил бол TimescaleDB-ийн чадварыг шалгах явдал байв - би секундэд 125 мянган утгыг тооцоолсон.
Энэ бол удаан хугацаанд ажиллах боломжтой "тохируулга" юм. Гэхдээ миний диск ердөө 1,5 TB байсан тул хоёр өдрийн дотор дүүргэсэн.
Хамгийн гол нь нэгэн зэрэг шинэ TimescaleDB хуваалтууд бий болсон явдал юм.
Энэ нь гүйцэтгэлийн хувьд огт анзаарагдахгүй. Жишээ нь MySQL дээр хуваалтуудыг үүсгэх үед бүх зүйл өөр байдаг. Энэ нь ихэвчлэн шөнийн цагаар тохиолддог, учир нь энэ нь ерөнхий оруулга, хүснэгттэй ажиллах, үйлчилгээний доройтлыг үүсгэж болзошгүй юм. TimescaleDB-ийн хувьд энэ нь тийм биш юм.
Жишээ болгон би олон нийтийн дундаас нэг график үзүүлье. Зураг дээр TimescaleDB идэвхжсэн бөгөөд үүний ачаар процессор дээр io.weight ашиглах ачаалал буурсан байна. Дотоод үйл явцын элементүүдийн хэрэглээ мөн буурсан. Түүгээр ч барахгүй энэ бол SSD биш энгийн бин дискэн дээрх энгийн виртуал машин юм.
үр дүн нь
TimescaleDB нь жижиг "тохируулга" хийх сайн шийдэл юм., энэ нь дискний гүйцэтгэлд нөлөөлдөг. Энэ нь мэдээллийн баазыг техник хангамж руу аль болох хурдан шилжүүлэх хүртэл сайн ажиллах боломжийг танд олгоно.
TimescaleDB нь тохируулахад хялбар, гүйцэтгэлийн өсөлтийг өгдөг, Zabbix болон PostgreSQL-ээс давуу талтай.
Хэрэв та PostgreSQL ашигладаг бөгөөд үүнийг өөрчлөхөөр төлөвлөөгүй бол би зөвлөж байна PostgreSQL-ийг TimescaleDB өргөтгөлтэй хамт Zabbix-тэй хамт ашигла. Энэ шийдэл нь дунд зэргийн "тохиргоо" хүртэл үр дүнтэй ажилладаг.
"Өндөр гүйцэтгэл" гэж хэлэхэд бид үүнийг хэлдэг . Үйлчилгээг сая сая хэрэглэгчдэд үйлчлэх боломжийг олгодог технологи, практикийн талаар мэдэхийн тулд та удаан хүлээх шаардлагагүй болно. Жагсаалт 7-р сарын 8, XNUMX-ны хувьд бид аль хэдийн эмхэтгэсэн, гэхдээ энд илүү ихийг санал болгож болно.
Манайд бүртгүүлнэ үү и , үүгээр бид удахгүй болох хурлын онцлогуудыг илчилж, түүнээс хэрхэн хамгийн их ашиг хүртэх талаар олж мэдэх болно.
Эх сурвалж: www.habr.com