Problem:
The CPU of your UCS server spikes very frequently making the server partially unresponsive.
Environment
You operate a multi server environment with a couple of member servers.
Solution
UCS servers need to rebuild the local group cache in order to make sure the data is always up-to-date for authentication purposes.
In the default setting, the group cache is regenerated every time changes are made to a group. This avoids cache effects whereby group memberships only become visible for a service after the next scheduled group cache rewrite (in the default setting after 15 minutes and after 15 seconds of inactivity in the Univention Directory Listener. In larger environments with a lot of group changes, this function should be deactivated by setting the Univention Configuration Registry variable nss/group/invalidate_cache_on_changes to false . This setting takes effect immediately and does not require a restart of the Univention Directory Listener.
To set do:
ucr set nss/group/cachefile/invalidate_on_changes=false
When the group cache file is being generated, the script verifies whether the group members are still present in the LDAP directory. If only the Univention Management Console is used for the management of the LDAP directory, this additional check is not necessary and can be disabled by setting the Univention Configuration Registry variable nss/group/cachefile/check_member to false .
To set do:
ucr set nss/group/cachefile/check_member=false
Frequently the group updates are not needed immediately so you can schedule the re-creation for the nights:
ucr set nss/group/cachefile/invalidate_interval='0 0-7,17-23 * * 1-5'
In this example it is run from 17:00 until 07:00 every hour at “0” minutes and only Monday to Friday. See man crontab for further details about the syntax.
Additionally you might configure you member servers to use a backup or slave server for this operation so the load will get balanced. By default it is set to your master server:
ucr set ldap/server/name=slave1.multi.ucs