[ Doktor Hlad @ 01.11.2018. 12:54 ] @
Na jednom malom serveru (1 GB RAM) imam MySQL v8 i neki Python servis. Sve radi na Ubuntu server 18.04.

Python servis inace napravi konekciju ka MySQL-u i svakih par sekundi poziva odredjenu stored proceduru koja mu vrati natrag informaciju da li ima sta da radi ili nema. Ako ima sta da radi onda python nesto uradi i rezultate upise natrag u bazu. Nista preterano zahtevno a baza nema vise od par megabajta. Sve funkcionise besprekorno osim sto MySQL vremenom zauzima sve vise i vise RAM-a pa tako kada pokrenem Python servis MySQL zauzima oko 380MB RAM-a a posle 15 dana zauzima preko 800MB i onda na kraju zauzme sav slobodan RAM tako da Python servis pocne da stuca jer nema vise raspolozive memorije za njegov rad.

Ako iskljucim Python servis RAM koji MySQL zauzima se ne smanjuje. Jedino sto pomaze je da restartujem MySQL.

E sad, pokusao sam da googlam ali je toliko razlicitih informacija naokolo na temu na sta sve MySQL moze da trosi RAM da sam se potpuno izgubio i uopste nemam pojma gde da gledam. Ima li neko ovde ideju sta bih mogao da proverim i koje podesavanje da promenim kako bi trosio manje RAM-a?
[ Branimir Maksimovic @ 01.11.2018. 13:06 ] @
To je normalno kod fragmentacije memorije. Ne samo mysql nego generalno svi procesi alociranjem i dealociranjem prave fragmentaciju memorije
sto se ispoljava sve vecim zauzecem. Mozda pomogne ako promenis alokator ali fragmentacija je neminovnost.
[ Doktor Hlad @ 01.11.2018. 13:23 ] @
Nisam bas najbolje razumeo sta bih trebalo da uradim?

I kako to mislis da je to normalno? Pa do koliko on moze da zauzima RAM? Nije problem da se taj server poveca na 2 ili vise GB ali ne shvatam do koje velicine on moze da zauzima RAM?

Ranije sam za vrlo slicnu stvar koristio 5.x verzije i nikad nije bilo ovakvih problema. Radio godinama i nikad nije zauzeo mnogo RAM-a a isto se vrteo na 1GB. Sada zbog nekih regexp funkcija moram da koristim 8.0 jer u starijim verzijama toga nema.
[ Branimir Maksimovic @ 01.11.2018. 13:46 ] @
Ne mozes nista da uradis. Jednostavno ta nova verzija pravi drugacije alokacijske paterne i pravi vecu fragmentaciju. To eventualno zauzme
ceo RAM i predje u swap...
Zapravo mozes da restartujes proces, stavi skriptu koja ce to da radi u crontab.
[ bogdan.kecman @ 01.11.2018. 15:46 ] @
to mozes da teras na 5.6 ako sam dobro skontao sta radis, vrati se na
5.6 ... 8 je super ali ima par memory bagova koji su posebno izrazeni na
malim instlacijama..
[ Doktor Hlad @ 01.11.2018. 17:38 ] @
Ne mogu na 5.6 jer su search_regexp funkcije moguce tek od 8.0.
[ bogdan.kecman @ 01.11.2018. 20:04 ] @
jbg onda si u problemu ... ima par memory leak bagova koji su
verifikovani ... nadam se da ce u .14 ili .15 biti opravljeni za sada
nema resenje :( .. ima cak i par koji nisu verifikovani, ja nisam uspeo
da ih potvrdim ali ljudima se desavaju, ne bez razloga...
[ Doktor Hlad @ 01.11.2018. 20:15 ] @
Pazi, meni je najbitnije da ustanovim da li je do mene ili nije :) Jer, ako nije do mene onda da trazim drugo resenje (MariaDB?) ili nekako da resim taj regexp na drugi nacin.

Ali ako jeste do mene onda ne bih da jurim druga resenja nego da popravim sta ne valja. Npr, evo gledam InnoDB buffer je bio iskoriscen 18% kada sam pokrenuo python servis i malo po malo se povecava... Ne znam da li to moze da ima veze i da li bi smanjivanje pomoglo ali praticu narednih dana pa cu da vidim.
[ bogdan.kecman @ 01.11.2018. 21:02 ] @
marija ima isto mem leakova koliko oces nece te spasiti ..

