Resil jste nekdo napojení dat z nejakeho HTTP API, ktere presentuje data v jsonu do Promethea? Pouzili jste na to nejaky exporter a jen priohnuly, nebo jste to museli nejak napsat sami?

QUIP: Tak jsem to zkusil prehodit na TIMESCALEDB ... a ten jejich timescaledb-tune je mazec ;) Kazdopadne pozoruji vyrazny rozdil. Zkusim si s tim pohrat a neco si vice nastudovat. Ale tohle mi prijde jako spravna cesta. Kleslo vytizeni stroje (bodejt by ne ;) ).

Diky vsem za reakce a rady !

TOTAL: Dej pak vedet, jak jsi s tim pochodil, ja mam Zabbix zatim jen pro testovaci ucely a protoze vic pracuju s MySQL (MariaDB), tak to mam napojene na MySQL, ale kdyz jsem cetl ty krasny veci o TimescaleDB, tak bych tomu asi taky dal sanci, protoze az do Zabbixu nahazim tech par desitek hostu, tak se to zacne taky chovat jinak, nez kdyz to ted testuju se 3 hostama. :)

QUIP: Tak jsi mel pravdu. Po dumpu a restore je velikost DB o 1,5GB mensi ... mazec. Ted jdu testovat (rozhodne to rychlejsi je). Ale vrta mi hlavou ten TIMESCALEDB ... i kdyz to je kanon na vrabce, ale uz jenom si ho zkusit ;)

Diky moc za nasmerovani.

QUIP: Uz na tom importu pracuju ;)

Co se tyce TIMESCALEDB, tak to vypada na slusny rozdil .... to jsem uplne minul ;)

RATTKIN: Diky za tip ... ;)

TOTAL: Jako uplne prvni krok zkus udelat pg_dumpall, smazat DB a ten dump zase naimportovat zpatky. Tim zajistis, ze data nebudou nijak fragmentovana atd. Problem to nijak zahadne nevyresi, ale muze ti to pomoc s analyzou, jestli je tvuj problem nejak spojeny s fragmentaci / filesystemem, nebo je problem uz celkovy objem.
Ono treba u MySQL s InnoDB tabulkama ten dump a re-load casto vyresi vetsinu problemu s rychlosti, protoze z principu InnoDB neuvolnuje stare misto po DELETEd zaznamech, takze po case ma DB na disku treba 20GB velmi fragmentovanych dat a po reloadu je to treba jen 2GB a vsechno zase rok fici jak z praku. Nevim, jak se v tomhle chova PG.

Ted jsem si jeste v rychlosti vyhledal neco o TimescalDB a vypada to, jako nejlepsi volba:
TimescaleDB vs. PostgreSQL for time-series: 20x higher inserts, 2000x faster deletes, 1.2x-14,000x faster queries
Jednodussi nez table partitions.

Zabbix, Time Series Data and TimescaleDB – Zabbix Blog
https://blog.zabbix.com/zabbix-time-series-data-and-timescaledb/6642/

4 TimescaleDB setup [Zabbix Documentation 5.2]
https://www.zabbix.com/documentation/current/manual/appendix/install/timescaledb

QUIP: Zatim smeruju, ze tu DB budu muset smazat a (data nijak nepotrebuji) a jet znovu s pozorovanim, co to dela .... na VPS jsem psal, samozrejme pisi, ze u nich neni problem, ale u me v DB, nebo sluzbe, ktera cte a zapisuje ...

RATTKIN: Nepouzival jsem nikdy. Jsou nejake vyhody proti klasickemu POSTGRESQL ? Ted se divam a v konfiguraci POSTGRESQL staci jen toto ? Ma to cenu zkouset ?

shared_preload_libraries = 'timescaledb'

Co se stane potom ? ;) Ma jiny pristup k DB ? Nikdy jsem tohle nezkousel.

TOTAL: máš tam timescale db?

TOTAL: 4GB neni nic velkeho, to je fakt. Nemam ale moc velke zkusenosti s tuningem PostgreSQL, vicp racuju s MySQL a tam je tech moznosti tuningu opravdu hodne.
NVME je hodne rychly, ale zase jestli je to nejaky sdileny stroj verejneho poskytovatele, mozna tam ostatni VM delaji takovy provoz, ze pro tvoji VM uz moc nezbyva.
Druha varianta je, ze to VM ma na hypervisoru nastavene nejake limity. On takovy O2 cloud ma treba 200 iops u zakladniho disku a to je faaakt malo. Takze zkus prozkoumat, jestli to nebrzi nejake nastaveni, jestli skutecne pro tvoji VM je tolik IOPS, kolik je potreba.

RUDOLF: To nevim, jestli ovlivnim ;) Ten stroj zapisuje cca 22hodnost za sekundu. Coz by mela byt sranda, ale asi neni kdyz ta DB takhle roste ...

