It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,788
×2,339

question asked: Sep 14 '13, 5:36 a.m.
question was seen: 5,261 times
last updated: Sep 16 '13, 11:24 p.m.

Related questions

FAQ - How this Forum works

Maximum Java heap size can be set on WAS?

0
Makson Lee (410●2●42●41) | asked Sep 14 '13, 5:36 a.m.
Tried to set Xmx setting to 40GB, but got option too large error, we can't find any documents about how to calculate the maximum heap size, can anyone help?

Here is our hardware and software configuration,

RAM: 100GB
OS: RedHat Enterprise Linux 64-bit
WAS: 8.5.5.0

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Matt Lennon (612●2●5) | answered Sep 14 '13, 8:20 a.m.
JAZZ DEVELOPER
Hi Makson.

Too much JVM heap can be just as bad as too little - the JVM will spend all it's time garbage collecting. What motivated you to want to increase it to 40 GB? Are you getting out of memory exceptions? I've not personally seen a server with more than 16 GB myself.

Are you hosting multiple applications in the same WAS profile? Perhaps you could split them into separate profiles.

-Matt
Comments
Makson Lee commented Sep 14 '13, 8:58 p.m.

We are doing Android platform development, for some reason, need to put about 400K files into a single component (i know this is not a good practice), and we have few projects with component like that.

We found RTC server sometimes takes about 10 minutes to run getFileTreeByVersionable4 service for workspace loading operation, but sometimes takes about 2 minutes for the same workspace loading.

So i guess RTC server may cache something there, and our Java heap is just not big enough so the cache been swapped out, that's why i am trying to set the heap size to as big as possible.


Matt Lennon commented Sep 16 '13, 10:38 a.m.
JAZZ DEVELOPER

I don't think the getFileTreeByVersionable4 response data is being cached by the server - at least not enough to cut 8 minutes off the response time, and certainly not enough to consume 40 GB of Java heap. Have you tried monitoring your server's JVM heap usage? That will give you a much better idea of an optimal JVM heap size setting for your server.

Bo Chulindra commented Sep 16 '13, 11:25 a.m.
JAZZ DEVELOPER

Makson: I'm guessing you tried 16 GB but it didn't solve your problem?

Tim Mok commented Sep 16 '13, 11:57 a.m.
JAZZ DEVELOPER

258751: Long time during the fetching time of a build with large amount of files under Windows
245863: Improve load performance by parallelising getFileTreeByVersionable4() and content load
62219: FilesystemService.getFileTreeByVersionable() should be streamed
It sounds like you're affected by these work items. It doesn't sound like any of them have mentioned improvement by allocating more memory. It's just a limitation of the implementation at the moment and it needs to be improved.

Makson Lee commented Sep 16 '13, 11:24 p.m.

Thanks for all of your response.

I am not sure that if the getFileTreeByVersionable4 response data is being cached by the server, but from our experience, after a WAS server restart, it takes about 10 minutes to run the first time getFileTreeByVersionable4, but takes only about 2 minutes to run the second time, i am also curious about that, maybe you could help to verify?

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.