Good use of RAM for JRun/Java 2 command line parameters

Maybe this is what you were looking for -ss?

Search for '-ss' and remember if you play around with it then the maximum number of threads on your machine will be affected.

http://www.javaworld.com/javaworld/jw-03-1999/jw-03-volanomark-2.html

Connection scaling in Java

 As Java's scope grows on the server, it is being used to develop highly-scalable server applications. These applications require
 the ability to maintain thousands of concurrent long-lived connections. Java applications must typically devote a thread to each
 connection on which they receive data. Thus applications that require thousands of concurrent connections require thousands
 of concurrent threads and sockets from their Java VM.

 Threads and sockets are system resources and, as such, are finite commodities. Moreover, they consume other system
 resources like virtual memory. Once the thread, socket, or memory limit is reached, no further connections can be established.
 One of the goals of the IBM Win32 JVM on Windows NT was to extend the connection limit within the constraints of the
 operating system.

 Threads consume virtual memory due to the existence of a thread stack. The thread stack is a LIFO (last-in first-out) data
 structure in which function call arguments, function return values, and local variables (among other things) are placed. Java
 provides a command-line flag, -ss, to specify the desired size of the JVM's thread stacks.

 On Windows NT, the amount specified via -ss defines the amount of virtual memory actually allocated for each of the
 JVM's thread stacks. However, unless otherwise specified, the OS still reserves 1 MB of virtual memory by default for each
 thread. Since NT allows a total 2 GB of virtual memory for an application's private address space, the 1-MB stack reservation
 per thread effectively limits the JVM to approximately 2048 threads (2048 MB total virtual space / 1 MB per thread = 2048
 threads). The IBM Win32 JVM achieves a much higher effective thread limit by reducing the virtual memory reservation per
 thread from its 1-MB default. The thread stack reservation is specified in the header of the executable and can be set either via
 a linker option (/STACKSIZE) at the time the JVM is built, or even on a prebuilt executable using the editbin
 utility.

 While making threads thriftier in their resource usage leads to impressive gains in connection scaling, the thread-per-socket
 model simply cannot scale up to tens or hundreds of thousands of concurrent connections. Some form of multiplexing many
 connections to a single thread is required. Native applications traditionally use the select() or poll() system calls to
 achieve this. Java does not yet have a select() facility in its sockets API, but it is clear that one is needed as server-side
 Java applications grow in magnitude and scope.

no response from you?

(not yet :) )

I dont get it? Evaluating still ? gone to EE question above?
Pity not many people r looking into this ,I wonder why? deployment is very very essential to make sure u get good output from ur hot shot stuff.
:)

Sorry it took a while...

I looked over a bunch of the stuff, hopefully hit most of what was important.

So, if we have a situation where:
1) there are alot of servlets running and
2) they are using some shared classes

Is it useful to use NOCLASSGC? I imagine that is why they currently have it there....due to reusable classes. Otherwise, it wouldn't make sense, right?

Regarding ss--it appears that that refers to the maximum size for C threads according to a ref in java.sun.com...did you have recommendations concerning that value? Or am I lost here? Should we add -oss?

Also, somewhere along the line, I've heard that using a higher value for mx and ms can cause instability for our current (1.1.6, I believe) jvm. Are you familiar with this? My original question refers to 1.2, though I'm thinking also about our general environment right now.

Is there any need to consider a larger number than you have listed for ms and mx?

Are there any other parameters we should consider?

Thanks!

>Pity not many people r looking into this ,I wonder why?

You mean these parameters and such? Yeah, I haven't found much on the web about it. Thought I might just be putting in the wrong search values ;)

-ss<number>       set the maximum native stack size for any thread
-oss<number>      set the maximum Java stack size for any thread

I feel that before changing this you should confirm what is the default size of a newly spawned Thread for different versions of JDK?

-noclassgc I think allows to garbage collect statics as this is what I interpret by the word 'class' I think that you should not touch this at all as if your Server is running forever Memory will progressively get littered over time.
My advice dont use it.

>>>I've heard that using a higher value for mx and ms can cause instability for our current (1.1.6, I believe) jvm

we have been using -256M for the last year and have switched to -512 for past two months (JDK 1.1.6 on Win NT4.0 SP3/4 and Sun Solaris 2.6),I didn't hear of any problems yet. But the last 2 months we have been under developement/testing :)

look at for general programming stuff,lots of links...
http://www.purpletech.com/servlet-faq/

>>>Are there any other parameters we should consider?

