Prometey 2-dagi vaqt seriyalari ma'lumotlar bazasi (TSDB) muhandislik yechimining ajoyib namunasi bo'lib, u Prometheus 2-dagi v1 xotirasiga nisbatan ma'lumotlarni to'plash tezligi, so'rovlarni bajarish va resurslar samaradorligi nuqtai nazaridan katta yaxshilanishlarni taklif etadi. Biz Prometey 2 ni Percona Monitoring and Management (PMM) da joriy qildik va men Prometey 2 TSDB ning ishlashini tushunish imkoniga ega bo'ldim. Ushbu maqolada men ushbu kuzatishlar natijalari haqida gapiraman.
Prometeyning o'rtacha ish yuki
Umumiy maqsadli ma'lumotlar bazalari bilan shug'ullanadiganlar uchun odatiy Prometey ish yuki juda qiziq. Ma'lumotlarni to'plash tezligi barqaror bo'ladi: odatda siz kuzatadigan xizmatlar taxminan bir xil miqdordagi ko'rsatkichlarni yuboradi va infratuzilma nisbatan sekin o'zgaradi.
Ma'lumot so'rovlari turli manbalardan kelib chiqishi mumkin. Ulardan ba'zilari, masalan, ogohlantirishlar ham barqaror va bashorat qilinadigan qiymatga intiladi. Boshqalar, masalan, foydalanuvchi so'rovlari, portlashlarga olib kelishi mumkin, garchi bu ko'pchilik ish yuklari uchun bunday bo'lmasa.
Yuklash sinovi
Sinov paytida men ma'lumotlarni to'plash qobiliyatiga e'tibor qaratdim. Men ushbu skript yordamida Linode xizmatida Go 2.3.2 (PMM 1.10.1 qismi sifatida) bilan tuzilgan Prometheus 1.14 ni joylashtirdim: . Buni ishlatib, eng real yuk yaratish uchun Men haqiqiy yuklangan bir nechta MySQL tugunlarini ishga tushirdim (Sysbench TPC-C testi), ularning har biri 10 ta Linux/MySQL tuguniga taqlid qilgan.
Quyidagi testlarning barchasi sakkizta virtual yadroli va 32 Gb xotiraga ega Linode serverida ikki yuzta MySQL misolini kuzatuvchi 20 ta yuk simulyatsiyasi bilan bajarildi. Yoki Prometey nuqtai nazaridan, 800 ta nishon, sekundiga 440 ta qirqish, sekundiga 380 ming yozuv va 1,7 million faol vaqt seriyasi.
dizayn
An'anaviy ma'lumotlar bazalarining odatiy yondashuvi, shu jumladan Prometey 1.x tomonidan qo'llaniladigan . Agar yukni ko'tarish uchun etarli bo'lmasa, siz yuqori kechikishlarni boshdan kechirasiz va ba'zi so'rovlar bajarilmaydi. Prometey 2-da xotiradan foydalanish kalit orqali sozlanishi mumkin storage.tsdb.min-block-duration, bu diskka o'tkazishdan oldin yozuvlar qancha vaqt xotirada saqlanishini belgilaydi (standart - 2 soat). Kerakli xotira miqdori aniq kiruvchi oqimga qo'shilgan vaqt seriyalari, teglar va qirqishlar soniga bog'liq bo'ladi. Disk maydoni nuqtai nazaridan Prometey har bir yozuv (namuna) uchun 3 baytdan foydalanishni maqsad qilgan. Boshqa tomondan, xotira talablari ancha yuqori.
Blok o'lchamini sozlash mumkin bo'lsa-da, uni qo'lda sozlash tavsiya etilmaydi, shuning uchun siz Prometeyga ish yukingiz uchun qancha xotira kerak bo'lsa, shuncha ko'p xotira berishga majbur bo'lasiz.
Agar kiruvchi o'lchovlar oqimini qo'llab-quvvatlash uchun etarli xotira bo'lmasa, Prometey xotiradan tushib qoladi yoki OOM qotili unga etib boradi.
Prometey xotirasi tugashi bilan ishdan chiqishni kechiktirish uchun almashtirishni qo'shish haqiqatan ham yordam bermaydi, chunki bu funksiyadan foydalanish portlovchi xotira sarfiga olib keladi. Menimcha, bu Go bilan, uning axlat yig'uvchisi va almashtirish bilan bog'liq.
Yana bir qiziqarli yondashuv - bu jarayonning boshidan hisoblash o'rniga, bosh blokni diskka ma'lum bir vaqtda yuvish uchun sozlashdir.
Grafikdan ko'rinib turibdiki, diskni tozalash har ikki soatda sodir bo'ladi. Agar siz min-blok davomiyligi parametrini bir soatga o'zgartirsangiz, bu qayta o'rnatishlar yarim soatdan keyin har soatda sodir bo'ladi.
Agar siz Prometey o'rnatishingizda ushbu va boshqa grafiklardan foydalanmoqchi bo'lsangiz, undan foydalanishingiz mumkin . U PMM uchun mo'ljallangan, ammo kichik o'zgarishlar bilan har qanday Prometey o'rnatilishiga mos keladi.
Bizda xotirada saqlanadigan bosh blok deb ataladigan faol blok mavjud; eski ma'lumotlarga ega bloklar orqali mavjud mmap(). Bu keshni alohida sozlash zaruratini yo'q qiladi, lekin agar siz bosh blok sig'adiganidan eskiroq ma'lumotlarni so'rashni istasangiz, operatsion tizim keshi uchun etarli joy qoldirishingiz kerakligini anglatadi.
Bu, shuningdek, Prometey virtual xotirasi iste'moli ancha yuqori ko'rinishini anglatadi, bu tashvishlanadigan narsa emas.
Yana bir qiziqarli dizayn nuqtasi - WAL (oldindan yozish jurnali) dan foydalanish. Saqlash hujjatlaridan ko'rinib turibdiki, Prometey halokatlarning oldini olish uchun WAL dan foydalanadi. Ma'lumotlarning omon qolishini kafolatlashning o'ziga xos mexanizmlari, afsuski, yaxshi hujjatlashtirilmagan. Prometheus versiyasi 2.3.2 har 10 soniyada WAL-ni diskka o'tkazadi va bu parametr foydalanuvchi tomonidan sozlanmaydi.
Siqilishlar
Prometheus TSDB LSM (Log Structured Merge) do'koni kabi ishlab chiqilgan: bosh blok vaqti-vaqti bilan diskka yuviladi, siqish mexanizmi esa so'rovlar paytida juda ko'p bloklarni skanerlashni oldini olish uchun bir nechta bloklarni birlashtiradi. Bu erda siz bir kunlik yukdan keyin test tizimida kuzatgan bloklar sonini ko'rishingiz mumkin.
Agar siz do'kon haqida ko'proq bilmoqchi bo'lsangiz, meta.json faylini ko'rishingiz mumkin, unda mavjud bloklar va ular qanday paydo bo'lganligi haqida ma'lumot mavjud.
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}Prometeydagi siqilishlar bosh blokning diskka yuvilgan vaqtiga bog'liq. Ayni paytda bir nechta bunday operatsiyalarni bajarish mumkin.
Ko'rinib turibdiki, siqilishlar hech qanday tarzda cheklanmagan va bajarish paytida katta diskdagi kirish/chiqarish tezligini keltirib chiqarishi mumkin.
CPU yukining keskin ko'tarilishi
Albatta, bu tizim tezligiga juda salbiy ta'sir ko'rsatadi va LSM xotirasi uchun jiddiy muammo tug'diradi: ortiqcha xarajatlarsiz yuqori so'rov stavkalarini qo'llab-quvvatlash uchun siqishni qanday qilish kerak?
Siqilish jarayonida xotiradan foydalanish ham juda qiziqarli ko'rinadi.
Siqilgandan so'ng, xotiraning ko'p qismi "Keshlangan" holatidan "Bepul" holatiga qanday o'zgarishini ko'rishimiz mumkin: bu potentsial qimmatli ma'lumotlar u erdan o'chirilganligini anglatadi. Bu yerda ishlatilganmi, qiziq fadvice() yoki boshqa minimallashtirish texnikasi yoki bu kesh siqilish paytida vayron qilingan bloklardan ozod qilinganligi uchunmi?
Muvaffaqiyatsizlikdan keyin tiklanish
Muvaffaqiyatsizliklardan tiklanish vaqt talab etadi va yaxshi sabablarga ko'ra. Bir soniyada million yozuvlar oqimi uchun SSD drayverini hisobga olgan holda tiklash amalga oshirilganda taxminan 25 daqiqa kutishim kerak edi.
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."Qayta tiklash jarayonining asosiy muammosi yuqori xotira iste'molidir. Oddiy holatda server bir xil hajmdagi xotira bilan barqaror ishlashi mumkinligiga qaramay, agar u ishlamay qolsa, OOM tufayli tiklanmasligi mumkin. Men topgan yagona yechim ma'lumotlar yig'ishni o'chirish, serverni ishga tushirish, uni qayta tiklash va yig'ish yoqilgan holda qayta ishga tushirish edi.
Isitish
Isitish paytida yodda tutish kerak bo'lgan yana bir xatti-harakat - bu boshlang'ichdan so'ng past ishlash va yuqori resurslar iste'moli o'rtasidagi bog'liqlik. Ba'zi, lekin hammasi emas, men protsessor va xotirada jiddiy yukni kuzatdim.
Xotiradan foydalanishdagi bo'shliqlar Prometey boshidanoq barcha to'plamlarni sozlay olmasligini ko'rsatadi va ba'zi ma'lumotlar yo'qoladi.
Yuqori protsessor va xotira yukining aniq sabablarini tushunmadim. Menimcha, bu yuqori chastotali bosh blokda yangi vaqt seriyalarini yaratish bilan bog'liq.
CPU yukining ko'tarilishi
Etarlicha yuqori I/U yukini yaratadigan siqilishlarga qo'shimcha ravishda, men har ikki daqiqada protsessor yukida jiddiy o'sishni payqadim. Kirish oqimi yuqori bo'lsa, portlashlar uzoqroq bo'ladi va Go'ning axlat yig'uvchisidan kelib chiqqan ko'rinadi, hech bo'lmaganda ba'zi yadrolar to'liq yuklangan.
Bu sakrashlar unchalik ahamiyatsiz emas. Ko'rinib turibdiki, ular sodir bo'lganda, Prometeyning ichki kirish nuqtasi va ko'rsatkichlari mavjud bo'lmay qoladi, bu esa xuddi shu vaqt oralig'ida ma'lumotlar bo'shliqlarini keltirib chiqaradi.
Bundan tashqari, Prometey eksportchisi bir soniya davomida yopilganini ham sezishingiz mumkin.
Biz axlat yig'ish (GC) bilan bog'liqlikni ko'rishimiz mumkin.
xulosa
Prometheus 2-dagi TSDB tez, millionlab vaqt seriyalarini va bir vaqtning o'zida juda oddiy uskunadan foydalangan holda soniyada minglab yozuvlarni boshqarishga qodir. CPU va disk kiritish-chiqarishdan foydalanish ham ta'sirli. Mening misolim ishlatiladigan yadro uchun soniyada 200 000 ko'rsatkichni ko'rsatdi.
Kengayishni rejalashtirish uchun siz etarli xotira miqdori haqida eslab qolishingiz kerak va bu haqiqiy xotira bo'lishi kerak. Men kuzatgan xotira miqdori kiruvchi oqimning sekundiga 5 100 ta yozuv uchun taxminan 000 Gbni tashkil etdi, bu esa operatsion tizim keshi bilan birgalikda taxminan 8 Gb band xotirani beradi.
Albatta, protsessor va disk kiritish-chiqarish tezligini yumshatish uchun hali ko'p ish qilish kerak va bu TSDB Prometheus 2 ni InnoDB, TokuDB, RocksDB, WiredTiger bilan solishtirganda, bu ajablanarli emas, ammo ularning barchasi o'xshash edi. hayot tsiklining boshida muammolar.
Manba: www.habr.com