Solaris

Hi gurus,
Please advice me in case such a process is taking too much of memory what are the necessary steps we need to do. Please explain with detailed.

Thanks | P.Bharathiraja

You mean too much VM, or too much RAM? What is your symptom?

If a locally written program, mistakes like not free()ing dynamically allocated space before the pointer variable is lost or reloaded (memory leaks) are a common culprit. What flies in JAVA/C# is very bad in C/C++.

Mistakes in declarations can also hurt (arrays larger than needed), and bad tactics can require much memory (sorting big files in memory, for instance, or using DOM not SAX to parse XML.

Usng mmap() can use more RAM and less swap, which can be a problem or solution.

Dear DGPickett,
Thank you for your valuable letters. I just want to know (any case... VM, or too much RAM). What are the steps we need to do... which are the place we need to look... as i am newbie plz apologies in case it is stupid Q.....

Thanks | P.Bharathiraja.

Well, leaks mean that programs use an increasing amount of swap, show a larger vm size on ps and may eventually bomb. Every malloc()/calloc()/realloc()/new must be to a pointer not overwritten or out of scope before a corresponding free()/delete, except if you exit(). If a subroutine returns a new object or dynamically allocated space, the caller may inherit the obligation to delete or free() when out of use, if not exit(). You may be calling other people's libraries that put this obligation on you.

Declaring excess or VM intensive choices is a more subtle, architectural problem.

The mmap()/mmap64() facilities are unique, allowing you to map files (or swap or copy to swap on write) creating memory spaces you can just reference for accessing values or to write (persistent) variable values, no read or write, just =, memcpy() and such. If you write a file and mmap() the file, not malloc and fill an array, you are still using as much RAM, and address space, but no swap space to provide rollout space for the array (sometimes, swap allocation is delayed until first rollout). If you run out of address space, you can munmap() some old space and mmap() a new chunk, so you have infinite VM (and potential RAM use) in just a 32 bit app. You can even do huge sparse arrays with seek, write -- ufs will not allocate blocks for null spaces never written, and mmap64() the whole sparse array. I wrote a fgrep that used open(), mmap(), string search, munmap(), close(). When testing, I did a search of every file, and rolled every app on the system out as I paged in files totaling more than the system RAM size, temporarily freezing every other application and user. Even after you close and munmap(), the file is available in RAM for the next mmap(), until it ages out. This is great for /lib/libc.so or moving your windows into files around, but not so great for private files in huge numbers.

What, exactly, is your concern?