Look at for complete explanation but the long and short of it is move all your Servlets and Support Classes into WebServer's classpath and out of server_root/servlets ,it's dangerous.

"ClassCastException  in the servlet"
https://www.experts-exchange.com/jsp/qShow.jsp?ta=java&qid=10255641 

Some explanation

Servlet reloading is NOT performed for classes found in the server's classpath(such as server_root/classes) coz those classes are loaded by the core,primordial class loader.
These classes are loaded once and retained in memory even when their class files changes.It is generally good to put servlet support classes soemwhere in classpath of web server where they dont get reloaded.

This moving of servlets to classpath improves performance a bit,since the server does not need to check the class files timestamp to decide whether to reload the class file.

We will meet on Monday as a long weekend ahead for me :)

>Pity not many people r looking into this ,I wonder why?
You mean these parameters and such? Yeah, I haven't found much on the web about it. Thought I might just be putting in the wrong search values ;)

that also and not many people from here participated.

(or Tuesday or so ;) ) Have a good weekend!

no am here ,had to stay out ,wanna discuss ?

Regarding 'noclassgc', you think that that could then be part of why there is a problem with running out of memory? I believe in this instance, there is only one app running in that jvm. That shouldn't be a problem should it?

appears that the default stack size is 128K  (i.e. for ss) for oss, the default is 400K

(Thanks for the other refs)

I just noticed that I might have been unclear. In general, the number of servlets in production is growing. The situation where I know there was a problem running out of memory was where (I believe) there was only one app in production.  

have u moved all your classes to web server's classpath?

-noclassgc,i think it's not the problem,but still dont use it.
Java is bad in long server uptimes,why make it worser still?
                  
Alternatively have you examined and done regression testing on JRun?
or whatever servlet engine you are using? Deploying it on IIS 3.0?
Chedked the configuration for that?
Keep the pagefile size to around 10GB or more if you have the space that is ,
remember the more is teh size of the page file the more are the chances of ur
App running albiet a bit more slowly.

Finally it will happen that there will be one culprit
that will hog memory way too much,try using a good profiler
for each and every class file that you have loaded into Web server.
Have a practice of running all ur classes thru a profiler.
This is just normal and it will help you tune your appls .
Sigh..... why are no website dedicated to this important thing?

JRun is being deployed on Unix...

So, are you recommending that all production servlets reside in the jrun's classpath and not be auto-reloaded?

So, would it be useful if you are running only one servlet instance in jrun to keep 'noclassgc' on or is there something I'm missing regarding the idea of class garbage collection?

>>>all production servlets reside in the jrun's classpath

Yes,pls read the other thread I mentioned for a explanation.

re: -noclassgc

Please don't use that as somebody (let's take you) does the initial configuration,later on some other guy deploys more and more servlets,and they forget to remove the -noclassgc option,this means that as more servlets gets loaded when the Web Server decides to destroy a particular servlet if more requests arrive for others,then the statics like

public/private /protected static final int KK=0;
etc...

wont get gc'd for them I think.
Is your swap (or page file in Windows NT)file size decent ? Increasing it to 10Gb or more will increase throughput of your system.

Remember it not enough to have only more RAM but more Virtual Memory as well.

Cheers :)

(Good morning :) )

already read your other explanation; thought you were referring to shared/library classes, rather than production classes that are not shared as far as classpath/non-reload;

re:-noclassgc--it is currently in use so I will need to justify a change, so I want to make sure I know what I'm talking about when the discussion happens.  The -noclassgc option includes static variables within classes and such?

They are run on Unix servers. The swap space allotted is usually consistent with the amount of RAM. It also appears that many of the servers have 2G of RAM rather than one.

Turning off asynchronous Java garbage collection means that garbage collection will not occur until absolutely necessary.

As you may know because the Java gc thread has a lock on the Java heap, when the garbage collection runs, nothing else happens. Using the -verbosegc flag will show you when garbage collection is ocurring. As this is JVM issue, i tink that we will need a change in technology (if using jdk 1.2 |1.3 HotSpot )before we see an improvement here.

In general, so more physical memory increases the speed of execution of Server work, and will make it possible to support more clients.

I found out 1 thing though.

If you want the GC thread to wake up and do more work or in case you have Memory problems ,reduce the -ss & -oss from

>>>128K for ss to less
>>>400K for oss to less

If you have lots of Memory or you don't want GC thread to kick in more often ,increase them.

this is Peter Norton's advice...

