SMA and LLA Guide : Configuration parameters for a diskless server : IndexFile.CacheSize parameter in diskless servers
  
IndexFile.CacheSize parameter in diskless servers
The IndexFile.CacheSize parameter defines the amount of main memory in bytes that the server allocates for the buffer cache.
For example:
[IndexFile]
CacheSize=10000000
With diskless servers, the cache size depends on the following criteria:
Because a diskless server does not use any disk storage space, it maintains all D-tables in the database cache. The database cache size (IndexFile.CacheSize) has to be configured to contain the whole database. Thus, if the database on a diskless server contains mainly disk-based tables (D-tables), the cache size (in bytes) needs to be at least 20% larger than the maximum file size (that is, the amount of data) set with the IndexFile.FileSpec parameter. The 20% buffer is an estimate that can vary depending on the usage of the database.
For example:
[IndexFile]
FileSpec_1=solid.db 10MB CacheSize=12MB
If the database on a diskless server contains mainly in-memory tables (M-tables), a database cache still exists: it holds the system tables. With M-tables, the minimum cache size is 1-2 MB. The space occupied by the system tables depends of the number and complexity of database objects and whether advanced replication is used or not.
The cache size must be less than the physical memory available for running the diskless server.
You can estimate the total memory used by the diskless server by using the following formula. The total memory must fit within the amount of physical memory available, which means that the cache size must be smaller than the amount of physical memory available to the server.
CacheSize
+ 5MB
+ (100K * number of users * number of active statements per user)
+ in-memory table space
+ (HSB operations to be sent to the Secondary) [1][2]
[1] This term of the equation applies to HotStandby users only. An HSB Primary server needs some memory to store HotStandby operations that are to be sent to the Secondary server. During a temporary network failure between the Primary server and the Secondary diskless server, the Primary may continue to accept transactions from an application. When the network connection is restored between the servers, updates from the Primary server are sent to the Secondary server. (HotStandby uses the transaction log to store these operations. A diskless server cannot write the transaction log to disk; the information must be stored in memory.) This memory is separate from the Cache.
[2] For this term of the equation, the maximum limit is currently 1 MB or 512 operations, whichever is lower. Unlike on a disk-based server, the transaction log is not allowed to keep growing until it uses up all available space.
The exact amount required also depends on other factors, including the nature of the queries executed against the server. The amount of memory available to the server is less than the total physical memory, since, for example, the operating system uses some of the physical memory.
See also
Configuration parameters for a diskless server