Re: known memory leaks?

[cwolves]

Hi,

I'm seeing a similar issue. Our DB server just came down a little
while ago because dbslayer was eating 90+% of the memory. It turned
out to be initially caused by an application error, but regardless I
find dbslayer's behavior odd...

The app error was causing a MySQL query to be repeated every 60
seconds (it's part of a flushing mechanism). The query was returning
about 20MB of data from a ticketing system (people submit LARGE
tickets -- actually the cause of the app error). Anyway, dbslayer's
memory usage kept going up by 20MB every minute when the exact same
query was run, and it flat out would not go back down. I reproduced
this on my dev environment and hours later after hundreds of other
queries, the memory usage was still through the roof.

I'm wondering if anyone has any advice of how to prevent this?

Thanks,
-Mark

[dgot...@gmail.com]

Large request will result in large memory usage. DBSlayer is designed
for returning small results - less than 10k rows. - mostly in a web
based scenario. DBSlayer doesn't leak memory but like almost _all_
programs it doesn't returned the memory back to the operating system
until the program exits. It uses malloc alloc the memory but doesn't
call brk or sbrk to return memory back to the OS it calls free which
allows for the same . This is very standard behaviour across nearly
all applications.

d

[cwolves]

Yeah, it was actually only one row with 20MB of data in it. Anyway,
with a max of 10 connections, my question is why was dbslayer allowed
to chew 2GB of RAM on 20MB/connection increases?

-Mark