ТСДБ анализа у Прометеју 2

База података временских серија (ТСДБ) у Прометхеусу 2 је одличан пример инжењерског решења које нуди велика побољшања у односу на в2 складиште у Прометхеусу 1 у смислу брзине акумулације података, извршења упита и ефикасности ресурса. Имплементирали смо Прометхеус 2 у Перцона Мониторинг анд Манагемент (ПММ) и имао сам прилику да разумем перформансе Прометхеус 2 ТСДБ. У овом чланку ћу говорити о резултатима ових запажања.

Просечно радно оптерећење Прометеја

За оне који су навикли да раде са базама података опште намене, типично радно оптерећење Прометеја је прилично интересантно. Стопа акумулације података обично је стабилна: обично услуге које надгледате шаљу приближно исти број метрика, а инфраструктура се мења релативно споро.
Захтеви за информацијама могу доћи из различитих извора. Неки од њих, као што су упозорења, такође теже стабилној и предвидивој вредности. Други, као што су захтеви корисника, могу изазвати рафале, иако то није случај за већину радних оптерећења.

Тест оптерећења

Током тестирања, фокусирао сам се на способност акумулације података. Поставио сам Прометхеус 2.3.2 компајлиран са Го 1.10.1 (као део ПММ 1.14) на Линоде сервис користећи ову скрипту: СтацкСцрипт. За најреалније генерисање оптерећења, користећи ово СтацкСцрипт Покренуо сам неколико МиСКЛ чворова са стварним оптерећењем (Сисбенцх ТПЦ-Ц тест), од којих је сваки емулирао 10 Линук/МиСКЛ чворова.
Сви следећи тестови су изведени на Линоде серверу са осам виртуелних језгара и 32 ГБ меморије, уз 20 симулација оптерећења праћења две стотине МиСКЛ инстанци. Или, речено Прометејем, 800 мета, 440 гребања у секунди, 380 хиљада записа у секунди и 1,7 милиона активних временских серија.

Дизајн

Уобичајени приступ традиционалних база података, укључујући и ону коју користи Прометхеус 1.к, је да ограничење меморије. Ако то није довољно да се носи са оптерећењем, искусићете велике латенције и неки захтеви неће успети. Коришћење меморије у Прометхеус 2 се може конфигурисати помоћу кључа storage.tsdb.min-block-duration, који одређује колико дуго ће се снимци чувати у меморији пре испирања на диск (подразумевано је 2 сата). Потребна количина меморије зависиће од броја временских серија, ознака и белешки додатих нето долазном току. Што се тиче простора на диску, Прометхеус има за циљ да користи 3 бајта по запису (узорку). С друге стране, захтеви за меморијом су много већи.

Иако је могуће конфигурисати величину блока, није препоручљиво да је конфигуришете ручно, тако да сте приморани да дате Прометеју онолико меморије колико је потребно за ваше радно оптерећење.
Ако нема довољно меморије да подржи долазни ток метрика, Прометеј ће испасти из меморије или ће ООМ убица доћи до њега.
Додавање замене за одлагање пада када Прометеју понестане меморије заправо не помаже, јер коришћење ове функције изазива експлозивну потрошњу меморије. Мислим да то има везе са Го-ом, његовим сакупљачем смећа и начином на који се бави разменом.
Још један интересантан приступ је да се конфигурише главни блок да се испразни на диск у одређено време, уместо да се рачуна од почетка процеса.

Као што можете да видите на графикону, испирања на диск се дешавају свака два сата. Ако промените параметар мин-блоцк-дуратион на један сат, онда ће се ова ресетовања дешавати сваких сат времена, почевши од пола сата.
Ако желите да користите овај и друге графиконе у вашој Прометхеус инсталацији, можете користити ово Командна табла. Дизајниран је за ПММ, али се, уз мање модификације, уклапа у било коју инсталацију Прометеја.
Имамо активан блок који се зове хеад блоцк који се чува у меморији; блокови са старијим подацима доступни су преко mmap(). Ово елиминише потребу за одвојеним конфигурисањем кеша, али такође значи да морате да оставите довољно простора за кеш оперативног система ако желите да тражите податке старије од оних које главни блок може да прими.
То такође значи да ће потрошња виртуелне меморије Прометеја изгледати прилично висока, што није нешто о чему треба да бринете.

