Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: How we use Perl.

by mpeppler (Vicar)
on Nov 08, 2004 at 07:09 UTC ( [id://405987]=note: print w/replies, xml ) Need Help??


in reply to How we use Perl.

Not to name any names, but a we have had memory allocation issues with a particular DBD package. The memory leak was slow and it only appeared when disconnecting from data sources.
I'm probably not the target of that remark, but I know that there is a leak in DBD::Sybase that is related to closing and re-opening connections. Finding and fixing these sorts of leaks can be tricky (in my case for example valgrind doesn't report the leak), and I've again spent some time trying to find it. I've discovered one possible cause that is buried in the Sybase libraries, though a Sybase engineer that I discussed this with didn't seem to think that there was a leak there - so maybe this "leak" is due to memory fragmentation.

Anyway - this may not be related to your situation, and maybe the fix for the driver you are using is comparatively simple - but I still wanted to point out that fixing memory allocation issues in things like perl isn't always simple...

Michael

Replies are listed 'Best First'.
Re^2: How we use Perl.
by osunderdog (Deacon) on Nov 08, 2004 at 15:24 UTC

    Not at all! DBI is a great package and DBD::Sybase works well. It's safe to say we wouldn't have been able to get this far without DBD::Sybase.

    Also, I know that the connect/disconnect leak is a bugger. I tried to find it myself. I'm pretty sure that it is in on the sybase api side. But Sybase isn't interested in fixing it -- probably because they are fighting to stay in business.

    I'm just trying to point out some of the pitfalls of running Perl for a long time. Test packages you intend to use over a long time and benchmark Memory consumption.


    "Look, Shiny Things!" is not a better business strategy than compatibility and reuse.


    OSUnderdog
      Actually from my testing the leak is in allocating/deallocating the CS_LOCALE structure. If you run a connect/disconnect loop written in C that doesn't allocate a CS_LOCALE struct then the memory usage is dead even for thousands of iterations. If you add the CS_LOCALE alloc/dealloc the memory grows.

      I may decide to open a tech support case on this issue to see if I can get this escalated.

      Michael

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://405987]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2024-04-19 04:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found