McGillivray, Don [IT]
Donald.A.McGillivray at sprint.com
Thu Jan 22 15:08:53 CST 2009
Thaks for responding, Jim. Well, the details I provided initially related to the experiment I did in an effort to gain some understanding of what I should expect to see while my app is running. Based on those findings, I gathered that I ought to see memory and handle usage fluctuate around some "average" values during processing, but that they ought not to grow incrementally over time. As I watch the stats on my app as it runs, I definitely see the memory and handle usage rise over time. Once I have eliminated all the likely suspects (closing all my recordsets and setting them to nothing, for example) I need to know how to isolate the source of the leak if it persists. Any suggestions? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Thursday, January 22, 2009 12:48 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Tracking down memory leak Don, <<So, now I'm more confused than when I started. How exactly does one detect memory leak, and once detected, how to find its source?>> A "memory leak" stems from a process that allocates memory for a purpose, but then doesn't give it back. From task manager, check the specific task instance and see if the memory it's using grows. If so and the app is doing the same thing over and over, then you have a leak. From what you describe below, it doesn't sound like you have a leak. It's not abnormal to see memory (and handles) grow and shrink while an app is running. Exactly what is the problem your having? Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of McGillivray, Don [IT] Sent: Thursday, January 22, 2009 1:39 PM To: Access Developers discussion and problem solving Subject: [AccessD] Tracking down memory leak Hi, All I'm looking for guidance on identifying the source of a memory leak in an application. I've already gone through my code to ensure that each "Set ObjVariable = . . . " statement is accompanied by a "Set ObjVariable = Nothing" statement. All my procedures use error handling, and are forced to exit through a substructure that contains the proc's "Set ObjVariable = Nothing" statements, ensuring that the object variables are set to nothing even when an error occurs. As the app runs, both memory usage and the handle count slowly creep up over time - the handle count faster than the memory usage. I did a simple experiment by monitoring handle usage while opening and closing a single table in a database several times. I noticed that at first the handle usage was variable, but that after several repetitions it more or less stabilized. Something like this: Rep State Handles ================================= 0 Initial 195 1 Open 203 1 Closed 199 2 Open 203 2 Closed 200 3 Open 202 3 Closed 200 4 Open 201 4 Closed 200 5 Open 210 5 Closed 204 6 Open 207 6 Closed 204 7 Open 206 7 Closed 201 8 Open 204 8 Closed 201 9 Open 204 9 Closed 201 For grins, I left the db open and idle overnight. When I checked this morning, its memory usage had gone from 20.7 MB to 3.7 MB. Upon opening the table, the usage went to 7.8 MB and stayed around there after several open/close repetitions. So, now I'm more confused than when I started. How exactly does one detect memory leak, and once detected, how to find its source? Anybody out there with nothing better to do than to educate my weak brain? Don This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.