za pocetak zapusi mu config (default config na osmici uzima mnogo vise
od 1G rama) to ti mozda resi problem dok ne dodju fixevi
[ Doktor Hlad @ 01.11.2018. 22:00 ] @
Pa ocu ja ali pojma nemam sta treba da promenim :(
[ bogdan.kecman @ 01.11.2018. 22:11 ] @
pa baci ovde sadasnji config pa ce ti pomognemo :D
[ Doktor Hlad @ 01.11.2018. 22:20 ] @
Ne znam ni gde je config :( Vise nije u fajlovima kao sto je bilo u ranijim verzijama nego u negde u information_schema ili sta vec... sta tacno treba da izvucem?
[ bogdan.kecman @ 01.11.2018. 22:30 ] @
sta ti pise u /etc/my.cnf koji je os uopste u pitanju?
[ Doktor Hlad @ 02.11.2018. 07:45 ] @
ubuntu 18.04

/etc/my.cnf ne postoji a u /etc/mysql/my.cnf osim uvodnog komentara ima samo ovo:

Code:
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/


U prvom direktorijumu /etc/mysql/conf.d/ ima samo jedan fajl: mysql.cnf i osim uvodnog komentara ima samo:

Code:
[mysql]


Drugi direktorijum /etc/mysql/mysql.conf.d/ ima dva fajla:

default-auth-override.cnf:

Code:
# This file is automatically generated by MySQL Maintainer Scripts
[mysqld]
default-authentication-plugin = mysql_native_password


mysqld.cnf:

Code:
[mysqld]
pid-file    = /var/run/mysqld/mysqld.pid
socket        = /var/run/mysqld/mysqld.sock
datadir        = /var/lib/mysql
log-error    = /var/log/mysql/error.log


I to je to...
[ Miroslav Jeftić @ 02.11.2018. 11:41 ] @
Glupo pitanje, ali jel ne možeš da staviš više rama na tom serveru? Nego da sve menjaš i/ili prelaziš na nešto treće?
[ Doktor Hlad @ 02.11.2018. 12:01 ] @
Citat:
Miroslav Jeftić: Glupo pitanje, ali jel ne možeš da staviš više rama na tom serveru? :) Nego da sve menjaš i/ili prelaziš na nešto treće?


A koliko da stavim? :)

Nije problem ako znam da ce rast RAM-a da se zaustavi na nekom broju onda bih to uradio ali ako ce RAM da raste u nedogled onda moram da saznam zasto se to desava a ne da resavam problem povecavanjem memorije.

Kao sto rekoh vec ranije cela stvar je radila vrlo slican posao sa verzijom 5.x i to jako dugo bez ikakvih problema. I to nisam ni znao koliko tada memorije upotrebljava niti me je interesovalo bas zato sto nikad nije pravio probleme :)

Ukljucio sam mu sada swap i podesio na 2GB pa cu da posmatram sta se desava.
[ Miroslav Jeftić @ 02.11.2018. 12:19 ] @
Ne znam kakav je tačno server u pitanju i koju memoriju koristi, da li je običan PC u pitanju ili neka teška egzotika - ako je običan PC već bih stavio bar 8 GB bez razmišljanja.
[ Doktor Hlad @ 02.11.2018. 13:00 ] @
Imam jednog kolegu ovde koji je na test okruzenju imao neki program koji je procesirao neke podatke. I u jednom momentu coveku zafali RAM-a i umesto da mu padne na pamet da proveri sta ne valja u njegovom programu on je isto tako "bez razmisljanja" odlucio da je bolje da poveca ram (na nasu zalost imao je pristup hypervisor konzoli).

Jednog dana dolazi novi kolega koji treba da se bavi infrastrukturom i posle par dana pita nas: "Ljudi, a za sta koristimo ovu devbox masinu koja ima 1TB rama?".

Nadam se da kapiras sta hocu da kazem :)
[ Everx @ 02.11.2018. 13:09 ] @
Jel možeš da pređeš na Postgresql?
[ bogdan.kecman @ 02.11.2018. 13:14 ] @
@miroslav, bice da je to neki VM :D

@doktor, pa znaci sve ti je na default... default vrednosti za 8 su mnooooooooooooogo vece od default vrednosti za 5.x

sto ne volem te konfige tako na turubuntu .. elem izmeni mysqld.cnf

Code:

[mysqld]
pid-file    = /var/run/mysqld/mysqld.pid
socket        = /var/run/mysqld/mysqld.sock
datadir        = /var/lib/mysql
log-error    = /var/log/mysql/error.log

#stavi neki default-time-zone, koji god ali neki stavi
default-time-zone='+02:00'

# ovo moze a ne mora zavisi dal ti treba generalno ako ti sad radi bez toga ostavi bez toga
# https://dev.mysql.com/doc/refm..._default_authentication_plugin
#default-authentication-plugin=mysql_native_password

# ovo da te ne smara sa isteklim siframa (low security ali kontam to je neki dev koji nema externe usere)
default_password_lifetime=0
validate_password.policy=0

