Run away process on Linux

[Pattabhi]

Gurus,

I came across an unusual process on my Linux box, which is taking 23Gb of VIRTM, but where the hell from???? I dont have that much available even after adding up swap and RAM, so is this a bug in top or what??

ENV details

OS: RHAS 4.4 64-bit
top: procps version 3.2.3
Kernel: 2.6.9-42.ELsmp

Any advice on this is welcome

# top
top - 17:39:57 up 28 days, 11:06, 10 users, load average: 1.02, 1.47, 1.22
Tasks: 190 total, 1 running, 189 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.6% us, 1.9% sy, 0.0% ni, 97.4% id, 0.0% wa, 0.0% hi, 0.1% si
Mem: 4040812k total, 4016020k used, 24792k free, 5736k buffers
Swap: 8388600k total, 3358284k used, 5030316k free, 459056k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17004 tfernan1 16 0 23.3g 1.2g 3380 S 0 31.2 16:41.74 java
16998 tfernan1 18 0 5364 312 308 S 0 0.0 0:00.00 run.sh

[Steven E. Protter]

Shalom,

kill -9 17004

Java has a leak.

http://www.hpux.ws/?p=8

Or a Java based app.

Memory leak detector link above.

SEP

[Pattabhi]

Thanks steve,

But the question i have is there are other users running the same application and i dont see any mem leak on them, its only for this user that i the memory grow like mad.. any thoughts on this???

[Matti_Kurkela]

Virtual memory probably includes memory-mapped files. If the Java application this user is running is accessing files using the mmap() interface, the size of the file gets included in the process's virtual address space.

The process can then read the file just as if it was reading a memory area; whenever the application tries to access some part of the file that is not currently in real memory, the page fault handler of the OS will load it, and then the access operation is resumed.

The 64-bit environment allows the memory-mapping of huge files, as the address space limit is not an issue.

MK