QUIP: Ten stroj je VPS a ted to prohlizim a mas pravdu. Zda se, ze ma opravdu problemy se zapisem na disk (i kdyz by tam melo byt NVMe). Jen jen to dost promenlive. A to muze byt i ta DB. Housekeeper mi bezi cca 1/h. Zase tolik dat podrobne neni nutne udrzovat. Co se tycen pameti a CPU, vytizene to je cca na 50-60%.

Co se tyce POSTGRESQL, tak to byla instalace s vytvorenim strukrury a jina vetsi udrzba nebyla delana. Mam daleko vetsi instalaci na MYSQL a tam se to nedeje.

Mam vsechna data v jedne tabulce. Partitions nepouzivam, ale podivam se na to. Diky za tip ! Velikost je cca 4GB.

Diky moc za tve postrehy.

TOTAL: moje zkušenost, že za vše můžou špatně koncipovaný Query;-)

osobně se na postgres dívám, jen skrz nějakou appku, co z toho vytahá zajímavý věci.. přes psql-fu jsem se málokdy k něčemu kloudnýmu dostal..

TOTAL: "Vytizeni masiny neni nijak strasne" to znamean co? Ze mas malo zatizeny CPU, nebo malo zatizeny disky, nebo malo vyuzivanou RAM?
Jakmile zacnou trvat dlouho transakce, tak to je patrne problem se zapisama na disk. Muze to byt tim, ze disk vytezuje i neco jineho, muze to byt tim, ze disk se postupne zaplnuje a soubory na filesystemu jsou hodne fragmentovane (pokud to neni SSD ale HDD, tak je fragmentace znacne zpomalujici faktor). Muze to byt tim, ze se v tabulce vyskytuje stale vetsi pocet zaznamu a jestli se nad nima dela i nejaky update, ktery musi upravovat i index, zase to bude s casem porad pomalejsi a pomalejsi.

Mas vsechna data v jedne tabulce, nebo pouzivas partitions pro rozdelovani tabulek treba po mesici, aby ti prave nedochazelo k tomu, ze se porad zvetsuje objem aktivnich dat? Jak velka ta databaze je / kolik tam mas zaznamu?
Ale asi by bylo lepsi to resit v auditku o tuningu PostgreSQL

TBC: hele, tak v současným farmaceutickým korporátu, dostaneme přístupy do datadog a od ledna povinný agenty na všech strojích, tak dám nějakou svoji zkušenost za pár měsíců..

co se týče networkingu, tak je to u nás hell.. náš korporátní networking je do AWS zadrátovaný, zatím jsem neviděl žádný popis toho řešení, ale slyšel jsem nějaké divočiny, jak data v rámci regionu lítají občas přes oceán;-) Tak uvidím co se dozvím časem.

tady freeminar na datadog serverless, co nám teď dorazil..

Bits of Serverless | Datadog
https://www.datadoghq.com/...tm_medium=VirtualEvent&utm_campaign=VirtualEvent-202012ServerlessWeekES

Opet zdravim vespolek ! Resim ted problemy s vykonem POSTGRESQL ... v logu se pravidelne objevuje .. Zabbix server se viditelne zpomalil.

4945:20201129:224118.925 slow query: 5.121216 sec, "commit;"
4928:20201129:224118.934 slow query: 3.123032 sec, "commit;"
5002:20201129:224119.442 slow query: 16.384187 sec, "update hosts set lastaccess=1606686063 where hostid=10270;

To je znamka toho, ze DB ma docela problemy. Vytizeni masiny neni nijak strasne. Snazil jsem se zvetsovat cache (jak v ZABBIXU, tak i v POSTGRESQL) a ladit, ale pomohlo na par dni. Nejake tipy a triky ? Diky moc za pripadne reakce.

TBC: já jsem onpremise nepotřeboval.. provozní zkušenost nemám, jel jsem několik produktů v trial.. tehdy jsem koukal, jak to vidí do kontejnerů.. ale máme zaplacený new relic, ten je taky drahej ale ten app monitoring s info o DB používáme na debugging úspěšně.

RUDOLF: mas s tim nejakou provozni zkusenost? jinak mi prijde ze to nenabizi onpremise reseni v rozashle velke interni siti nebo ano?

mít peníze tak data dog..

je to uz olddkool ;) v kazdy lokaci mame collector, co sbira metriku, threshholds, logy, authlogy....., atd, prezvejka a vysledek vybleje kazdou minutu do centralniho node, ten neni na nicem postaveny, normalne php/mysql. ELK tu mame jen na delani veselych grafu pro vedeni a navstevy

CHOROBA: vlastni system, ze ho mate napsany, na jake technologii? tech stack jak pise
SAMGARR: bych bral prave neco jako jako vlasnti reseni, par virtualu na elk uz se na to najde. no hotovy reseni jsou molochy typu IBM Netcool apod.