in reply to FD leaks while interacting with DB
I don't know how you're expecting us to help without better information. You give us the source code to a tiny script that you say doesn't give any problems, so there's no real need to look at that. You next give us a debug log from DBI for an unrelated program that obviously does more and different things. While debug logs are nice, there are no references to file opens/closes, so I don't see how it's useful to help you track down an FD leak. It's kind of like you asking "Hey, I'm trying to figure out why my hard drive got filled up by my program. Here's the source code to a totally different program, and I have an NVidia GTX970 video card. So how do I fix it?"
What I would want to see would be the source code to the app that is failing along with the DBI log. But I wouldn't want to wade through hundreds of lines of irrelevent code. So I'd suggest making a copy of your application, and then start chopping out pieces that aren't interesting, testing each version of the code to make sure that the file descriptor leak is still happening.
Frequently during this process, you'll chop out a chunk of code and the problem will go away. When this happens, take a look at what you chopped out to see what bearing it may have on the problem, alternately, you'll get a small enough program for people to look at that you can post and ask qustions about.
Anyway, when I looked at your debug log, I notice a couple things:
Since perl tries to delete things when they're no longer accessible, I'd look for places where you store database handles, statement handles, etc. Not only can you store them in a hash or array, you can also have accidental references to them with closures, so be sure to look for those, too.
When your only tool is a hammer, all problems look like your thumb.
|Replies are listed 'Best First'.|
Re^2: FD leaks while interacting with DB
by prabakar.bhatt (Initiate) on May 04, 2020 at 10:46 UTC