Friday Nov 21, 2008

List of Supported Cyphers in DSEE

Need to know the list of supported cyphers in Directory Server Enterprise Edition? Use the following command:

dsconf get-server-prop ssl-supported-ciphers

Friday Oct 24, 2008

DSEE Release Notes

Where to find the information about platform support for DSEE: Release Notes.

Technorati Tags:

Monday Aug 18, 2008

Reference tuning architecture - Directory Server running on small systems

Following is an effective reference tuning architecture for servers with insufficient physical memory to cache the entire Directory Server database in database cache and entry cache(s).

Directory Server uses a single database cache for all entries in the database, that is, db/\*/\*.db3 files, and one entry cache per backend. The database cache is a copy in pages of the .db3 files, the entry cache is essentially a hashmap of entries formatted to return to the LDAP client. The best possible performance occurs when the entry being searched for is in the entry cache and can be returned immediately to the client. The worst possible performance occurs when Directory Server must read a page containing an entry from disk and the page is not in the file system buffer cache.

Referring to the diagram below, when an LDAP client issues a search, Directory Server examines the entry cache for the entry and returns the entry if found. If the entry is not in the entry cache, Directory Server examines the pages in the database cache for the entry. If the entry is found in the database cache, the entry is formatted, placed in the entry cache, and returned to the client. If the entry is neither in the entry cache or the database cache, then Directory Server must issue a disk read to read the page containing the entry - assuming it exists - into the database cache, then format the entry for the entry cache, then return the entry to the client. If the page containing the entry is not in the filesystem buffer cache, then that page must be read from disk.

Dscaching

In some large databases, all entries cannot be cached in database cache and entry cache. When all entries cannot be cached, tuning efforts should concentrate on reducing disk I/O on search operations. This is accomplished by caching the database file pages in the file system buffer cache as follows: set segmap_percent in /etc/system to accommodate the database, reboot the server, and prime the file system cache with dd, set database cache and entry cache sizes to something reasonable, perhaps 2GB each - the database cache size will help with updates. Directory Server response times should be excellent in this scenario. To determine the amount of memory needed for the file system cache, sum the number of bytes in all the db3 files in the database and multiply the result by 1.2 (20%). This is easily done with ls and awk:

ls -l db/\*/\*.db3 | awk '{ total += $5; } END { print total \* 1.2; }'

I/O caused by Directory Server reading data from disk can have a negative impact on Directory Server response times. Not only can response times be elevated, the response times are subject to a greater correlation of variation, i.e., response times are "spiky". The following graph shows the results of a 40 minute test run against Directory Server 5.2 patch 4 under extreme load, with the nsslapd-db-home-directory set to a local filesystem:

Baseline 40Min Spikes

in the diagram above, disk service times on the filesystem containing the mmap backing files averaged above 500 ms.

Change the nsslapd-db-home-directory to a tempfs filesystem, restart Directory Server, and run a new test. After restarting directory server, there will be a short "caching" period as the database cache and entry cache are filled, resulting in:

Beforeprime

The gradual increase in average response times up to about 1000 seconds into the test is the caching period. Immediately afterwards run the same job again and Directory Server begins to respond with very even average response times: this is because there is no I/O on search operations:

Afterprime

Technorati Tags: , , , , ,

Friday Aug 15, 2008

Cleaned up the tools & one liners article

The tools and one-liners wiki article was not served very well by its narrative nature. So I put all the tools and descriptions in and easy-to-read, side-by-side tabular format.

Technorati Tags: , , , ,

Thursday Aug 14, 2008

dseeEtimes.pl version 1.2 available

I have made a correction to the dseeEtimes.pl script. The correction is cosmetic and causes years to be displayed correctly. The tool is found at the dseeEtimes website.

dseeEtimes.pl provides a detailed analysis of Directory Server etimes.

Technorati Tags: , , , ,

Wednesday Aug 13, 2008

New content in the one-liners page

I've added the logconv.sh bash script to to the one-liner page. This script can be used to drive the analyzeDirectoryLogs.pl script, which will analyze the previous days' directory server access logs. I usually run all this out of cron.

Technorati Tags: ,

Thursday Jul 17, 2008

dsconf and dsadm docs

dsadm docs, dsconf docs.

Technorati Tags: , ,

Wednesday Jun 04, 2008

C SDK for LDAP

There have been some recent questions about the C SDK for LDAP. The main site is the Mozilla Wiki. Also, there are links to the documentation.

C-Sdk-Mozilla

Technorati Tags: ,

Tuesday May 27, 2008

RDBMS and Directory Proxy Server from DSEE6.3

Check this list for for databases supported for virtulization with Directory Proxy Server 6.3.

Technorati Tags: , , , ,

Tuesday May 13, 2008

segmap_percent, directory server, and file system cache

Remember to think about segmap_percent when you are considering using the Solaris file system cache for directory server.

EDIT: My friend Bill Hathaway reminded me of an excellent article at the Solaris internals wiki on the subject. Thanks, Bill.

Technorati Tags:

About

Sun, LDAP, SLAMD, DSLA, java, Struts, networking, chess, books, cooking, wine, and many other things.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today