Our production servers (three replicants) are equipped with 128GB. We started maxing out
the 64G chips that used to be in there and had to upgrade. This is for a similarly sized
id2entry file, however, the memory we use primarily is not for database cache but is for
the entry cache.
This memory size applies to Sun Directory Server 6.3. We are transitioning to 389, and
389 uses about half the memory required for the entry cache, so we probably can get by
with 64G for those nodes, but with Linux, we have been experiencing the memory
fragmentation problem which grows the memory requirements significantly when lots of
modifies are done. For this reason, we are also going with 128G for that environment.
Ultimately, you will need to test for performance, but definitely test with larger memory
sizes and larger cache sizes to verify what speed improvements you might get. Speed can
be very seriously impacted when the cache is not tuned well and doesn't have enough
space for decent response time.
Regards,
Russ.
==============================
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
beall(a)usc.edu
==============================
On Nov 16, 2012, at 6:30 AM, P R <pwrdevman(a)gmail.com> wrote:
Hello,
First off, my server is equipped with 12GB of physical memory. From reading tuning guides
online, I’ve found that a starting estimate for the ‘dbcachesize’ = SUM(allDB4files). For
one of my directory instances, the id2entry.db4 file alone is ~ 11GB.
Performance wise, would it be worthwhile to increase the amount of physical memory on the
server (perhaps 64-128GB)? Or does 11GB for an id2entry seem like an extremely high value
that’s out of the operating capabilities of the directory? Is it unheard of for a
production directory server to be equipped with 64GB of physical memory?
Thanks,
pwr
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users