Thanks Paul,
        I did a man on top and sure enough there was a PPID command on
Linux (f then B) for parent process.  And yes, they always have the same
parent command.  Thanks for your help as I'm obviously still a noob on
Unix.

Tom

-----Original Message-----
From: Paul Smith [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 16, 2006 3:18 PM
To: java-user@lucene.apache.org
Subject: Re: Memory

If you look at the man page for 'ps' you'll see a switch that shows  
all the threads too (it's different on different unix flavours, so  
best to do look in the man page).

Once you've shown the threads in 'ps' you'll see that the process  
that is appearing in top, and I'll bet it's parent is your original  
java process.

I wouldn't panic, each thread is almost certainly sharing the same  
memory pool, so while top reports that the thread has X Mb of memory,  
it's really the same physical block as all the others.

You see this all the time in a Tomcat app server box, where each Http  
Connector is a thread, and appears as it's own process.

cheers,

Paul Smith

On 17/01/2006, at 7:11 AM, Aigner, Thomas wrote:

>
> Hi all,
>       Is anyone experiencing possible memory problems on LINUX with
> Lucene search?  Here is our scenario, we have a service that lives on
> LINUX that takes all incoming request through a port and does the
> search.  Only 1 IndexSearcher is instantiated to do this from our
> service.  When I run a ps and grep for java it shows only 1 java  
> process
> running.. however, when 4 users log into our program and start to  
> search
> at the same time, 4 java processes show up on TOP (and I can't see  
> their
> parent PID from the top command), but still only 1 java on ps.
>       My company fears that each process is being allocated 128M
> memory and is running the box out of memory (when the service is  
> started
> we allocated 10 - 128M from the java call).  I am still in the process
> of testing with our system guys and having the data analyzed with a  
> 3rd
> party, but was curious as to your findings..
>
> Thanks ahead of time,
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to