Novell Teaming is a Java/J2EE application and therefore executes within a Java Virtual Machine (JVM*). The JVM exists as a process on your system and all of the Novell Teaming and portal software runs within it. Consequently, the amount of memory available to the JVM process is a critical aspect of overall Novell Teaming performance.
The key JVM memory setting is the Java heap size, which roughly corresponds to the amount of memory available to the Java applications (such as Novell Teaming).
The setting in the window of the installer allows you to set the amount of physical memory you want to devote to the Java Virtual Machine.
The default configuration assumes that the JVM uses 1 GB (one gigabyte) of memory. It is possible to run Novell Teaming with less than 1 GB of assigned memory, but this is only applicable to very small test configurations, and is not suitable for production use. (In such a test configuration, 512 MB is the minimum amount of memory required to produce a functioning Novell Teaming application.)
A general rule is that no more than 75% of the available physical memory should be allocated to the JVM. This means that you need to account for other processes (including the operating system itself) that use memory. Databases, in particular, tend to be memory-intensive, so take special care when co-locating a database server with the Novell Teaming application server.
Java and Novell Teaming make heavy use of available memory to provide good performance. Larger deployments (large numbers of users and/or large numbers of documents) often need memory settings in excess of 2 GB to provide adequate performance. For these conditions, 64-bit hardware coupled with a 64-bit JVM are required.
WARNING:A JVM on a 32-bit system should never be configured to take more than 1.5 GB (1500 MB) of memory. Larger memory allocations require 64-bit servers.
Novell Teaming memory usage is driven by a number of factors:
Number of sessions (users logged in): Does not represent a significant amount of memory.
Number of active/concurrent sessions: Does not represent a significant amount of memory.
Novell Teaming internal database caches: Can be a significant part of memory use. These caches are separate from any caching or memory use by the database server itself, which might or might not be on the same server. Internal tuning settings have been set to handle a wide range of deployment sizes.
Lucene index cache: Can also be a significant consumer of memory. Large data stores (particularly with large files or a high number of files) can create a very large index. Installations with this type of demand should consider separating the Lucene Index Server to a dedicated standalone server for optimum performance (see Installing a Standalone Lucene Index Server).