Slow file system performance in a directory with excessive files.
(Last modified: 19Nov2002)
This document (10021744) is provided subject to the disclaimer at the end of this document.
fact
Novell NetWare 5.x
Novell NetWare 4.x
Traditional NetWare Volume
Formerly TID 2917642
symptom
Slow file system performance in a directory with excessive files.
Deleting a file or group of files from a directory with 15,000 - 80,000 files in it takes forever.
With a large amount of files in a single directory, the performance of the server whenever it has to access this directory takes a BIG hit.
Users notice degraded performance when doing any kind of command that requires a look through the DET and FAT for the directory.
Searches that would normally takes less than 5 seconds, now require minutes to complete.
cause
The reason for this problem is rooted in DOS and the NCPs used by the clients. Whenever NetWare accesses a file in a directory, it uses the DOS commands to do it. DOS will do a "wild-card like" search of the directory (a flat-scan), looking at each and every file in the directory for a match. Even if the file NetWare is searching for is known (say from a database, or similar program), the entire directory is searched, including after the file is found.
For instance: If a server had 25,000 files in one subdirectory, and a "DIR TESTFILE.XFO" was typed at a client, then every one of the 25,000 files would be looked at, even if "TESTFILE.XFO" was the FIRST file in the FAT found in the search. The search will continue through the entire directory looking for further matches in each of the remaining 24,999 files.
This is the reason performance takes a huge hit. This is not a NetWare problem, it is a DOS limitation that NetWare is working with. This problem is never seen unless the number of files in a directory becomes large.
The Novell Client group is working to address this situation with different API calls on the client (all versions from 95-NT) that do not do a wild-card search of the entire directory structure.
fix
There are really only a couple of things that can be done to solve this problem.
#1. Decrease the amount of files in the directory. This is obvious, but is THE BEST and only real solution to this issue. By decreasing the amount of files in the directory, this problem will not be encountered. The best suggestion is to remove files until the server performance for that directory is satisfactory.
#2. For NetWare 4.x and 5.x there are 8 set parameters that can be "pegged" to give the best possible directory searching capabilities. These set parameters will not fix the performance issue, but it certainly will help ease the problem, and hopefully increase performance to a tolerable level.
Go to SERVMAN (4.X) or MONITOR (5.X) | SERVER PARAMETERS | DIRECTORY CACHING to change the parameters.
Here are some pointers on how to optimize the parameters -
Change every directory caching set parameter to the highest / lowest (depending on the set parameter) value allowed.
There are four parameters specifically that should be singled out (among the 8):
1. Directory Cache Allocation Wait Time:
This parameter tells the operating system how fast to allocate new directory cache buffers. This parameter should be set low; i.e., 0.1 sec. So, instead of waiting the default of 2.2 seconds before a new directory cache buffer is allocated, the server waits just 0.1 seconds.
2. Directory Cache Buffer NonReferenced Delay:
This parameter tells the operating system how often to flush out unused data in the directory cache buffers table. The default is 5.5 sec. This means that if after 5.5 seconds a piece of information in a directory cache buffer isn't used, it will be flushed. This cache buffer will then be made available for another piece of data to use. By setting this parameter high; i.e., 30 minutes, or 60 minutes, then these directory cache buffers will not be reallocated as quickly and can help to keep a large directory structure (50,000 or so files) cached for a great deal of time.
3. Maximum Directory Cache Buffers:
This is the upper limit on the number of directory cache buffers the OS can use for the caching of the directory structure on the ENTIRE server. These buffers are specifically designed to increase the speed at which basic file operations occur. Anytime a "dir" is performed, that entire directory is cached in directory cache buffers.
4. Minimum Directory Cache Buffers:
This parameter informs the server of the amount of directory cache buffers to start out with when the server is first started. By having this parameter at an amount where the server has been previously base-lined at, this will save on time allocating these buffers (see "directory cache allocation wait time"), and utilization.
#3. Update to the latest client available from Novell. The later clients have been known to fix many issues that the older client exhibited.
#4. Go into the directory which contains the files, and do a 'dir', or some other DOS command that will cause a 'search' of the entire sub-directory to take place. What this will do is force NetWare to cache most of the files from the fat for this directory in the server ram; i.e., directory cache buffers. Do the 'dir' command about 3 times and wait for it to finish the whole directory each time.
#5. Another option is to use a DOS emulator like Shell on the server. This can be much faster for operations such as deleting files. To use the Shell on the server type "LOAD NETBASIC" and then type "SHELL"
FYI: The NSS file system will not fix this problem. Although NSS does handle larger directories and more complicated structures with a more robust engine (read: faster), it still will give similar results if excessive files (or excessive directories) exist in one specific directory.
document
| Document Title: | Slow file system performance in a directory with excessive files. |
| Document ID: | 10021744 |
| Solution ID: | 1.0.39692410.2410040 |
| Creation Date: | 15Nov1999 |
| Modified Date: | 19Nov2002 |
| Novell Product Class: | End of Life NetWare Novell eDirectory |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.