Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 14 total |
Progressive slow down 2 |
Tue, Jun 25 2013 4:27 AM | Permanent Link |
Matthew Jones | A service I am working on has had a slow but sure increase of processor time each
hour and day, and I've been working to find why. It turns out I was leaking TDBISAMSession objects. I'm posting this here so that others may have this as a suggestion, and so that I can save myself time next time I make this mistake. Executive summary: The Engine manages Sessions, and if you do not free them up, they build up forever. This causes a slowdown after a while. The key to this was that I had to change my session object management due to the multi-threaded nature of the web server application. My applications have tended to be heavily threaded, and a session per thread works fine. I adopted this for my web use too, but it ended up with a single thread doing multiple actions for many clients (thread pools) and having the session shared by everything was turning into a mess. So I re-jigged it so that each activity created and free'd its own session. Except I missed a free for one of them, an action called about once a second. But running my test harness with leak checking showed no error. I can only imagine that the slow down is due to the large number of sessions causing a general longer time to do anything. The session number is managed by TBits for example, which will run down the array for an open bit, so as more sessions are leaked, more work is needed to find that empty bit. The lack of a leak is because the Engine manages the list of sessions, and of course will free any left over at the end. To check that I don't fall over it again, I've added this check to the control thread: if Engine.SessionCount > 100 then begin LogReport(leError, '## SESSION LEAK ERROR ' + IntToStr(Engine.SessionCount)); end; This isn't a big thing, and again I'm probably unusual in the use here - it isn't normal to create and delete sessions every second. But it did fix my other issues, and once the leak is fixed, it has been rock solid again. /Matthew Jones/ |
Tue, Jun 25 2013 8:53 AM | Permanent Link |
Raul Team Elevate | Thanks for that - we've come to rely on FastMM reporting leaks (for components with nil owners) so this is definitely a small concern for us as well. I don't think we leave any sessions dangling but now i need to go and add some debug logging to check engine also just to be sure. Raul On 6/25/2013 4:27 AM, (Matthew Jones) wrote: > Executive summary: The Engine manages Sessions, and if you do not free them up, > they build up forever. This causes a slowdown after a while. |
Tue, Jun 25 2013 10:05 AM | Permanent Link |
Matthew Jones | I've never had this issue before, and I suspect most people never will. And you'd
notice it with a slow creep up in processor use over time for an otherwise idle process. It only happened because of my refactoring and thus breaking the normal object disposal pattern I'd used. Easy to check anyway - I figure no one will normally use 100 sessions, so outputting an alert if such is reached will make someone think. Also worth saying that I pondered whether anything should be added to DBISAM to warn on this, but in the many years of reliable DBISAM service I've never had need, so why now when I can spot it so easily myself, if needed. /Matthew Jones/ |
Tue, Jun 25 2013 11:56 AM | Permanent Link |
Raul Team Elevate | I would prefer this to work like other runtime created delphi objects
(meaning if i call TDBISAMSession.Create(nil) then it will leak unless i free it myself). Raul On 6/25/2013 10:05 AM, (Matthew Jones) wrote: > Also worth saying that I pondered whether anything should be added to DBISAM to > warn on this, but in the many years of reliable DBISAM service I've never had need, > so why now when I can spot it so easily myself, if needed. > > /Matthew Jones/ > |
Tue, Jun 25 2013 12:33 PM | Permanent Link |
Matthew Jones | > I would prefer this to work like other runtime created delphi
> objects (meaning if i call TDBISAMSession.Create(nil) then it will > leak unless i free it myself). It would be nice perhaps, but it would add complication to the existing stable code. The key (I presume) is that some sessions are auto-created, so it would need to manage the lifetimes of each in some way, and that then adds complexity. I'm not sure it is worth the change. /Matthew Jones/ |
Tue, Jun 25 2013 2:00 PM | Permanent Link |
Raul Team Elevate | It would be consistent which is more important IMHO. Also there should
be no impact to existing code - currently you free sessions when app exists (and engine is freed) and with leak you leak memory when app exits and can capture it if your mem manager supports it. Either way there should be no impact to runtime code other than the bug you ran into. I don't believe sessions are auto-created (other than the one default session and that should have dbisam engine or application as owner or such). Same is true for session on datamodule or form (they would have a parent). Hence the leak should only apply to sessions created with nil parent. Let's see what Tim says is possible. Raul On 6/25/2013 12:33 PM, (Matthew Jones) wrote: > It would be nice perhaps, but it would add complication to the existing stable code. > The key (I presume) is that some sessions are auto-created, so it would need to > manage the lifetimes of each in some way, and that then adds complexity. I'm not > sure it is worth the change. |
Mon, Sep 26 2016 6:43 AM | Permanent Link |
Matthew Jones | Matthew Jones wrote:
> if Engine.SessionCount > 100 then > begin > LogReport(leError, '## SESSION LEAK ERROR ' + > IntToStr(Engine.SessionCount)); > end; I'd like to thank myself for posting that back in 2013. Faced again with a leak, I searched here to find myself telling me it was really in my code, so go look harder. And I found my new leak. Well done me. 8-) -- Matthew Jones |
Mon, Sep 26 2016 1:04 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< I'd like to thank myself for posting that back in 2013. Faced again with a leak, I searched here to find myself telling me it was really in my code, so go look harder. And I found my new leak. Well done me. 8-) >> We really need to figure out a way to capitalize on all of this time travel that we've managed to accomplish recently.... Tim Young Elevate Software www.elevatesoft.com |
Tue, Sep 27 2016 4:36 AM | Permanent Link |
Matthew Jones | Tim Young [Elevate Software] wrote:
> We really need to figure out a way to capitalize on all of this time > travel that we've managed to accomplish recently.... 8-) Me, I find that I am capitalising by hitting these things again and that saves me time. I've even found StackOverflow questions that I'd asked years earlier and solved! So long as we have the internet, we won't have to repeat things quite so much. Remember when we had to learn things and look them up in books? That was an age ago. -- Matthew Jones |
Tue, Sep 27 2016 5:20 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Matthew
>. Remember when we had to >learn things and look them up in books? That was an age ago. All we should have done is replace books with the internet which simply speeds things up a bit. What seems to have happened in practice is lots of people no longer even bother trying to learn (ie internalise the knowledge and processes) or research or remember but simply ask the question again and again. Roy |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |