On 08/20/2013 08:39 PM, Jeffrey Dunham
wrote:
What is the platform? What version of 389-ds-base? How much RAM do you have? What is the size of your database?
Yes.
Replication on the supplier side or replication on the consumer side.
To speed up writes? That might help, but not much, since your bottleneck is that only one write can happen at a time. The first thing you should do is optimize your db and entry cache usage. You can use the https://github.com/richm/scripts/wiki/dbmon.sh script to monitor your cache usage, and find out how much RAM you need for your caches, and find out how much RAM you have left over for other tuning. 1) Try putting the db home directory on a RAM disk. By default, bdb uses memory mapped files in /var/lib/dirsrv/slapd-INST/db. These have to be flushed to disk. Change nsslapd-db-home-directory to point to a RAM fs. mkdir /dev/shm/slapd-INST ; chown nobody:nobody /dev/shm/slapd-INST ; chmod 0600 /dev/shm/slapd-INST Then shutdown dirsrv, edit /etc/dirsrv/slapd-INST/dse.ldif in the dn: cn=config,cn=ldbm database,cn=plugins,cn=config entry, add nsslapd-db-home-directory: /dev/shm/slapd-INST NOTE: This will use the amount of RAM specified by nsslapd-dbcachesize, so make sure you have enough RAM. https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Database_Plug_in_Attributes.html#Database_Attributes_under_cnconfig_cnldbm_database_cnplugins_cnconfig 2) Use different physical disks for your db directory, transaction log directory, and server log directory. If you can afford it, use a disk controller with a write back cache for the disk used for the transaction logs. 3) If you can afford the possibility of data loss, you can disable durable transactions.
|
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users