[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Openldap2.4.16 performance issue
William E Jojo <w.jojo@hvcc.edu> writes:
[...]
>> "Singh, Devender (GE Capital, consultant)" <Devender.Singh2@ge.com>
>> writes:
>>
>> > Hi Dieter,
>> > Please find the below details:
>> > 1. hardware related
>> > - type of storage - Simply SATA had disk attached.
>> > - raid level, if any- No RAID
>> > - file system of disk(s)- ext3 on LVm
>> > - type of network, 100MB, 1G, 10G
>> >
>> >
>> > 2. is this host running on a virtual machine or on bare metal.
>> > - if virtual machine, -Yes, OS installed on VM
>> > -- what type ---Don’t know
>> There is nothing suspicious, except for the virtual machine. Your
>> really should carefully check layout and configuration of this VM,
>> do not use virtual disks.
>>
>
> Hi Dieter,
>
> Could you kindly explain what this means? I've been all over the
> inter-webs and I'm not finding anything concrete about OpenLDAP and
> VM's or Databases and VM's in general. The closest I came was about
> some database latency studies and some VMware propaganda.
My comments are based on my own experience. I am not against virutal
machines in principle, but only against full virtualisation, that
is virtualised disks and cpus, in a production environment.
A para virtualisation might be acceptable, if the hypervisor provides
sufficient resources and exclusive read/write access to a disk and
client connections are moderate. But in all cases you have to expect
performance loss.
> We are about to launch a master and two replicas (utilizing
> delta-syncrepl) running in Ubuntu 10.04 on a VMware VSphere ESXi 4.0
> cluster with four IBM x3650-M2's (2 Quad Nahalem and 64GB memory each)
> with virtual disks carved from NFS mounts to all of the VSphere
> servers in the cluster to facilitate HA and FT - by the VMware book.
> (BTW, I took one of Howard's old posts to heart and we are following
> the Ubuntu playbook and we have purchased Canonical 24x7
> support/maintenance. :-) )
>
> We have had no problems with this environment in development and get
> better results than on bare metal with or without RAID. I know that it
> is recommended that the logs live on another "disk" from the database
> and RAID is frowned upon, but I have difficulty with a few points:
>
> 1) Separate, unprotected disks seems illogical. The last log and the
> BDB files are necessary to start BDB in slapd, correct? So, if you
> lose either disk, you're in trouble. Backups are ok, but daily seems
> too long a time. Seeing as we process new user accounts every 15
> minutes, this would not be ideal for us.
Yes, slapd requires the last transaction logs in order to recover a
corrupted database, but the risks can be minimized by setting
appropriate checkpoints. Writing new entries every 15 minutes wouldn't
cause much trouble if you checkpoint every 4K and every 3 minutes.
> 2) RAID-1 I can understand having an issue on writes. But what about
> LUNs in FC from a NetApp 3140? Virtual disks on NFS in VMware? Both of
> these are in the best practices of both VMware and NetApp
> documentation.
Just a scenario based on my own experience:
a organisation wide addressbook with some 100,000 user entries, each
user may have arbitrary private addressbooks underneath its entry
node. Mail clients use this addressbook for address completion, mail
clients are badly configured to use the root entry as search base. Can
you imagine the number of parallel read operations? In addition to
this read operations consecutive write operations of adding new
entries, writing to index databases writing transaction logs. If you
do not allow the transaction logs to reside on a different disk, you
sure will experience db deadlocks in search opeerations.
> 3) 13-disk 7200RPM SATA RAID-DP (NetApp) is far faster than a single
> disk, dual diak or RAID-1, so why wouldn't you use SAN/NAS storage?
>
> I seriously want to understand the VM concern as it pertains to
> OpenLDAP. I think more and more people are doing this very thing and
> will benefit from this discussion.
The main concern is performance. If you only expect a few connections
per second, performance is not a questions, but if you expect a few
thousend connections per second, performance is an issue.
[...]
-Dieter
--
Dieter Klünter | Systemberatung
sip: 7770535@sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6