Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 11 to 20 of 20 total |
Out of Memory issues with DBSRVR |
Tue, Jun 6 2006 12:27 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Paul,
<< Although another problem has now presented itself, we have now had 3 sites saying that after awhile of use the DBSRVR will stop and deny any more new connections. When this happens the message "Cannot open or create log file C:\Path\to\logfile\DBSRVR.log for database server." which is then shortly followed by an Access Violation in DBSRVR. >> Have you verified that there aren't any resource issues involved here also ? The only reason the server wouldn't be able to create or open the log files are: 1) User rights 2) System resources are too low (either memory or disk space). << I can send you these 2 log files if that helps? >> It never hurts - please send them to timyoung@elevatesoft.com -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Jun 6 2006 7:30 PM | Permanent Link |
"Ralf Mimoun" | Paul Candido wrote:
> Hi Tim, > > You were right a bit of eyeball over the code turned up that one of > the queries I was using in my loop didn't have a close before free > which was causing the memory to build. Freeing a query should also close it. Or am I wrong here? Ralf |
Tue, Jun 6 2006 9:35 PM | Permanent Link |
Paul Candido | Hi Tim,
<< Have you verified that there aren't any resource issues involved here also ? The only reason the server wouldn't be able to create or open the log files are: 1) User rights 2) System resources are too low (either memory or disk space). >> I don't think it's User rights, as it has always been working with all these sites before the service upgrade. Disk space on one of the drives was 135gb free, and when it crashed at one of the other schools the DBSRVR was using ~150mb of memory out of 2gb of physical memory and 3gb of virtual memory. We have had more reports from other sites today that the service isn't accepting any new connections until they restart the service. Once the server decides it doesn't want to accept any more sessions, it seems to me that people in the system can still use it (this is unconfirmed). I will try today restoring the older service we were using previous to << It never hurts - please send them to timyoung@elevatesoft.com >> Sent. Hi Ralf, << Freeing a query should also close it. Or am I wrong here? >> I don't know if it should or not but this was the case with me, before i put the close in the code the memory would just build with every loop, now it just stays steady. Thanks, - Paul |
Tue, Jun 6 2006 10:43 PM | Permanent Link |
Paul Candido | Just got some feed back from some of our sites, it seems as if the dbsrvr is having
troubles freeing memory associated with a session. When a session is removed shouldn't it free all memory allocated to that session? or maybe this error stopping it from doing that? -> [ERROR] Internal error removing session [Access violation at address 7C8396D0 in module 'ntdll.dll'. Read of address 502D3AE5] [Client Version: 0.00 User Name: HD Address: 10.12.25.239 Encrypted: No Thread: 5036 Session: 44701704] |
Wed, Jun 7 2006 4:36 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ralf,
<< Freeing a query should also close it. Or am I wrong here? >> You are right - I missed that. A Free instead of a Close/Free makes no difference at all. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jun 7 2006 4:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Paul,
<< We have had more reports from other sites today that the service isn't accepting any new connections until they restart the service. Once the server decides it doesn't want to accept any more sessions, it seems to me that people in the system can still use it (this is unconfirmed). I will try today restoring the older service we were using previous to >> I doubt if that will make any difference - 4.22 and 4.24 are pretty much the same thing except for 4.24 has bug fixes that 4.22 doesn't. You can give it a shot, I just wouldn't hold my breath. As for the issue - I looked at the server logs that you sent, and the logs are showing an external exception and then exceptions in ntdll.dll. There is no originating exception in the database server in terms of an AV, etc. Now, it is certainly possible that an external exception could happen due to an error in DBISAM, but it is extremely rare to not see an actual AV in DBISAM first. This indicates something pretty severe. Are you using multiple threads in your client application(s) that are accessing the DBISAM database server ? Also, the first log that you sent shows only one client connecting and disconnecting a few times, both as a normal user and an admin, before the external exception occurs during the logout. The whole series of connects/disconnects only spans about 2 minutes. What is your application doing in terms of administrative access when connecting as the administrator ? -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jun 8 2006 2:34 AM | Permanent Link |
Paul Candido | Tim,
Ok, I've been doing some testing. All I need to do is login to our program and then just exit. And we get the error when removing the session in DBSRVR. << I doubt if that will make any difference - 4.22 and 4.24 are pretty much the same thing except for 4.24 has bug fixes that 4.22 doesn't. You can give it a shot, I just wouldn't hold my breath. >> I downgraded my components on our program to 4.22 b5 and ran the 4.24 b1 dbsrvr, Login, exited. I no longer receive the error when removing the session. << Are you using multiple threads in your client application(s) that are accessing the DBISAM database server ? >> Nope << Also, the first log that you sent shows only one client connecting and disconnecting a few times, both as a normal user and an admin, before the external exception occurs during the logout. The whole series of connects/disconnects only spans about 2 minutes. What is your application doing in terms of administrative access when connecting as the administrator ? >> I don't know why this log had so many Logout's i cannot replicate this, all our program does is Login as a generic user to gather the username. As soon as the user has a successful login, the session disconnects and then connects as their DB Username. The admin logins you see in that log is the Tech at the site logging into svradmin to check the log/statistics. I have no idea what we are doing different to everyone else using this version, but something has changed between 4.22 b5 and 4.24 b1 in regards to clearing the sessions. Is there any problem with running 4.22b5 components on a 4.24b1 dbsrvr? Thanks, - Paul |
Thu, Jun 8 2006 10:18 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Paul,
<< Ok, I've been doing some testing. All I need to do is login to our program and then just exit. And we get the error when removing the session in DBSRVR. >> Can you send me something that replicates this ? I would really appreciate it. Or, at the very least, give me a run-down of the operations that are occurring after the login. << I have no idea what we are doing different to everyone else using this version, but something has changed between 4.22 b5 and 4.24 b1 in regards to clearing the sessions. >> Not that I'm aware of. The only fixes are those listed here: http://www.elevatesoft.com/scripts/incident.dll?action=list However, that doesn't mean the something couldn't have been inadvertently broken. We do extensive regression testing of every release, but if it wasn't an issue before then it may not have been caught. << Is there any problem with running 4.22b5 components on a 4.24b1 dbsrvr? >> Wait, so you're saying that the problem is related to using the 4.24B1 *client-side* components, and not the database server ? IOW, if you keep the database server at 4.24B1 and change the client components to 4.22B5, the problem goes away ? -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Jun 8 2006 11:58 AM | Permanent Link |
Paul Candido | Tim,
<< Can you send me something that replicates this ? I would really appreciate it. Or, at the very least, give me a run-down of the operations that are occurring after the login. >> I'll work on trying to replicate this for you with some sample code tommorow. << Wait, so you're saying that the problem is related to using the 4.24B1 *client-side* components, and not the database server ? IOW, if you keep the database server at 4.24B1 and change the client components to 4.22B5, the problem goes away ? >> Correct, I found this a bit odd myself. No changes to code, just downgraded component and the error went away. I hope this helps you with locating the problem, be it my end or yours. Thanks for your help again, - Paul |
Thu, Jun 8 2006 5:08 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Paul,
<< I'll work on trying to replicate this for you with some sample code tommorow. >> Thank you. << Correct, I found this a bit odd myself. No changes to code, just downgraded component and the error went away. I hope this helps you with locating the problem, be it my end or yours. >> I'll try things out and see what I can find. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 14, 2024 at 07:14 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |