best scaling Solaris platform for DS5.2 with heavy ACIs?
I know this is a bit of a shot in the dark and am looking for feedback, possible URLs of performance benchmarks (Yes, I've seen the cn=Directory Manager blog), and any theories for the best platform DS5.2 on Solaris.
Windows is not in the running, unless it can be proven to be better than DS5.2 on v210 1.5ghz Uiii cpu's...
We have been using SLAMD with weighted searches to profile the performance of various platforms.
Unfortunately T2k's are not measuring up to our expectations.
We are gravitating to the X4200 series of machines from the perspective that we can get the most compute for the buck for the form factor.
Anyone have experience with 440's vs X4200 and which is better when considering the bang for the buck?
Any problems with 64 bit versus 32 bit?
Directory details:
We have a 200k population in our directory with many ACIs (~45-50..thanks JES :( ).
We also use JES mail 6.2.
We have already read and consolidated where we can the ACIs that are recommended by the Access Manager tuning document.
We already have bumped the caches to appropriate levels
We already have applied the latest O/S patches to the T2k's...including firmware updates, especially the gig ethernet interface patch. (ipg0 -->e1000g switch)
Thoughts, comments and pointers welcome!
C.
# 1
In my experience, the faster the CPU, the better scalability with "heavy" ACI for Directory Server.
So, I would favor an x4200 over a v210.
The drawback with the x4200 with DS 5.2 is the requirement to run as 32bit and thus the limit of memory to 4GB for the Directory Server. For 200K entries, this shouldn't be too much of an issue unless the entries are really large and you want response time under the 10ms. If that's the case, then I would encourage you to move to Directory Server 6.1 (the most recent version available) which runs as a 64 bit application on Solaris 10 AMD processors.
Regards,
Ludovic.
# 2
I have a similar doubt about this...we have around 1million entries and we are using DS5.2 sp4 on AIX 5.3 on ...
When i made the calculations for the caches....the DB cache alon came around 1GB with all the indexes and entry cache a little bit more..All servers are 2X4 650 LPAR equivalents..
I am a little bit confused with the cache settings...The Server we are using are 64 bit...So the limitation of 2GB cache allocation applies to each cache(DB, entry) or is it for the cumulative of those caches?
# 3
Directory Server 5.2 on AIX is a 32bit application and thus cannot address more than 4GB of memory overall.
Now some OS do limit the process allocation size to 3.7GB or 2GB. It is beyond the control of Directory Server.
Directory Server makes use of 2 caches: the entry cache, the dbcache.
The entry cache mostly serves reads. It caches the entries in memory and allows fast concurrent read access.
The DBCache serves both reads and writes as it limits the disk IOs. But it is used by all database files ie the main database but also indexes. And one cannot control what goes in the cache and how it's loaded.
If all of your database files can fit into the DBcache and your disk subsystem tends to be the bottleneck, then you should favor this cache.
If all of your data can fit in the entry cache and search response time is your critical factor, then favor the entry cache.
If none works, you will need to balance between the 2 caches to get the overall best performances for your load.
Regards,
Ludovic.
# 4
Thank you for everyone's input so far.
You have affirmed my hypothesis about clockspeed being king for a situation like this.
On the T2k, using Directory Manager, I cannot get faster than 17ms performance.
The ACI challenge that we have is significant since they are never going to be reduced, they will always be there, and even proliferate further.
If I could get sub 30ms response with a regular user who has to have ACI's evaluated, that would be fantastic....but maybe a pipe dream, i'm not sure.
I'm expecting portal server to be a significant hit on directory since the portal desktop profile is stored in the directory as base64'd XML...which at times can be quite heavy.
As for index caches, running the access manager tunings it recommends about 2.5x the physical index footprint present on the machine as the recommended cache level.
Is this unrealistically high?
C.