Још једна занимљива тачка дизајна је употреба ВАЛ-а (дневник писања унапред). Као што можете видети из документације за складиштење, Прометхеус користи ВАЛ да избегне падове. Специфични механизми за гарантовање преживљавања података, нажалост, нису добро документовани. Прометхеус верзија 2.3.2 испушта ВАЛ на диск сваких 10 секунди и ову опцију корисник не може конфигурисати.

Збијања

Прометхеус ТСДБ је дизајниран као ЛСМ (Лог Струцтуред Мерге) складиште: главни блок се периодично испушта на диск, док механизам за сабијање комбинује више блокова заједно како би се избегло скенирање превише блокова током упита. Овде можете видети број блокова које сам приметио на тест систему након једног дана оптерећења.

Ако желите да сазнате више о продавници, можете да прегледате датотеку мета.јсон, која садржи информације о доступним блоковима и како су настали.

{
       "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
}

Компактације у Прометеју су везане за време када се блок главе испразни на диск. У овом тренутку може се извршити неколико таквих операција.

Чини се да збијање није ограничено ни на који начин и може проузроковати велике И/О скокове на диску током извршавања.

Шикови оптерећења ЦПУ-а

Наравно, ово има прилично негативан утицај на брзину система, а такође представља озбиљан изазов за ЛСМ складиште: како извршити сабијање да би се подржале високе стопе захтева без изазивања превеликих трошкова?
Коришћење меморије у процесу сабијања такође изгледа прилично занимљиво.

Можемо видети како, након сажимања, већина меморије мења стање из кеширана у слободна: то значи да су потенцијално вредне информације одатле уклоњене. Занима ме да ли се овде користи fadvice() или нека друга техника минимизације, или је то зато што је кеш ослобођен блокова уништених током сабијања?

Опоравак након неуспеха

Опоравак од неуспеха захтева време, и то са добрим разлогом. За долазни ток од милион записа у секунди, морао сам да чекам око 25 минута док је опоравак обављен узимајући у обзир ССД диск.

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."

Главни проблем процеса опоравка је велика потрошња меморије. Упркос чињеници да у нормалној ситуацији сервер може стабилно да ради са истом количином меморије, ако се сруши, можда се неће опоравити због ООМ-а. Једино решење које сам пронашао је да онемогућим прикупљање података, покренем сервер, пустим да се опорави и поново покрене са омогућеним прикупљањем.

Загревање

Још једно понашање које треба имати на уму током загревања је однос између ниских перформанси и велике потрошње ресурса одмах након почетка. Током неких, али не свих покретања, приметио сам озбиљно оптерећење ЦПУ-а и меморије.

Недостаци у коришћењу меморије указују на то да Прометеј не може да конфигурише све колекције од почетка, а неке информације су изгубљене.
Нисам схватио тачне разлоге за велико оптерећење процесора и меморије. Претпостављам да је то због стварања нових временских серија у блоку главе са високом фреквенцијом.

Пренапон оптерећења ЦПУ-а

Поред сабијања, које стварају прилично велико И/О оптерећење, приметио сам озбиљне скокове у оптерећењу ЦПУ-а свака два минута. Рафали су дужи када је улазни проток висок и изгледа да их узрокује Го-ов сакупљач смећа, при чему су барем нека језгра потпуно напуњена.

Ови скокови нису тако безначајни. Чини се да када се то догоди, Прометејева интерна улазна тачка и метрика постају недоступни, што узрокује празнине у подацима током истих временских периода.

Такође можете приметити да се извозник Прометхеус гаси на једну секунду.

Можемо уочити корелације са сакупљањем смећа (ГЦ).

Закључак

ТСДБ у Прометеју 2 је брз, способан да рукује милионима временских серија и истовремено хиљадама записа у секунди користећи прилично скроман хардвер. Искоришћеност ЦПУ-а и диска И/О је такође импресивна. Мој пример је показао до 200 метрика у секунди по коришћеном језгру.

Да бисте планирали проширење, морате запамтити довољне количине меморије, а то мора бити стварна меморија. Количина коришћене меморије коју сам приметио била је око 5 ГБ на 100 записа у секунди долазног тока, што је заједно са кешом оперативног система дало око 000 ГБ заузете меморије.

Наравно, има још много посла да се укроти ЦПУ и диск И/О скокови, и то није изненађујуће с обзиром на то колико је млади ТСДБ Прометхеус 2 у поређењу са ИнноДБ, ТокуДБ, РоцксДБ, ВиредТигер, али сви су имали сличне проблеми у раној фази животног циклуса.

Извор: ввв.хабр.цом