sql_mode=""
innodb_buffer_pool_size = 128M
innodb_buffer_pool_instances = 1
innodb_log_file_size = 8M
innodb_log_files_in_group=1
innodb_log_buffer_size = 8M
#innodb_compression_level = 6

join_buffer_size = 8M
sort_buffer_size = 2M
read_rnd_buffer_size = 2M
#open_files_limit = 650000
#innodb-open-files=550000
table_open_cache=10
table_open_cache_instances=1

#bind_address = 10.0.0.1
#max-connections = 500
#skip-name-resolve

max_allowed_packet=128M


pa probaj kako ce da se ponasa
[ Doktor Hlad @ 02.11.2018. 20:48 ] @
@everx

Pojma nemam, nisam imao iskustva do sada. Morao bih da istrazim.

@bogdan

Hvala, evo podesio sam upravo pa cu da pratim narednih par dana sta se desava.
[ Everx @ 02.11.2018. 22:44 ] @
Sa Postgresom bi se gotovo sigurno rešio curenja memorije (ako je u tome problem). Ukoliko MySql ima curenje memorije verujem da će taj problem biti rešen u skorije vreme, s obzirom da je MySql najpopularniji besplatni server baza podataka. Međutim, misilm da svakako ne bi bilo loše da pogledaš i Postgresql. Ja sam davno prešao sa MySql na Postgersql zbog Full Text Search-a i otkrio sam da mi Postgresql praktično u svakom pogledu više odgovara od MySql-a. Verovatno da MySql ima nekih prednosti, ali ja ih za sada nisam otkrio, počev od dokumentacije, licence, kompatibilnosti sa SQL standardom, tipova podataka, indeksa, podrške za json, geospatial... u poslednjim verzijama je značajno unapređena i replikacija. Čini mi se da veća popularnost MySql-a posledica inercije, a ne kvaliteta. U zavisnosti od kompleksnosti projekta, prelazak na drugi sistem za upravljanje bazom podataka može da zahteva dosta posla, tako da je povratak na stariju verziju MySql-a dok se ne sredi najnovija verzija verovatno najbolja opcija (ukoliko konfiguracija koju je predložio Bogdan ne bude dala rezultate).
[ bogdan.kecman @ 03.11.2018. 02:53 ] @
@everx, ja koristim oba od kad postoje prilicno ravnopravno u svojim projektima, daleko od toga da je univerzalno jedan bolji od drugog, no gresis znacajno u postavci ... nema veze sa inercijom nego brzinom i use-case, na webu (a to je masovnost, specijalni slucajevi su nebitni ako pricamo o kolicini i popularnosti) je bitna brzina, tu je mysql uvek bio i dalje je absolutni sampion, dalje replikacija na psql-u do "juce" nije radila sto je za bilo kakav ozbiljniji HA setup nono a o resenjima poput drbd-a ne bih ovde, "podrska za kompleksne upite" (bolja podrska sql standarda, ozbiljne stored procedure pisane u vise jezika, gzilion puta bolji optimizer...) su do jaja stvar da se koriste, na zalost, masa (a opet pricamo o masi, kolicini, popularnosti, ne o 0.2% elite) svejedno ne zna da napise kompleksan upit ... a za ove jednostavne web upite koje zna mysql em radi do jaja em radi za red/dva velicine brze od psql-a .. istoriski ..

e sad, vreme prolazi, web vise nije isti kao devedesetih, zahtevi su drugaciji... mysql-ov glavni gazda je otiso (onaj sto je tvrdio da subselect i left join nikad nikom nece trebati kada je pravio mysql i koji nije dozvolio da se uposli ni jedan jedini QA inzenjer jer "testirace to raja dzaba") svojim putem a neki drugi ljudi preuzeli pa sada ako pogledas mysql ima utf8m4 podrsku koja radi brze od psql-a, ima full geospatial podrsku koja radi kao na psql-u (i dalje je mongo brzi od oba ?!?! bem li ga kako), ima podrsku za json kompletniju od psql-a (ladno mysql sada postuje veci % standarda od psql-a), ima group replikaciju (ima sitnih bagova jos da se istrebe ali je to sistem par generacija ispred onoga sto psql danas nudi), ima (najzad) cte, window.. ima najzad dobar optimizer pa moze da proguta i one uzasne upite :D .. jedino gde je psql ostao tata su stored procedure (koliko ja znam ne postoji plan da se to uskoro unapredjuje) i "array" tip (momci iz dev tima tvrde da ce daju svi otkaz ako neko zahteva da se to implementira)...

