views:

170

answers:

2
+1  A: 

You are making an awful lot of assertions there.

And you've not said what is generating the queries / consuming the data.

While it is possible that MySQL has an undocumented memory leak - thats one problem which I have never experienced with it.

The first thing I would be doing is to look at top sorted by memory to see what's using lots of memory / whats grabbing more memory. I suspect you may find its the clients not releasing result sets correctly that may be causing the problem.

symcbean
I guess i wrote that this is a production server of a large scale web application that is generating and consuming queries. or there is something specific that my question is not clear about.Thanks.
Ishu
and I have checked its not clients.. Its always the mysql grabbing the top slot of the unix top command sorted by memory.. and the other thing that leads me to think that its not clients is that even if i restart apache to release it all what its holding, even then the server is under heavy load unless i restart mysql. That strengthens my belief that its mysql thats pissing it off....
Ishu
+2  A: 

You have your key_buffer set to 2.5Gb, right?

And this is a 32-bit system.

Are you joking?

You really, really need to use a 64-bit OS if you plan to run MySQL on a server. Otherwise, you cannot reasonably use enough ram. It is probably running out of address space, not memory. This causes problems as you've seen.

The maximum address space that a process can use in 32-bit Linux is typically around 3G. You're blowing most of that on your oversized key buffer, leaving little breathing room.

As a temporary workaround, decrease the key buffer a lot. You should definitely start monitoring the VM usage until you can migrate to 64-bit.

MarkR
hmmm... a pretty much valid point Mark.. but with my traffic around I can't really decrease the key buffer much with ISAM tables, though i have made them 1.8G for now. what do you think?Thanks.
Ishu
Traffic is not necessarily the problem - consider how large the indexes are of your tables. If your database is small, or the commonly used subset is small, the key buffer does not need to be so big. However in the longer term, moving to 64-bit sounds like a good idea.
MarkR