On 20 December 2011 00:01, Ted <r6squee...@gmail.com> wrote:
> use the concurrent garbace collector can mitigate stop-the-world, you can
> configure where the concurrent process starts so most of the time stop the
> world never actually takes place.

NOTHING you can do will prevent the major stop the world compaction...
it is coming if you run for long enough...

All you can do is postpone it...

depending on your workload and allocation rate and type, you might be
postponing it longer than the next time you need to restart the app...
but it will come eventually if you let your app run for long enough.

http://aragozin.blogspot.com/2011/12/garbage-collection-in-hotspot-jvm.html

http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection

>
> But, back to the original problem of exporting, you may wish to stream the
> data instead of reading it all into memory for export... then it'd require
> no more ram than would be required for 1 record at a time (plus a list of
> the id's which should be very little ram too).

AKA re-design the app.

>
>
> On Tue, Dec 20, 2011 at 7:11 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> if the server us dedicated and has 8gb of ram... you could give 6gb (or 3g
>> if a 32bit os as more will nor be used on 32bit os)... BUT when the stop
>> the world big Garbage Collection triggers (and it will trigger eventually
>> as the last resort to resolve heap fragmentation) then that gc will be 6
>> times longer... if your app response time is important then giving more
>> memory could cause more of a problem.
>>
>> - Stephen
>>
>> ---
>> Sent from my Android phone, so random spelling mistakes, random nonsense
>> words and other nonsense are a direct result of using swype to type on the
>> screen
>> On 19 Dec 2011 20:01, "Jim May" <jim.webg...@gmail.com> wrote:
>>
>> > I have been doing some research on this topic and I know that there is
>> > quite a bit of information out there. Unfortunately, I usually do not
>> > notice articles that recommend JVM tuning setting for servers with X
>> amount
>> > of memory. I have an issue with a production tomcat server that is
>> running
>> > two applications. One of the applications has an export all records
>> feature
>> > AS AN OPTION. The default is export only the 100 rows on the page, but
>> > sometimes the Admin needs to go to the site and export all records into
>> > excel for their reporting. Now the admin is triggering the export all
>> > feature and the server is imploding with out of memory errors for the
>> heap.
>> >
>> > This is the current settings:
>> >
>> > -Xms256m -Xmx1024m -XX:MaxPermSize=384m -XX:PermSize=256m
>> >
>> > I was wondering what you would recommend for JVM tuning settings on a
>> > server that has 8GB or higher of memory? Are there rules that are usually
>> > followed in deciding the settings? The server is completely dedicated to
>> > the two websites and the database runs on a different server.
>> >
>> > Thanks,
>> > --
>> > James
>> >
>>
>
>
>
> --
> Ted.

Reply via email to