osmica je izasla "juce" jbg i ima uzasno mnogo core-changes u sebi tako da je ocekivano da ce biti stucanja, tek smo na 8.0.13 ... ono sto su trenutni problemi je 2 bug-a sa mem leak-om (bice to sigurno ispeglano uskoro, posebno sto su izgleda bagovi u nekim bildovima samo u externim bibliotekama ne u mysql-u), "cudno" ponasanje GR na azure platformi (azure ima neke cudne probleme sa network komunikacijom, u 8.0.14 je ubacen workaround da se poveca timeout da se zaobidju problemi sa azurom ali videcemo kako ce to da se pokaze u divljini) i performance hit za sve DDL operacije zbog promene data dictionary sistema... ovo zadnje je super smor nekim korisnicima (kreiranje 2500 tabela koje je trajalo 30-40sec sad moze da traje sat vremena, insert u tabelu bez provere FK traje isto kao i da se FK provera radi i slicno) i pitanje koliko ce moci da se ubrza .. (i dalje je brze nego psql :D samo je mnooogo sporije nego 5.7) .. fora je u tome sto je sada ceo data dictionary ACID compliant tako da se sve promene nad strukturom baze rade transakciski (pre 8.0 nisi mogao da rollback neki alter table na primer) i jbg kad predjes sa nontrans na transakcioni sistem za cuvanje cega god, versioning, isolation .!. palac .. mora da izgubis performanse ...

mislim da ono sto je doktora ovde zakacilo je pre default config nego ovih par memlikova koji postoje jer su default setovanja za 5.x mnoooooooooooooogo skromnija od default setovanja za 8.x (ono tipa 2 reda velicine skromnija, 4M vs 128M i slicno) ... ako ovaj config koji sam ja poslao nije dovoljno limitirao ram usage moze to jos da se kasapi :D
[ bogdan.kecman @ 03.11.2018. 03:10 ] @
@doktor, zaboravih najvaznije,
daj mu "odma"

Code:

CALL sys.ps_setup_enable_consumer('');
CALL sys.ps_setup_enable_instrument('');


da ti upali sve moguce instrumentacije za profajling

ako vidis da uzima mysql puno ram-a i krece da jede swap zabodi ovo pls pa baci sta kaze:

Code:

SELECT * FROM sys.memory_global_by_current_bytes; 

SELECT 
       SUBSTRING_INDEX(event_name,'/',2) AS code_area, 
       sys.format_bytes(SUM(current_alloc)) AS current_alloc
FROM 
       sys.x$memory_global_by_current_bytes
GROUP BY 
       SUBSTRING_INDEX(event_name,'/',2)
ORDER BY 
       SUM(current_alloc) DESC;

SELECT  
       sys.format_bytes( SUM(high_alloc) ) AS highalloc, 
       sys.format_bytes( SUM(current_alloc) ) AS currentaloc 
FROM 
       sys.x$memory_global_by_current_bytes;


da vidimo sta ti guta ram :)

[ Everx @ 03.11.2018. 17:00 ] @
@Bogdan
Prešao sam na Postgres kada je FTS radio samo sa MyISAM i bio je praktično neupotrebljiv, pa me zanima kakvo je trenutno stanje (FTS nije jedini razlog zašto nisam gledao unazad). Znam da sada i InnoDb podržava FTS, ali ne znam koliko je stvarno upotrebljiv. Da li je moguće definisati tezarius, ispell, snowball, rečnik sinonima, unnaccent (bez Spinx-a ili nečeg sličnog)?

Na primer, da li je moguće napraviti konfiguraciju koja bi omogućila da za reč Beogradski, unet ćirilicom ili latinicom, dobijem redove koji sadrže Beograd, Beograda, Beograde... i istovremeno uradim nekoliko džoina nad tabelama koje sadrže par miliona zapisa, a da vreme izvršenja upita bude reda par desetina milisekundi?

Kako stoje stvari u najnovijoj verziji u vezi sa problemom koji je izložen u ovom članku: Don’t Waste Your Time With MySQL Full-Text Search ?

Upoznat sam sa tim da su se ova dva sistema veoma približila jedan drugom po karakteristikama, ali kao što si par puta pomenuo da MySql radi brže istorijski, ja sam istorijski imao mnogo manje problema sa Postgresom. Ne mislim da je MySql loš, ali... bilo je tu (a možda i još uvek) puno nekih nelogičnih stvari.
[ bogdan.kecman @ 04.11.2018. 09:23 ] @
Citat:
Everx: @Bogdan
Prešao sam na Postgres kada je FTS radio samo sa MyISAM i bio je praktično neupotrebljiv, pa me zanima kakvo je trenutno stanje (FTS nije jedini razlog zašto nisam gledao unazad). Znam da sada i InnoDb podržava FTS, ali ne znam koliko je stvarno upotrebljiv. Da li je moguće definisati tezarius, ispell, snowball, rečnik sinonima, unnaccent (bez Spinx-a ili nečeg sličnog)?


