Forums

What do you guys set your memory settings to?

I realize memory usage patterns will be different for every application, but I thought it might be a good discussion to have.

We use a memory calculator that takes the total amount of memory available and number of users as an input, and outputs the memory settings to put in the ini file and a recommended number of App Servers. It assumes all of the App Servers will be on the same physical server as the DB Server.

The calculator uses a figure of 30 users per App Server based on some very old advice from Jade - what do you guys use? Does anyone have experience with larger numbers of users per App Server?

The calculator caps memory usage at 2GB because we're still using 32bit.

It leaves 1/4 of the memory free for use by the OS and other programs. That could probably be more intelligently calculated but it's hard to tell what the OS will need.

It calculates the amount of memory available for use by the DB Server using a ratio of 340 to 420. The ratios were calculated backwards from an example system we manually configured to be the way we wanted.

It divides the memory allocated to the DB Server into 59% for the PersistentDb ObjectCacheSizeLimit, 29% for the JadeServer ObjectCacheSizeLimit and 6% each for the JadeServer TransientCacheSizeLimit and RemoteTransientCacheSizeLimit. The ratios are set up so that the majority of the memory is to the PersistentDb ObjectCache on the principle of making the cache closest to the physical db the biggest. Next smallest is the JadeServer ObjectCache and then some left over for transient caches. Our server apps aren't usually as high priority as the thin clients, so we don't allocate too much memory to them.

It divides the memory allocated to each App Server into 24% for the JadeClient ObjectCacheSizeLimit, 5% for the JadeClient TransientCacheSizeLimit, 71% for the JadeInterpreter MethodCacheLimit (we use MethodCache=Single) and half the MethodCacheLimit for the StringPoolLimit so that Strings and Binaries never push all methods out of the cache.

So for an available memory of 2GB and up to 30 users, these are the memory settings the calculator recommends:

1 CPUs or Cores are needed

[PersistentDb]
ObjectCacheSizeLimit=405M

[JadeServer]
ObjectCacheSizeLimit=199M
TransientCacheSizeLimit=41M
RemoteTransientCacheSizeLimit=41M

1 App Server(s), each with the following ini settings:

[JadeClient]
ObjectCacheSizeLimit=204M
TransientCacheSizeLimit=42M

[JadeInterpreter]
MethodCache=Single
MethodCacheLimit=603M
StringPoolLimit=302M

Does anyone have experience or advice that violently disagrees with our memory settings?

There are a few things where I would recommend a different conceptual aproach.

Firstly, Windows file-system cache is extremely useful. What Task manager reports as "Available Memory" in Windows 2003 server and XP is acutally mostly file-system cache when JADE databases are running. It would be better to allow most memory to be used for this rather than in the database server. This is especially true if there are multiple databases running on the machine. The PersistentDb ObjectCacheSizeLimit should basically be set depending on the frequency of updates - I tend to use 20M, 40M or 80M in most cases.

The application server persistent object caches should be set to keep the high-level collection blocks and other frequently-used objects as close to the executing methods as possible. It is usually better to have more Windows file-system cache than appserver cache, especially if there are multiple appservers. Finding an object in the local node cache rather than file-system cache saves a little cpu. Not finding an object in file-system cache results in an IO to disk, which is much more expensive. The primary objective of caching is to reduce IO. So size the appserver persistent object caches to hold the really frequently used objects, and hope to get the rest from file-system cache. I generally use 20M, 80M or 120M for this, for light, normal and heavy usage systems respectively. Oversizing these caches means there can be multiple copies of objects in memory (in multiple appservers), and can cause increased IO due to restricted file-system cache.

Sizing of transient caches depends a lot on the application. If transients are used a lot, sizes similar to persistent cache sizes may be appropriate. Sizing of server caches depends even more on the application. If server apps and serverExecution are not used much, 20M or even smaller may be appropriate.

Performance will be better with multiple method caches. In your example you have MethodCacheLimit=603M for 30 users. Using 20M and multiple caches would perform better (due to decreased contention), and use the same overall amount of memory. In my experience, most applications do not benefit from more than 8M or 12M of method cache, so I generally would use those values for production systems.

A couple of cautions for method cache settings:
1. When using multiple caches, the cache size specified is allocated for each user (same for string pool). If the number of users is fluid and you over-allocate this, you can easily exceed the 2GB memory limit on appservers.
2. The default method cache size of 512K was set back when memory sizes were much smaller. It would be advisable for everyone to check that they are not using this setting.

Finally, I would reemphasize the importance of Windows file-system cache. If there is not enough of this cache after configuring the JADE caches, more memory should be installed. Few systems can operate efficiently on less than 500M. 1GB or more is usually much better. I have seen cases where increasing Windows file-system cache from 14GB to 30GB made a huge improvement in performance.