Re: Multi-Theading writes to the same 389 Master Server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/20/2013 08:39 PM, Jeffrey Dunham wrote:
We have a customer that has been multi-threading behind multiple servers and writing to our Master server.   These writes come in the form of heavy spikes (1k over 5 second intervals) very much burst traffic and all the writes are adding new items to the same ou.

What is the platform?  What version of 389-ds-base?  How much RAM do you have?  What is the size of your database?

While we have plans to throttle them I had a few questions:

a) If they're writing to the same ou / updating the same indexes are they blocked on one items success before another succeeds?

Yes.

So in this case multi threading behind multiple boxes does not give them any performance impact.  I would guess this is the case, but I want to be sure.  Because replication seems to be fine which goes through a single thread iirc.

Replication on the supplier side or replication on the consumer side.


b) are there any performance tweaks that can help?  I thought maybe looking at nsslapd-threadnumber.

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.


-Jeff


-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux