Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

MySQL v 8.0 trosi RAM

[es] :: MySQL :: MySQL v 8.0 trosi RAM

Strane: 1 2 3

[ Pregleda: 5050 | Odgovora: 50 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Doktor Hlad

Član broj: 337261
Poruke: 414
*.dynamic.isp.telekom.rs.



+140 Profil

icon Re: MySQL v 8.0 trosi RAM02.11.2018. u 20:48 - pre 7 meseci
@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.
 
Odgovor na temu

Everx

Član broj: 339181
Poruke: 9
*.dynamic.isp.telekom.rs.



+38 Profil

icon Re: MySQL v 8.0 trosi RAM02.11.2018. u 22:44 - pre 7 meseci
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).
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM03.11.2018. u 02:53 - pre 7 meseci
@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

 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM03.11.2018. u 03:10 - pre 7 meseci
@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 :)


 
Odgovor na temu

Everx

Član broj: 339181
Poruke: 9
*.dynamic.isp.telekom.rs.



+38 Profil

icon Re: MySQL v 8.0 trosi RAM03.11.2018. u 17:00 - pre 7 meseci
@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.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM04.11.2018. u 09:23 - pre 7 meseci
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
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM04.11.2018. u 14:19 - pre 7 meseci
@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 )

 
Odgovor na temu

Everx

Član broj: 339181
Poruke: 9
*.dynamic.isp.telekom.rs.



+38 Profil

icon Re: MySQL v 8.0 trosi RAM04.11.2018. u 21:19 - pre 7 meseci
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]
 
Odgovor na temu

Doktor Hlad

Član broj: 337261
Poruke: 414
213.162.65.*



+140 Profil

icon Re: MySQL v 8.0 trosi RAM05.11.2018. u 09:09 - pre 7 meseci
@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.
 
Odgovor na temu

Everx

Član broj: 339181
Poruke: 9
*.dynamic.isp.telekom.rs.



+38 Profil

icon Re: MySQL v 8.0 trosi RAM06.11.2018. u 10:27 - pre 7 meseci
@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

 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM06.11.2018. u 10:40 - pre 7 meseci
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
 
Odgovor na temu

Everx

Član broj: 339181
Poruke: 9
*.dynamic.isp.telekom.rs.



+38 Profil

icon Re: MySQL v 8.0 trosi RAM06.11.2018. u 12:11 - pre 7 meseci
Nije baš da samo pričaju, pišu i kod: https://github.com/EnterpriseDB/zheap
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM06.11.2018. u 12:35 - pre 7 meseci
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
 
Odgovor na temu

Doktor Hlad

Član broj: 337261
Poruke: 414
213.162.65.*



+140 Profil

icon Re: MySQL v 8.0 trosi RAM08.11.2018. u 11:07 - pre 7 meseci
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.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM08.11.2018. u 14:01 - pre 7 meseci
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
 
Odgovor na temu

Doktor Hlad

Član broj: 337261
Poruke: 414
213.162.65.*



+140 Profil

icon Re: MySQL v 8.0 trosi RAM04.02.2019. u 09:59 - pre 4 meseca
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?
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM05.02.2019. u 01:04 - pre 4 meseca
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
 
Odgovor na temu

Doktor Hlad

Član broj: 337261
Poruke: 414
213.162.65.*



+140 Profil

icon Re: MySQL v 8.0 trosi RAM05.02.2019. u 13:06 - pre 4 meseca
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
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM05.02.2019. u 13:25 - pre 4 meseca
use sys;

select * from memory_by_thread_by_current_bytes ;

select * from memory_global_by_current_bytes;
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15079
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2295 Profil

icon Re: MySQL v 8.0 trosi RAM05.02.2019. u 13:38 - pre 4 meseca
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
 
Odgovor na temu

[es] :: MySQL :: MySQL v 8.0 trosi RAM

Strane: 1 2 3

[ Pregleda: 5050 | Odgovora: 50 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.