What is Memory Leak and how to find it ?

[Mahesh Nayak]

Hi All,

 

Please help me to get to know , what is Memory Leak and how to find it?

--
Regards
Mahesh B T|

[Val Weissman]

You can find a good example here:

http://motevich.blogspot.com/2007/08/how-to-detect-memory-leaks-with.html

 

--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

[John Crunk]

What is your profession when your not pretending to be a performance tester

Sent from my iPhone

--

[Shalabh Dixit]

Hi Mahesh,

If you want to learn from the basic, then read the following HP
monitoring guide:

https://www.sqa.its.state.nc.us/library/pdf/HP%20LoadRunner%20Monitor%20Reference%20guide.pdf

Also Below is the info that may help you...

A memory shortage is typically due to insufficient RAM, a memory leak,
or a memory switch placed inside the boot.ini. Before I get into
memory counters, I should discuss the /3GB switch.
More memory reduces disk I/O activity and, in turn, improves
application performance. The /3GB switch was introduced in Windows NT®
as a way to provide more memory for the user-mode programs.
Windows uses a virtual address space of 4GB (independent of how much
physical RAM the system has). By default, the lower 2GB are reserved
for user-mode programs and the upper 2GB are reserved for kernel-mode
programs. With the /3GB switch, 3GB are given to user-mode processes.
This, of course, comes at the expense of the kernel memory, which will
have only 1GB of virtual address space. This can cause problems
because Pool Non-Paged Bytes, Pool Paged Bytes, Free System Page
Tables Entries, and desktop heap are all squeezed together within this
1GB space. Therefore, the /3GB switch should only be used after
thorough testing has been done in your environment.
This is a consideration if you suspect you are experiencing a memory-
related bottleneck. If the /3GB switch is not the cause of the
problems, you can use these counters for diagnosing a potential memory
bottleneck.

1. Memory\% Committed Bytes in Use This measures the ratio of
Committed Bytes to the Commit Limit—in other words, the amount of
virtual memory in use. This indicates insufficient memory if the
number is greater than 80 percent. The obvious solution for this is to
add more memory.

2. Memory\Available Mbytes This measures the amount of physical
memory, in megabytes, available for running processes. If this value
is less than 5 percent of the total physical RAM, that means there is
insufficient memory, and that can increase paging activity. To resolve
this problem, you should simply add more memory.

3. Memory\Free System Page Table Entries This indicates the number of
page table entries not currently in use by the system. If the number
is less than 5,000, there may well be a memory leak.

4. Memory\Pool Non-Paged Bytes: This measures the size, in bytes, of
the non-paged pool. This is an area of system memory for objects that
cannot be written to disk but instead must remain in physical memory
as long as they are allocated. There is a possible memory leak if the
value is greater than 175MB (or 100MB with the /3GB switch). A typical
Event ID 2019 is recorded in the system event log.

5. Memory\Pool Paged Bytes: This measures the size, in bytes, of the
paged pool. This is an area of system memory used for objects that can
be written to disk when they are not being used. There may be a memory
leak if this value is greater than 250MB (or 170MB with the /3GB
switch). A typical Event ID 2020 is recorded in the system event log.

6. Memory\Pages per Second This measures the rate at which pages are
read from or written to disk to resolve hard page faults. If the value
is greater than 1,000, as a result of excessive paging, there may be a
memory leak.

Other counters that you can use are...

- Process/Private Bytes
The Process/Private Bytes counter reports all memory that is
exclusively allocated for a process and can't be shared with other
processes on the system.

Test: If Process/Private Bytes is increasing, but # Bytes in All Heaps
remains stable, unmanaged memory is leaking.

- .NET CLR LocksAndThreads/# of current logical Threads.
The .NET CLR LocksAndThreads/# of current logical Threads counter
reports the number of logical threads in an AppDomain.

Test:
If an application's logical thread count is increasing unexpectedly,
thread stacks are leaking.

Test:
If both counters for 'logical thread count' and 'Private Bytes' are
increasing, memory in the managed heaps is building up.

- .NET CLR Memory/# Bytes in All Heaps
The .NET CLR Memory/# Bytes in All Heaps counter reports the combined
total size of the Gen0, Gen1, Gen2, and large object heaps.

Test:
By default, the stack size on modern desktop and server versions of
Windows? is 1MB. So if an application's Process/Private Bytes is
periodically jumping in 1MB increments with a corresponding increase
in .NET CLR LocksAndThreads/# of current logical Threads, a thread
stack leak is very likely the culprit.

Test:
If total memory use is increasing, but counters for 'logical thread
count' and 'Private Bytes' (measuring managed heap memory) are not
increasing, there is a leak in the unmanag

-Shalabh Dixit

[James Pulley]

http://www.mypearsonstore.com/bookstore/product.asp?isbn=0136006639&xid=PSED

http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811

 

If you incorporate the knowledge from the above then you will have few issues with the ‘what,’ the ‘why’ or the ‘where’

 

James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix

--