How Services for Macintosh uses system resources in Windows Server 2003 (842355)

MORE INFORMATION

The File Server for Macintosh part of Services for Macintosh includes a service and a kernel-mode filter driver. To improve file sharing performance, the filter driver creates an index of all files and folders in the server's Macintosh volumes. This index contains one entry per file and is stored in paged pool memory. Additionally, Services for Macintosh makes one allocation in paged pool memory and one folder change notification object for each folder and subfolder on the volume.

When Services for Macintosh creates an index, Services for Macintosh makes a second allocation in paged pool memory and a second folder change notification for each folder and subfolder. These additional allocations are freed after the volume index has been created.

The index of a shared volume that has a small number or a medium number of files typically has a negligible effect on the server. However, if the volume is very large, its index may use so much paged pool memory that paged pool memory is exhausted. When this problem occurs, Services for Macintosh cannot share additional files or folders, and other operations on the server may not succeed. For example, you may not be able to use Remote Procedure Call or start new processes. Therefore, it is a good idea to estimate the effect that Services for Macintosh may have on the server.

The following sections describe the resources that are consumed by each file and folder on a Services for Macintosh volume.

File resource usage

To store an index, Services for Macintosh allocates paged pool memory in multiple 64 KB blocks. Services for Macintosh then fills each of these blocks with information about files and folders. The following table shows the number of bytes that are used for each file on the volume.

Number of characters in file name	Bytes used
1 - 8	120
9 - 12	128
13 - 20	144
21 - 32	168

Folder resource usage

The index entries for folders and subfolders are stored in the same paged pool memory blocks as the index entries for files. However, Services for Macintosh records slightly more information about folders and subfolders. The following table shows the number of bytes that are used for each folder and subfolder on the volume.

Number of characters in file name	Bytes used
1 - 8	140
9 - 12	148
13 - 20	164
21 - 32	188

Additionally, Services for Macintosh creates one NT executive folder change notification object for each folder and subfolder. These objects also share paged pool memory.

Finally, Services for Macintosh allocates 112 bytes of memory to track the notification object. In Microsoft Windows 2000, these bytes are allocated in nonpaged pool memory. In Windows Server 2003, these bytes are allocated in paged pool memory.

Resource usage during reindexing

When Services for Macintosh rebuilds an index, it allocates memory for file and folders as described earlier, and it makes two additional allocations for each folder and subfolder:

• One NT executive folder change notification object
• One additional 112-byte pool memory allocation

In Windows 2000, Services for Macintosh allocates these bytes in nonpaged pool memory. In Windows Server 2003, Services for Macintosh allocates these bytes in paged pool memory.

Capacity planning examples

In Windows 2000 Server, Services for Macintosh uses approximately 1 MB of paged pool memory for every 6241 files. (1,048,576 bytes per megabyte divided by 168 bytes per file equals approximately 6241 files.) Services for Macintosh uses 1 MB of paged pool memory for every 5577 folders. (1,048,576 bytes divided by 188 bytes per folder equals approximately 5577 folders.) Finally, Services for Macintosh uses 1 MB of nonpaged pool memory for every 9362 folders. (1,048,576 bytes divided by 112 bytes per folder equals approximately 9362 folders.) Therefore, if a Windows 2000-based server has 100 MB of paged pool memory and 90 MB of nonpaged pool memory available, Services for Macintosh may be able to use approximately 80 MB of paged pool memory and 60 MB of nonpaged pool memory to host approximately 1000 folders and 498,000 files. You can verify these figures by using the following calculations:

• 1000 * 112 = 112,000 bytes of nonpaged pool memory. (This value is not more than 60 MB.)
• 80MB - (1,000 folders * 188) / 168 bytes per file = 498,202 files.

If a Services for Macintosh volume has 200,000 files in 40,000 folders, it will consume about 39 MB of paged pool memory and 4.3 MB of nonpaged pool memory. You can verify these figures by using the following calculations:

• Paged pool memory:

  200,000 * 168 = 33,600,000
  40,000 * 188 = 7,520,000
  Total: 41,120,000 bytes = 39MB

• Nonpaged pool memory:

  40,000 * 112 = 4,480,000 bytes = 4.3MB

In Windows Server 2003, Services for Macintosh uses approximately 1 MB of paged pool memory for every 6241 files. (1,048,576 bytes divided by 168 bytes per file equals 6241.) Services for Macintosh uses 1 MB of paged pool memory for every 3495 folders. (1,048,576 bytes divided by 300 bytes per folder equals approximately 3495 folders.)

Note Because Windows Server 2003 does not use nonpaged memory, Windows Server 2003 does not require as much physical RAM as Windows 2000 Server requires.

Additional resource usage

In Windows 2000, the default paged pool memory size is 160 MB, but you can increase this size up to 491 MB. To do this, give the following registry subkey a value that is specified in bytes, and then restart the computer: For additional information about this subkey and its effect, click the following article number to view the article in the Microsoft Knowledge Base: In Windows Server 2003, the default paged pool memory size is 470 MB.

The following table illustrates the paged pool memory limit for the different operating systems.

Operating system	Default paged pool memory limit	Maximum paged pool memory limit
Windows NT 4.0	-	192 MB
Windows 2000	160 MB	491 MB
Windows Server 2003	470MB	-

For additional information about virtual memory, see Inside Microsoft Windows 2000 by David A. Solomon and Mark E. Russinovich.