radi sad u ibd-u bolje nego sto je onda radio u myisam-u, i dalje je solidno limitiran sistem, i dalje mnogo korisnije spojiti se sa sphinx-om

Citat:
Everx:
Na primer, da li je moguće napraviti konfiguraciju koja bi omogućila da za reč Beogradski, unet ćirilicom ili latinicom, dobijem redove koji sadrže Beograd, Beograda, Beograde... i istovremeno uradim nekoliko džoina nad tabelama koje sadrže par miliona zapisa, a da vreme izvršenja upita bude reda par desetina milisekundi?


jok, moze beograd cirilicom da nadje beograd cirilicom i beograd latinicom ali za ostalo na zalost sphinx (i dokle god sphinx radi do jaja ne verujem da ce mysql dodavati taj tip funkcionalnosti u mysql) ... mozes da napravis thes/syn tabele pa da radis join ali u zavisnosti od toga koliko su te tabele velike upit ce trajati ili ne, u svekom slucaju psql je tu i dalje mnogo bolji jer mysql tu realno kaze "koristi sphynx ako hoces advanced opcije za fts"


Citat:

Kako stoje stvari u najnovijoj verziji u vezi sa problemom koji je izložen u ovom članku: Don’t Waste Your Time With MySQL Full-Text Search ?

nikolas je "pretentious arse" ... za svaki sistem mozes da nadjes corner case koji nece raditi idealno, sve zavisi sta je cilj koji zelis da ostvaris

Citat:
Everx:
Upoznat sam sa tim da su se ova dva sistema veoma približila jedan drugom po karakteristikama, ali kao što si par puta pomenuo da MySql radi brže istorijski, ja sam istorijski imao mnogo manje problema sa Postgresom. Ne mislim da je MySql loš, ali... bilo je tu (a možda i još uvek) puno nekih nelogičnih stvari.


pa, mysql se usporio ali se priblizio (i u mnogim slucajevima preskocio) psql po tome koliki % standarda se postuje .. i to tek sa 8.x a posto je 8.x izasao "juce" ja ne savetujem jos uvek da se utrcava sa njim u produkciju tako da kapiram za jedno 6-12 meseci da moze da se pravi neki realan presek gde su
[ bogdan.kecman @ 04.11.2018. 14:19 ] @
@everx, relativno nov mozda zanimljiv clanak http://blog.dumper.io/showdown-mysql-8-vs-postgresql-10/

