MySQL v 8.0 trosi RAM

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?

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.

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.

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.

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ne mogu na 5.6 jer su search_regexp funkcije moguce tek od 8.0.

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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.

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Pa ocu ja ali pojma nemam sta treba da promenim :(

pa baci ovde sadasnji config pa ce ti pomognemo :D

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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?

sta ti pise u /etc/my.cnf koji je os uopste u pitanju?

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

ubuntu 18.04

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



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



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

default-auth-override.cnf:



mysqld.cnf:



I to je to...

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.

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.

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 :)

Jel možeš da pređeš na Postgresql?

@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



pa probaj kako ce da se ponasa

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/