Will paste a detailed text tommorow/day after abt this if u want.

Wondering if I'm getting lost here. You mentioned turning off asynchronous gc ...that would be the -noasyncgc tag, not the -noclassgc, right?

I would be interested in seeing more info on the ss/oss thread limits, if you feel like submitting it.

Thanks for all the info!

Yes ,sorry got lost a bit ,yes I was talking abt -noasyncgc ,I still think taht noclassgc is related to statics but I will ask some other people to come here and help you out.

here is the text and more on Constant pool too...

From
Peter Norton's Guide to Java Programming
by
Peter Norton & Wiliam Stanek

Chapter 24
The JVM

The Garbage-Collected Heap
--------------------------
Each program running in the Java runtime environment has a garbage-collected heap assigned to it. Because instances of class objects are allocated from this heap, another word for the heap is the memory allocation pool. By default, the heap size is set to 1MB on most systems.

Although the heap is set to a specific size when you start a program,
it can grow-for example, when new objects are allocated. To ensure that
the heap does not get too large, objects that are no longer in use are
automatically deallocated or garbage-collected by the Java Virtual Machine.

Java performs automatic garbage collection as a background thread. Each
thread running in the Java runtime environment has two stacks associated
with it: The first stack is used for Java code; the second is used for
C code. Memory used by these stacks draws from the total system memory pool. Whenever a new thread starts execution, it is assigned a maximum stack size for Java code and for C code. By default on most systems,the maximum size of the Java code stack is 400KB and the maximum size of the C code stack is 128KB.

If your system has memory limitations, you can force Java to perform
more aggressive cleanup and thus reduce the total amount of memory used. To do this, reduce the maximum size of the Java and C code stacks.
If your system has lots of memory, you can force Java to perform
less aggressive cleanup, thus reducing the amount of background
processing. To do this, increase the maximum size of the Java and
C code stacks.

The Constant Pool
-----------------
Each class in the heap has a constant pool associated with it. Because
constants do not change, they are usually created at compile time.
Items in the constant pool encode all the names used by any method in
a particular class. The class contains a count of how many constants
exist and an offset that specifies where a particular listing of
constants begins within the class description.

All information associated with a constant follows a specific format
based on the type of the constant. For example, class-level constants
are used to represent a class or an interface and have the following
format:

CONSTANT_Class_info {
    u1 tag;
    u2 name_index;
}
where tag is the value of CONSTANT_Class and the name_index provides
the string name of the class. The class name for int[][] is [[I. The
class name for Thread[] is [Ljava.lang.Thread;.

a colleague logged in here in my absence,these d..n cookies,so posted that above comment in rainmal 's  name.

I sent a mail to some people ,if they have time they will come and look up here including 'rainmal'.

So, that is a bogus post not worth reading?

Hey I posted it by mistake under 'rainmal' 's name ,I thnk it is definitely worth reading.
:)

OHHHHHHH, ok. Sorry, I totally misunderstood. I thought you said that someone else posted it!

have you found out anything abt -noclassgc ? If so do let me know
Thanx

OHHHHHHH, ok. Sorry, I totally misunderstood. I thought you said that someone else posted it!

EEk. It's bad to reload the page--tends to repost the last comment!

No, haven't found out anything new about -noclassgc. You neither?

no

(thanks for the detailed information you added, by the way)

So, in summary (what we have at this point):

use : -ms256M
         -mx256M for heap maxes and mins;

for -ss: default stack size is 128K for C threads (have we determined an optimal solution here?)

for -oss, the default is 400K for Java threads

-ss and -oss refer to the stack size each of these can reach, this memory removes total memory from the total system memory pool (So, when we are dealing with JRun, will this be the amount each servlet is allowed to have, or the amount of memory allocated to each user thread?)

If you want the GC thread to wake up and do more work or in case you have Memory problems ,reduce the -ss & -oss from their defaults to less;
                 
  If you have lots of Memory or you don't want GC thread to kick in more often ,increase them.

Recommend moving all production Java classes to the servlet engine's classpath (?)

-noclassgc: we're not sure what the definition of 'no class garbage collection' means completely;

  Using the -verbosegc flag will show you when garbage collection is ocurring.

Run all classes through a profiler, if possible.

Anything else?

No ,will let you know as and when I come by any good titbits.It's been a good and learning experience for me too.

Thanks amigo

Mail me at my profile ID and I will forward you a nice article on Threads by Allen Holub .

Thanks for all the help!