cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Previous day (Jan 23, 2006) | Main | Next day (Jan 24, 2006) »

Tuesday January 24, 2006

Frequently-Asked Questions #1: Size Limits

This is the first entry in a series of answers to what I consider frequently-asked questions about the Directory Server. These are questions that I see repeatedly from customers on internal mailing lists, or hear directly from customers. They may run the gamut from simple to complex, and some of them may be RTFM-type questions. Nevertheless, I figured it would be a good idea to answer them here so that when they're asked again we can point them to this information (i.e., RTFB) rather than having to craft the same response every time.

Q: Are there any size limits in the Directory Server? What's the largest attribute name you can use? What's the largest attribute value? What's the largest entry? What's the largest number of values you can have for an attribute? How many entries can you have?

A: In general, there is no hard-coded limit for any of these. Some directory servers do have hard-coded limits, so it is a legitimate question. But for all practical purposes, there isn't much of a realistic limit that you will encounter. But there are some operational limits that may need to be tuned in a few cases.

The first such limit is the maximum size of a request that the server will handle. This is controlled by the nsslapd-maxBERSize attribute in the cn=config entry (by default, this isn't present, but a value of about 2MB will be enforced). The Directory Server will immediately reject any request that it receives which will be larger than this amount and terminate the connection to the client. This limit is enforced as a means of helping to prevent denial-of-service types of attacks in which the client tries to consume bandwidth and memory that could otherwise be used for handling other requests. The default 2MB limit is fine in most normal directory uses, but there are occasionally times when it might be a little too small. One common case would be a static group with a very large number of members (e.g., at least in the hundreds of thousands). Another case is that in which an entry might need to store large blobs of data (like statistics collected by SLAMD). In these cases, increasing the value of the nsslapd-maxBERSize configuration attribute (which does require a restart to take effect in current versions) will allow you to store larger amounts of information.

If you do increase the maximum request size, then the next limit that you may encounter will be that of the transaction log file size, which is controlled by the nsslapd-db-logfile-size attribute and is 10MB by default. You may not have a single entry that is greater than the transaction log file size, so if you expect to have entries that are larger than 10MB, then you may need to increase this setting. Note, however, that if you already have one or more transaction log files with the old size (which will always be the case if you've got an existing database, and you should *NEVER* delete these files), then the database will continue to use this size. Therefore, if it is necessary to increase this limit, then you will need to export all database contents to LDIF (in all backends), change the configured size, remove all existing database contents, and re-import from LDIF.

If you get beyond the transaction log file size, then the next limit that you should encounter would be the largest single ASN.1 element that the server can handle, which is constrained by the size of a 32-bit signed integer (2GB minus one byte). This limit isn't going away any time soon, but in the unlikely case that you do have entries that need to be larger than 2GB in size, then you'll have to split them up in some way.

All of the above are related to the maximum size of an entry (and therefore, the largest size of any component of an entry), but have no impact on the maximum number of entries that can be held in the server. At present, the maximum number of entries in any one backend is limited by the 32-bit entry ID (less a few special values that have particular meanings), so you will not be able to have more than 4,294,967,292 entries in any one database. At present, we don't have any customers even close to that limit, but if it did become a potential issue, then it would be posible to split the entries into multiple backends to circumvent this constraint. In the future, we will likely be using 64-bit values for the entry ID so that this will not be an issue.

Posted by cn_equals_directory_manager ( Jan 24 2006, 09:39:16 AM CST ) Permalink Comments [2]