Deluje da ce psql morati da radi ozbiljan revamp njihogov storage engine-a jer je postao znacajno losiji od konkurencije :( (innodb je za koplje, i vise, bolji) .. (mozes o tome naci kod njih na vikiju https://wiki.postgresql.org/wiki/Future_of_storage )
[ Everx @ 04.11.2018. 21:19 ] @
Zanimljiv je članak. Sigurno je da postoje slučajevi gde je bolje koristiti MySql. Čuven je slučaj Uberovog prelaska sa Postgres na MySql. Čini mi se da je nakon toga Postgres dobio logičku replikaciju. Uglavnom, dobro je da postoji konkurencija. Iskreno, ja sisteme mogu da posmatram samo iz ugla korisnika. Verujem da je InnoDb bolji ispod haube, kao što je objašnjeno u članku, ali za sada je Postgres dovoljno dobar. Razlika između programa pisanih na C-u i programa pisanih na Pajtonu, Rubiju ili PHP-u je mnogo veća nego razlika u brzini i zauzeću resursa između Postgresa i MySqla, pa ipak veliki broj ljudi se odlučuje za ove jezike i platforme.

Što se tiče revampa storidž engdžina, mislim da će za to morati da se sačeka nešto duže.

[Ovu poruku je menjao Everx dana 04.11.2018. u 22:30 GMT+1]
[ Doktor Hlad @ 05.11.2018. 09:09 ] @
@bogdan

Proslo je par dana od kako sam primenio podesavanja koja si mi poslao i za sada deluje ok. Videcemo jos par dana kako ce da bude.
[ Everx @ 06.11.2018. 10:27 ] @
@Bogdan

Malo sam istraživao na temu alternativnih stroridž endžina za Postgres i trebalo bi da plugable API i zheap budu dostupni u verziji 12 ili 13. Meni zheap liči na InnoDb, ali kao što sam već rekao, moje poznavanje sistema ispod haube je veoma ograničeno. Zanima me tvoje mišljenje o tome.

http://amitkapila16.blogspot.com/2018/03/zheap-storage-engine-to-provide-better.html
zheap: a new storage format for PostgreSQL
https://www.slideshare.net/EnterpriseDB/postgres-vision-2018-the-promise-of-zheap

[ bogdan.kecman @ 06.11.2018. 10:40 ] @
prica se o novim SE za psql godinama, sta ce biti i kad ce biti ne znam,
kristalnu kuglu sam poslao na poliranje a u bilo kakve najave sam
prestao da verujem pre vise decenija .. kad naprave i izbace RC verziju
ja cu probam pa cu moci da komentarisem, pre toga se ne bi usudio da
prognoziram bilo sta ... posebno da prognoziram bazirano na "mi ce
napravimo nesto sto ce da proba da resi ove probleme koje smo
identifikovali da su nekima problem" .. ono sto ja citam iz ovih
dokumenata je da su oni jos u fazi "mi bi ovo da napravimo ali ..." ne
vidi se iz grafikona dal su to "ideje", "simulacija" ili su nesto
napravili pa probaju ...

innodb je generalno teoretski najbolji SE na planeti ... "teoretski"
zato sto je pravljen po teoriji, hikki je prosao celu teoriju koja
postoji i napravio teoretski idealan sistem ... e sad, svi znamo da
silver bullet ne postoji tako da .. ima tu svasta nesto, na primer
tokudb storage engine za mysql ima za neke stvari znacajno bolje
performanse od innodb-a sa tim neki fraktalnim indexima i cudima ..
https://en.wikipedia.org/wiki/TokuDB .. tako da .. ko zna sta ovi
naprave ali pricacemo o tome kad naprave :D
[ Everx @ 06.11.2018. 12:11 ] @
Nije baš da samo pričaju, pišu i kod: https://github.com/EnterpriseDB/zheap
[ bogdan.kecman @ 06.11.2018. 12:35 ] @
to je jedan od najvecih problema psql-a, ima koda koliko hoces,
milijardu feature-a koji nikad nisu izasli iz design stage-a .. samo
neka oni pisu, drzim fige da naprave nesto do jaja, al idok ne izbace RC
ne trosim vreme
[ Doktor Hlad @ 08.11.2018. 11:07 ] @
Ja samo da javim da je sve manje vise ok. RAM ide gore dole ali nije kao ranije da ide samo na gore bez zaustavljanja. Trenutno mysql proces zauzima oko 350MB RAM-a a toliko je bilo cini mi se i pre nedelju dana kada sam ga pokrenuo.
[ bogdan.kecman @ 08.11.2018. 14:01 ] @
super, znaci da nisi pogodjen memleak bug-om vec ti je samo default
config pravio problem jer je default config za 8 napravljen za malo jace
masine .. mozes da tvikujes konfig dalje ovo sto sam ti ja dao je neka
osnova

uzdravlje
[ Doktor Hlad @ 04.02.2019. 09:59 ] @
Eto me opet. Iz nekog razloga je posle odredjenog vremena problem ponovo poceo da se javlja. Dakle, da ponovim kakva je situacija:

- mali VM
- MySQL
- Python program koji se vrti u obliku servisa

i nista sem toga.

Python program na svakih par sekundi zove stored proceduru i ako mu stored procedura vrati nekakav rezultat onda taj program radi neke dodatne stvari i rezultate zapisuje u bazu. Ako mu stored procedura ne vrati nista onda ne radi nista i zove je ponovo posle par sekundi (mislim da je podeseno 5 sekundi interval).

Ono sto mislim da je bitno za napomenuti je da se od pokretanja programa uspostavlja veza sa MySQL i ta veza se koristi za sve operacije u programu i nikad se ne prekida niti se poziva nova. Cak cela klasa za komunikaciju sa MySQL je thread safe i nema pozivanja bilo cega dok se trenutna operacija sa bazom ne zavrsi. Ukoliko dodje do prekida veze pokusace ponovo da se poveze.

Sta sam primetio: sve dok je python program aktivan koriscenje RAM-a se povecava (od strane MySQL-a a ne od strane programa) i cim zaustavim program RAM se vrati na neki prethodni nivo. Onda pokrenem program ponovo i sve je u redu narednih par dana ali MySQL pocinje da zauzima sve vise i vise RAM-a. Cak i kada nema nista da se radi vec se samo poziva stored procedura i vraca prazan recordset opet se RAM povecava. Ta stored procedura pravi neke temp tabele ali ih uredno brise, radi neke joine i sta ti ja znam. Pokusao sam u programu da napravim da na svakih sat vremena prekine vezu sa MySQL i da se poveze ponovo i onda nema trosenja RAM-a ali mi je to nekako.... onako, linija manjeg otpora :) Hocu da resim problem kako treba.

Dakle, problem je izgleda samo u tome sto se za vreme izvrsavanja programa koristi jedna konekcija i nikad se ne prekida.

E sad, ima li neko hint sta bih mogao i gde da pratim kako bih ustanovio zasto se ovo desava?
[ bogdan.kecman @ 05.02.2019. 01:04 ] @
sa SYS bazom mozes da pratis zauzece rama

ako pustis ovde tu stored proceduru (mozes i meni privatno da je bacis
na mail ako nije za siru javnost) mozemo da vidimo sta je
[ Doktor Hlad @ 05.02.2019. 13:06 ] @
Citat:
bogdan.kecman: sa SYS bazom mozes da pratis zauzece rama


Moze malo detalja...?

Citat:
ako pustis ovde tu stored proceduru (mozes i meni privatno da je bacis
na mail ako nije za siru javnost) mozemo da vidimo sta je


Code:
create procedure p_start(IN in_time datetime)
BEGIN

    -- Delete temp tables
    drop table if exists for_queue;
    drop table if exists telegram_tmp;

    -- Get the ones for starting
    create temporary table for_queue
    SELECT    ID_sensor
    FROM    sensor
    where    active = 1
        AND    coalesce(next_exec, from_unixtime(0)) <= in_time;
    
    -- Set last execute time and next execute time
    update    sensor
    set        last_exec = in_time
            ,next_exec = from_unixtime(floor(unix_timestamp(date_add(in_time, INTERVAL interval_s SECOND))/interval_s)*interval_s)
    where    ID_sensor in (select ID_sensor from for_queue);
    
    -- Create jobs
    insert into job
    (
        ID_sensor
        ,time_insert
        ,ID_status
    )
    select    ID_sensor            as ID_sensor
            ,CURRENT_TIMESTAMP    as time_insert
            ,100                as ID_status
    from    for_queue;
    
    -- Delete old jobs
    delete    j
    from    job as j
    join    for_queue as q
        on    j.ID_sensor = q.ID_sensor
        and    j.ID_status in (select ID_status from job_status where is_done = 1)
        and    j.time_insert < date_add(current_timestamp(), interval -24 hour);
    
    -- Check if something running timed out
    update    job as j
    join    sensor as s
        on    j.ID_sensor = s.ID_sensor
    set        ID_status = 300
    where    j.ID_status between 200 and 299
        and    timestampdiff(second, j.time_start, current_timestamp()) >= s.timeout_s;
    
    -- Check if there is queue timeout
    update    job as j
    join    sensor as s
        on    j.ID_sensor = s.ID_sensor
    set        ID_status = 302
    where    j.ID_status between 100 and 199
        and    timestampdiff(second, j.time_insert, current_timestamp()) >= s.queue_s;
    
    -- Select jobs from queue
    drop table if exists for_start;
    SET @row_number = 0;
    create temporary table for_start
    select    t.ID_job        as ID_job
            ,t.ID_sensor    as ID_sensor
            ,s.filename        as filename
            ,s.name            as name
            ,s.timeout_s    as timeout
    from
    (
        select    j.ID_job
                ,j.ID_sensor
                ,js.is_queued
                ,(@row_number:=@row_number + 1) AS num
        from    job as j
        join    job_status as js
            on    j.ID_status = js.ID_status
            and    (
                    js.is_running = 1
                or    js.is_queued = 1
                )
        order by is_running desc
            ,time_insert asc
    ) as t
    join    sensor as s
        on    t.ID_sensor = s.ID_sensor
    where t.num <= (select max(concurrent_jobs) from job_limit)
        and    t.is_queued = 1;
    
    -- Set new job status
    update    job
    set        ID_status = 100
    where    ID_job in (select ID_job from for_start);
    
    -- Output new jobs
    select    fs.ID_job
            ,fs.ID_sensor
            ,concat(fs.filename, " ", coalesce(args.args, '')) as filename
            ,fs.name
            ,fs.timeout
    from    for_start as fs
    left join    (
                select    ID_sensor
                        ,group_concat(value order by order_id asc separator ' ') as args
                from    sensor_arg
                group by    ID_sensor
            ) as args
        on fs.ID_sensor = args.ID_sensor;
    
    -- Get Telegram messages to send
    create temporary table telegram_tmp
    select    *
    from    telegram_message
    where    ID_message_status = 1;
    
    -- Set status to queued
    update    telegram_message
    set        ID_message_status = 2
            ,time_queue = current_timestamp()
    where    ID_message in (select ID_message from telegram_tmp);
    
    -- Output messages
    select    t.ID_message
            ,t.text
            ,c.bot_api_id
            ,c.chat_id
    from    telegram_tmp as t
    cross join telegram_config as c;

END
[ bogdan.kecman @ 05.02.2019. 13:25 ] @
use sys;

select * from memory_by_thread_by_current_bytes ;

select * from memory_global_by_current_bytes;
[ bogdan.kecman @ 05.02.2019. 13:38 ] @
a za sp .. to cu pogledam kad izadjem iz guzve, danas/sutra ali imas puno "select-a" u sp-u koji ne idu nigde ... to je multiple result set na sp koji bi trebalo da uhvatis ... ako koristis neki stari konektor to bi moglo da dovete potencijalno do gomilanja ram-a na serveru za cuvanje rezultata ... e sad nemam ideju kako to ide sa pitonom sta je novo sta je staro ja to g. od jezika ne trosim ako ne moram al priupitacu kolege ima ih par koji seku vene na piton pa ce sigurno znati :D
[ Zlatni_bg @ 05.02.2019. 19:29 ] @
Je l' se adekvatno zatvara konekcija ka bazi posle queryja?
[ Doktor Hlad @ 05.02.2019. 22:41 ] @
Citat:
Zlatni_bg: Je l' se adekvatno zatvara konekcija ka bazi posle queryja?


Ne pazis na casu :) Konekcija se nikad ne zatvara i uvek se koristi ista.
[ Doktor Hlad @ 05.02.2019. 22:48 ] @
Citat:
bogdan.kecman:select * from memory_by_thread_by_current_bytes ;


