|
From: Leif M. <le...@ta...> - 2003-04-03 08:30:40
|
Clement,
I also just noticed from the generated Java command line, that you
appear
to have the following two properties set in your configuration file:
wrapper.java.initmemory=256
wrapper.java.maxmemory=256
The max memory setting is fine, but is there a reason to set the
init memory
so high? The JVM will have to allocate all of that memory on start up.
This
could be part of the reason why your application is so slow on that machine.
The machine I am currently working on has 768Mb of actual memory, so I was
tried setting the above settings to 900 each. The test apps are indeed
quite
a bit slower on startup. But I was was still not seeing the problem you are
having.
How much memory does that machine have available. If you give Java more
memory than the amount of actual memory available then the OS has to start
swapping memory to make the requested memory available. In my experience
Java does not perform very well under these circumstances. Depending on the
amount of disk swapping that is required to let the JVM access its required
memory, the application can be slowed down by a couple orders of magnitude.
So can you tell me how much actual and virtual memory is available
before you
launch the JVM?
Can you also perform your test and send me the resulting log file
when the
wrapper.java.initmemory=16
Thanks,
Leif
Leif Mortenson wrote:
> Clement,
> Thanks for the log files they were very helpful. I think that the
> problem is
> most likely that the Wrapper is not getting hardly any CPU at all. I
> see cases
> where the time stamps from the JVM are outputting a hundred or so
> lines of
> output all with the exact same time stamp, but the time stamps from
> the Wrapper
> show that it is taking well over a minute to output all of them.
> Because it was
> outputting around 1 line per second, it was taking over 50 seconds to
> output 50
> lines of output from the JVM. Thus, in the severe case you are
> seeing, my fix
> did not work correctly.
>
> I made another attempt at fixing this by making the function that
> processes
> JVM output yield CPU to the event loop after 250ms rather than 50
> lines of
> output. Originally I had thought that counting to 50 would be a
> lighter operation
> than getting the time so many times. This new fix should work even in
> the
> severe loading situation that you appear to be seeing.
>
> I have checked this fix into CVS and will email you an 3.0.2a
> release off list.
> Could you please test this new version on the problematic machine and
> let me
> know the results? Whether it works or not, I would like to get at
> least two runs
> with debug output enabled and the log format set to LPTM so I can take
> a look
> and make sure it is behaving as I expect.
>
> Could you also verify that the system CPU is indeed pegged at 100%
> while
> the application is starting up? I want to make sure it is not some
> other problem
> that I have not thought of.
>
> That is turning out to be a good test machine. :-)
>
> Cheers,
> Leif
>
>
>
> Clement, Nathan wrote:
>
>> Lief,
>>
>> We set the log level as requested and the problem did not occur. We
>> then
>> tried various combinations of the log parameters with the results below:
>>
>> M+INFO=FAIL
>> LPTM+DEBUG=WORK
>> LPTM+INFO=FAIL
>> M+DEBUG=FAIL
>>
>> PTM+DEBUG=FAIL
>> LM+DEBUG=FAIL
>>
>> I'm not sure why this occurs. The log file for this is attached. I
>> think
>> you can tell which part of the log corresponds to which parameter
>> combination based on what the log contains.
>>
>> Regards,
>>
>> Nathan
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for
> just $79/mo with 500 GB of bandwidth! No other company gives more
> support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
|