← Back to team overview

maria-developers team mailing list archive

Re: RFC: Pausing a query thread


hi Peter, i was helping some guys in a datacenter here in brazil and they
implement server hosting via virtual machines, in other words, they have a
very big linux cluster and many virtual machines with memory/cpu
restrictions, maybe that's the solution they give... in each virtual
machine they run a 'small server', it's a very 'expensive' solution, but
works... a cheaper one could be a per process restriction via variables
tunes / os restrictions

there's some others mysql patchs (github lauchpad others) that limit mysql
resources, but i didn't used

getting back to your idea: "SET PRIOTITY = xxxx FOR processlist.id=xxxx"
what this should do? change 'nice' value of linux pid? it can help, but i
tryed this some times and when problem is disk i/o limit it don't 'solve'
the problem, just help

i see a better solution using the MDEV-4623 that i told, and this others
MDEVs (MDEV-4615 <https://mariadb.atlassian.net/browse/MDEV-4615> -
vertical partitioning,
MDEV-3932<https://mariadb.atlassian.net/browse/MDEV-3932> -
mysql 5.6 merge) with vetical/horizontal partitioning and partition lock

with vertical/horizontal partitioning + partition lock prunes, we can
"change" a myisam table with table lock level, to a myisam table with
'partition lock' level, and implement a good partitioning that help us to
minimize the lock contention, and after we can change query cache to prune
partitions too, giving a better query cache hit rate

any other idea? maybe after this mdevs an script could 'optimize' server
'online' reading query cache queries removing some queries, reading
processlist and locking/unlocking some process and any other feature

my ideas was added in mariadb JIRA but i don't know if this solve your
problem and when someone will start development, i don't know many things
about mariadb source code, and i can't develop it (not yet =], but maybe in
future i can), if you want to vote that mdev we can have a better rank
position in JIRA and maybe someone give more priority to this and help us

any other ideas? i have the same problem for many queries, but in my case i
can change source code of some projects, others projects i just tell
developers to rewrite queries and optimize to better performace

sorry my english errors that's not my main language.

Follow ups