Code:
mysql> select * from memory_by_thread_by_current_bytes ;
+-----------+--------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| thread_id | user                                 | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+-----------+--------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
|     45671 | root@localhost                       |             -63209 | 310.76 MiB        | -5155 bytes       | 302.15 MiB        | 5.03 TiB        |
|     61086 | root@localhost                       |               -144 | 688.85 KiB        | -4899 bytes       | 868.96 KiB        | 95.81 MiB       |
|        43 | sql/event_scheduler                  |                  3 | 16.18 KiB         | 5.39 KiB          | 16.01 KiB         | 16.18 KiB       |


wtf???
[ bogdan.kecman @ 06.02.2019. 01:35 ] @
wtf indeed ...


povuci iz x$memory_by_thread_by_current_bytes ona se ne bavi
"formatiranjem" vec su unutra samo brojevi
[ Doktor Hlad @ 06.02.2019. 17:34 ] @
Code:
mysql> select * from x$memory_by_thread_by_current_bytes;
+-----------+--------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| thread_id | user                                 | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+-----------+--------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
|     45671 | root@localhost                       |             -68746 |         331728699 |        -4825.4255 |         320947132 |   6253750306818 |
|     62541 | root@localhost                       |                 82 |           1158325 |        14125.9146 |           1055640 |        35933914 |
|        43 | sql/event_scheduler                  |                  3 |             16569 |         5523.0000 |             16391 |           16569 |
[ Doktor Hlad @ 06.02.2019. 17:39 ] @
I onda sam zaustavio servis i pokrenuo ga ponovo:

