Dotaz: Mysql problem s Procedurou

[basss]

Zdravim

Muj problem je kdyz na sever pristupuje 400 klientu zaroven k jedne procedure ktere predavaji sve unikatni cislo a nasledne procedura vykonava / select * from tabulka_unikatni_cislo / a pak provede vypocty a vrati vysledek . Procedura funguje ale pri napojena nad 150+ klientu zacina system brat neumerne moc RAM

Po zapnuti DB je hodnat na 12GB a jak je pripoji vice jak 150 klientu zaci to prudce stoupat nekdy az na maximu serveru coz je 36GB a pak zacina swapowat a to je spatne .

Cele to je postavene na Slackware 13.1 s jadrem 3.2.32 a mysql 5.5.28

Pri testech sikany serveru kdy jsem udelal 400 klientu s tim ze jsem posilal primo z klienta / select * from tabulka_unikatni_cislo / tak se pamet serveru pohla +- 0.5GB coz jsem predpokladal.

Pri testech procedury i bez vypoctu jen se / select * from tabulka_unikatni_cislo / se stava problem s pameti co jsem vyse popsal.

Nesetkal se stim nekdo v praxi ?

Predem dekuji za rady a napady (ne za tak si to vygoooogly)

Odpovědi

[VM]

Netuším co to dělá, ale nedrží to náhodou v paměti moc dat z toho "SELECT *" ?

[Kit]

Také si myslím, že chyba bude někde v návrhu, protože pokud se aplikace skládá převážně z dotazů typu "SELECT * FROM tabulka;", tak je něco špatně. Běžné dotazy obsahují selekci i projekci a často i spojování, agregaci, řazení apod.

Bez konkrétních procedur však jen vaříme z vody.

[basss]

Neresim problem v navrhu jen to ze kdyz po mysql pozaduji stejnou vec pres proceduru tak ze to zere hodne pameti a kdyz zkousim stejnou vec jako dotazy tak se to na pameti neprojevuje .

[Kit]

Pokud je možné stejnou věc řešit dotazem, nevidím důvod pro použití procedury.

[l0gik]

Hmmm, to že nevidíš neznamená, že tam není

Důvodů může být hafo, např. spouštění stejného kódu více klienty (s různým prostředím a jazykem), optimalizace (zpracovat gigabyte na serveru je řádově levnější, než poslat gygabyte na klienta a zpracovat ho tam) atd, atd...

[Kit]

"...kdyz zkousim stejnou vec jako dotazy..."

[l0gik]

A? Každé zpracování dat udělatelné na serveru jde udělat i na klientovi. Neboť klient je turingovsky úplný. To ale neznamená, že to je vždy vhodnější a z dotazu v tomto případě plyne, že v tomto případě to opravdu vhodnější není.

V každém případě se na to tazatel neptal a důvody proč řeší tak jak to řeší nesdělil (což udělal dobře, protože to s jeho otázkou nikterak nesouvisí), takže když už sem zavlékáš oftopic téma, tak by bylo slušné se nejprve na ty důvody zeptat a ne hned ho stírat, že to řeší blbě. Kdybys četl dotaz pozorně, tak ta stored procedura dělá nějakou formu agregace, která zřejmě není vykonatelná přímo SQL dotazem, což je jasný důvod pro stored proc (aby se všechna data netahala ke klientovi).

Tazatel akorát udělal minimální testcase, ve kterém zjistil, že příčina memory leaku není ta agregace, ale samotné vytažení dat pro ni a tak se ptá, jestli někdo nezná důvod, proč ty samé dotazy co z klienta jedou v poho v stored proc žerou paměť. Což je naprosto legitimní dotaz a Tvoje s odpuštěním poněkud přemoudřelý připomínky jen dokazujou, že si především snažíš honit triko, jak to umíš vyřešit líp než tazatel, a přitom ani neumíš pořádně přečíst dotaz. Neber to prosím zle, ale takovýto přístup k diskuzím vede jen k tomu, že se tu příště už nikdo nezeptá, protože místo toho, aby mu někdo (jako např. ondra) poradil, tak mu jen lidi sypou na hlavu, jak je blbej, že to napsal takhle.

[Ondra]

Zkus SELECT SQL_NO_CACHE * FROM ....

Pak se podívat na velikost bufferů a počet vláken který můžou být spuštěný.

Když to nepomůže, tak zkusit něco jako MySQL cluster... Ale bacha, je to in-memory databázový engine.