Zarafa server tuning

From Zarafa wiki

Revision as of 09:16, 24 November 2010 by Ddebyttere (Talk | contribs)
Jump to: navigation, search


About Zarafa server caches

For performace reasons, it is strongly recommended to set the cache settings of the Zarafa server appropriate for your setup/server. Each time a request on an item can be found in the cache (cache hits), this avoids calls to other processes and disks/storage. Setting sensible cache settings certainly increases the performance.

This page contains some information about the settings and an example of a server dedicated for a complete Zarafa suite. This page only covers cache settings for the Zarafa server.

For more information about MySQL tuning, see MySQL tuning. If using the Webaccess in larger setups it is also advisable to tune your web server (Apache) as well.

In a server purely running Zarafa, it is advisable to set caches to use around 80% (in total -- including MySQL) of the RAM available in your server and can be considered to be a rule-of-thumb. The other 20% should be free for system processes, other processes (like your MTA) and the web server. Whenever you set the values too high this can result in the use of swap on your server. Swapping should be avoided, but we do want to make use of the RAM available. Therefore these settings should be a healthy balance between the risk of swapping and efficient caching in memory.

One could use the following example values for the server in the dedicated server situation described above.

  • cell cache: around 25% of total RAM size
  • object cache: 16-64 MB
  • indexed object cache: 16-128 MB

These cache settings need to be configured in the /etc/zarafa/server.cfg and details about these cache settings are described in the sections below.

The cache sizes set are a maximum and the actual use of it will grow along the server has had more request over time. Whenever you restart the server, these caches are purged and as a result performance will be lower until the caches are being filled up. To re-read configuration files, but not purge caches it is possible to reload the zarafa-server, instead of restarting it.

Cell cache (cache_cell_size)

Size in bytes of the cell cache. This is the main cache used in Zarafa. It caches all data that comes into view in tables (e.g. the view of your inbox, or any other folder). In an ideal situation, all cells would be cached, so that the database does not need to be queried for data when browsing through folders, but this would require around 1.5K per message item (email, appointment task, etc) in the entire server. If you can afford it, set this value as high as possible, up to 50% of your total RAM capacity.

Object cache (cache_object_size)

This caches objects and their respective hierarchy of folders. You can calculate the size with a simple equation:

<Concurrent users> * <max items in a folder> * 24

Default value is 5242880 (5 MB)

Indexed object cache (cache_indexedobject_size)

This cache contains unique id's of objects.

Cache statistics

To get the cache statistics from the zarafa-server process, you can send the USR1 signal to the server process.

 killall -SIGUSR1 zarafa-server

This will report the cache statistics in the /var/log/zarafa/server.log. Note that this command will not kill the zarafa-server processes, but just send a USR1 signal to the processes with the name zarafa-server.

The statistics include the hits of each cache and these values can be used to determine whether the cache is large enough for your setup. The output in the log file will look similar to this:

Dumping cache stats:
 Object cache size:      185277 ( 4446648 bytes) (usage 42.41%)
 Object cache hits:    103460236 / 103689654 (99.78%)
 Store cache size:        37058 ( 1037624 bytes) (usage 98.96%)
 Store cache hits:     53361616 / 53409325 (99.91%)
 ACL cache size:           1011 (   16176 bytes) (usage 1.54%)
 ACL cache hits:         330196 / 333755 (98.93%)
 Quota cache size:            0 (       0 bytes) (usage 0.00%)
 Quota cache hits:        40207 / 144955 (27.74%)
 ExternID cache size:        23 (     552 bytes) (usage 0.05%)
 ExternID hits:          347000 / 490377 (70.76%)
 User cache size:           148 (    3552 bytes) (usage 0.34%)
 User hits:             1458920 / 1584904 (92.05%)
 User Details size:         149 (    8940 bytes) (usage 0.34%)
 User Details hits:      968730 / 1093359 (88.60%)
 Server cache size:           2 (      56 bytes) (usage 0.01%)
 Server cache hits:       61393 / 61889 (99.20%)
 Cell cache size:        179181 (115208996 bytes) (usage 85.84%)
 Cell cache hits:      122278268 / 125544907 (97.40%)
 Index1 cache size:      211630 ( 5925640 bytes) (usage 35.32%)
 Index1 cache hits:    18049716 / 18073197 (99.87%)
 Index2 cache size:      210600 (15175824 bytes) (usage 90.45%)
 Index2 cache hits:    23058456 / 23279839 (99.05%)

In this example we see that the hits are generally 96-99.9% here. This saves just this amount of request to dependant services as MySQL or the filesystem!

Personal tools