Code:
mysql> select * from memory_by_thread_by_current_bytes;
+-----------+--------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| thread_id | user                                 | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+-----------+--------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
|     62564 | root@localhost                       |                230 | 1.20 MiB          | 5.32 KiB          | 1.01 MiB          | 603.19 MiB      |
|     62563 | root@localhost                       |                 16 | 991.54 KiB        | 61.97 KiB         | 1010.66 KiB       | 142.04 MiB      |
|        43 | sql/event_scheduler                  |                  3 | 16.18 KiB         | 5.39 KiB          | 16.01 KiB         | 16.18 KiB       |


Total_allocated se povecava sumanuto brzo. Nesto tipa 10MiB/s...
[ nkrgovic @ 06.02.2019. 21:31 ] @
Jako glup predlog, ovo ce definitivno Bogdan pre da zna od mene, ali da probam: Da nije do Linux-a, tj. fragmentacije memorije ipak? Ima li smisla da proba tmalloc?
[ bogdan.kecman @ 06.02.2019. 21:48 ] @
meni mrdi da je do kreiranja i brisanja temp tabele u jednom tasku ali
nemam kad da porobam..

[Ovu poruku je menjao bogdan.kecman dana 06.02.2019. u 23:07 GMT+1]
[ Doktor Hlad @ 07.02.2019. 13:21 ] @
Citat:
bogdan.kecman: meni mrdi da je do kreiranja i brisanja temp tabele u jednom tasku ali
nemam kad da porobam..

[Ovu poruku je menjao bogdan.kecman dana 06.02.2019. u 23:07 GMT+1]


Ja imam vremena, samo kazi sta da probam?
[ bogdan.kecman @ 07.02.2019. 20:00 ] @
osakati stored proceduru , npr za pocetak samo drop pa create table from
select i to vrti u krug i vidi dal to gomila ram
posto moguce da ima neki bug oko tog create/delete jer na v8 nema vise
frm nego imamo data directory pravi transakcioni

takodje probaj taj svoj program da radis begin/commit i tako da ga vrtis
u krug da vidis dal ce da tako prestane da trosi ram
[ Doktor Hlad @ 08.02.2019. 11:19 ] @
Ok, sad cu da probam pa javim :)