gshegosh wrote:
That's actually quite strange with Netbeans. I can see it's using Xmx
512M and MaxPermSize 200M but it still takes up almost 800M in mem and
I've seen more than 1,5G occasionally.
JVM Heap + Perm Gen (most JVMs except JRockit have it sit outside Java
Heap) + C Heap, Thread stacks, etc... = Process Memory
So... 512M + 200M + <?>... should at least be 712M+ and 800M isn't a
surprise.
What are you doing when you see it go up to 1.5G? Does it happen over a
protracted period of time? Perhaps a NetBeans memory leak? If its
nothing special then I would look at bug reports and consider switching
to another IDE as 1.5GB is ridiculous.
As to Glassfish - I have plenty of RAM so I upped Xmx and permsize
because otherwise it would give me outofmemory exceptions every 2 or 3
redeploys. I guess it's some serious leak in Glassfish itself, because
it happens for more than one apps and at the production, where redeploys
are rare, the problem is nonexistent.
What exact version of GlassFish and what JDK? v3 Final? 1.6_? I have not
seen any such memory leaks... . Do you happen to have a .hs_err_BLAH
(IIRC the name) file when the OOM occured... b/c if you do then you
should be able to easily see what filled up... if it indeed was perm gen
space or something else?
It's quite common practice to have on production app servers the min and
max of memory settings the same and maxed so that things don't grow i.e.
set "permSize" AND "maxPermSize" to your max perm size... set "-Xms" AND
"-Xmx" to your max JVM heap size... otherwise new blocks of memory will
need to be allocated, copying, etc... . In development I set the min to
at least 1/2 my max for the heap and set min and max perm gen to the max
value as there is a lot of class re-compilation / re-loading... 256MB is
usually sufficient and if that fills up its probably best to restart the
app server in any event. Then there are other JVM settings to tune as
well... like GC algorithm, GC threads, etc... setup your gc to print out
periodically and review the data.
What OS are you running on and what is your -Xss JVM setting? On Solaris
for example 1MB is allocated to the stack for each thread which is
overkill for almost any production app... 128k is typically more than
sufficient.
Performance tuning is a big area in itself and there are many things to
adjust / tweak. It amazes me how many times I have seen client
production app's fall over on a 32bit JVM with say 2.5GB of allocated
heap... yes... if you get enough load and your app server is worked hard
enough... it will fall over at 3.5 - 3.8GB (at least on Solaris).
But honestly you can't compare any app server in development vs.
production as the load characteristics and most often even the OS aren't
even the same.
You wont note a difference betwenn i5 and i7 when developing webapps.
If you do care about build time differences of a half second then use
a i7.
Probably true because I don't see all cores of my i7 busy too much on my
desktop (video and mass image processing is amazingly fast though).
So, a laptop with i5, 8G of RAM and an SSD drive perhaps should be good
for my needs. I haven't been really following _all_ tech changes in PCs
recently, is there anything else I should look at when hunting for a
perfect machine? :-)
I think that pretty much covers the hardware side... save of course a
big screen and / or external display.
--Nikolaos
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
