PDA

View Full Version : Optimizing Disks


FullOfLove
12-17-2007, 09:00 PM
The reason for this is that performance under different cluster sizes is directly related to the average file size on the volume; for example, you may find that larger cluster sizes deliver better performance than smaller ones or vice versa. However, you should always experiment thoroughly before committing to a custom cluster size choice. The nice thing here is that if you choose to just go ahead with NT’s default size and not bother, you’ll still get good performance. The major benefit of smaller cluster sizes is that there is less disk space wasted; it’s unlikely that you’ll see large performance differences between different cluster sizes.

NTFS COMPRESSION
Another important feature of NTFS, which was new with Windows NT version 3.51, is the ability to selectively compress individual files and folders on a disk. Although most people think of compression strictly in terms of disk space savings, you might be interested to know that compression can also have major performance benefits. However, these benefits come at a price: CPU utilization.

In our lab experimentation with NTFS compression during the writing of this book, we tested a number of machines with and without NTFS compression. On smaller volume sizes (generally sub-2GB non-RAID volumes), we were amazed to discover that volumes using NTFS compression delivered overall performance increases of up to 50 percent. It seemed too good to be true until we simultaneously monitored CPU utilization during a subsequent run of the same benchmarks using a compressed NTFS volume. We saw average CPU utilization on these tests jump from a mild 10–18 percent range on the uncompressed NTFS volume tests to a whopping 30–80 percent range on the compressed NTFS volume tests. Therein lies the rub. Additionally, we saw major performance decreases when using NTFS compression on large volume sizes (between 4GB and 17GB) and software-based fault-tolerant RAID volumes (which already incur a CPU hit due to the RAID redundancy operations).

To summarize, you can significantly increase disk performance using NTFS compression in some cases on smaller volume sizes, but you’ll likely do so with a significant hit in CPU utilization. However, this effect might be tolerable on systems with extremely fast processors or multiple installed processors. As always, it is recommended that you test this feature on a nonproduction machine to experiment with it prior to deploying it “live” in your environment.

If you do choose to employ compression on your NTFS volume, you’ll be glad to know that compression can be done on a selective basis. In fact, NTFS compression goes down to the file level, meaning that you can compress individual files and directories on a case-by-case basis; you don’t have to compress the entire volume as is the case with compression methods used by other operating systems. However, if desired, you can also compress an entire NTFS volume simply by compressing the volume’s root folder. With NT 3.5x, you compress files and folders with File Manager. In NT 4.0, you select a file or folder’s Properties dialog by right-clicking on the file or folder and choosing Properties.

TIP: To compress an entire drive, open the My Computer (http://www.windowsitlibrary.com/Content/435/07/8.html#) desktop folder, right-click on the NTFS volume to be compressed, and choose Properties. In the dialog that appears, check the Compress <drive:> box and choose OK. You will be asked if you wish to also compress all the subfolders of the drive as well; if this is the case, choose Yes. Otherwise, only the root folder of the volume will be compressed.
Figure 7-19 (http://www.windowsitlibrary.com/Content/435/07/files/fig7_19.html) is an example of the dialog to compress an NTFS volume.

Figure 7-20 (http://www.windowsitlibrary.com/Content/435/07/files/fig7_20.html) is an example of the dialog to compress an individual folder on an NTFS volume.

You can also compress a file or folder with the command-line utility COMPACT.EXE. The command format to do this is: COMPACT [/c | /u] [/s[:dir]] [/a] [/i] [/f] [/q] [filename [...]]

NOTE: When used without any command-line parameters, COMPACT displays the compression status of the current directory and any files it contains. You can also use multiple filenames and wildcards (however, you must put spaces between multiple parameters).

NTFS TUNING
In addition to what has been described elsewhere in this chapter, there are a few other things you can do to optimize the performance of NTFS volumes. Specifically, there are several Registry modifications you can make to disable certain features of NTFS that may not be necessary in your environment.

The first such modification is a system change that disables NTFS’s automatic creation of MS-DOS style 8.3 format “short names” for files stored on NTFS volumes. As you probably know, Windows NT supports the use of long filenames on both NTFS and FAT volumes. In both cases, NT automatically creates a short name version of each file stored on a volume in 8.3 naming format. This maintains compatibility with 16-bit operating systems and applications that access the volume (such as MS-DOS, Windows 3.x, Windows for Workgroups, and applications that run under these operating systems). However, this procedure also incurs additional write overhead to add the second Master File Table entry for each file and directory. With NTFS volumes, it is possible to disable this automatic name generation via a Registry modification (there is no such equivalent for FAT volumes).

You may want to consider making this modification if your network is in pure 32-bit networking environment with 100 percent 32-bit operating systems and applications. To enable this change, open one of the Windows NT Registry Editor utilities and locate the following key and value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\FileSystem Value: NtfsDisable8dot3NameCreation

Default Data: 0 (false)

To disable 8.3 short-name generation, set the data for this value to 1.

There are several important points to remember if you’re considering making this change. First, be very sure that your network does not now contain, and will not in the future contain, any systems that use DOS, Windows 3.x, or Windows for Workgroups 3.x. These systems cannot use files on an NTFS volume without 8.3-style names. Also, be aware that using 16-bit applications (e.g., MS-DOS or Win16 applications) on an NTFS volume without 8.3 names may cause application incompatibilities or crashes. Finally, be aware that changing this Registry value affects only future files stored on the volume. Existing files retain their previously created 8.3 version names until you remove the files from the volume. If you want to start with a clean slate, you’ll have to set the Registry value to 1, move all the files to another volume or tape, and then move the files back to the original volume.

CAUTION: Disabling NTFS 8.3 short-name creation on a Windows NT 3.51 Server running Microsoft Exchange Server (http://www.windowsitlibrary.com/Content/435/07/8.html#) may prevent Exchange Custom Forms from working properly. If you are using these products in this configuration, it’s recommended that you leave 8.3 name creation enabled.
In addition to the 8.3 name generation feature, there is one other Registry modification that we can make to create some improvement in NTFS’s performance. A value named NtfsDisableLastAccessUpdate controls whether NTFS updates the LastAccess time/date stamp on directories as NTFS traverses the directory structure. Disabling these last access updates can reduce NTFS’s overhead without significantly impairing functionality. The default value is 0 (NTFS updates directory time/date stamps); change the value to 1 to disable updates. If you don’t see the NtfsDisableLastAccessUpdate value listed, you can manually add it as a REG_DWORD value and then set the value’s data as 1. However, if you add it, be very certain to spell the value name correctly including capitalization.

DISK FRAGMENTATION AND OPTIMIZATION

One of the most important practices in maintaining a well-optimized disk subsystem under any operating system is minimizing the level of file fragmentation that exists on the system’s various drive volumes. This can be accomplished by regularly running a disk defragmentation utility that defragments – that is, makes contiguous – every file on the volume. In addition, these utilities are also capable of defragmenting the free disk space on the volume, which is also beneficial to improving volume performance.

Fragmentation adversely affects performance because additional head and platter movements are required to access a file which is stored in multiple, noncontiguous locations on a disk. On the other hand, when a file is contiguous, it can be read sequentially in one long burst without requiring additional drive re-positioning.

To maintain optimal disk performance on your Windows NT system, you should regularly run a disk defragmentation tool. The frequency of this process should be proportionate to the level of disk usage on the machine; that is, heavily-accessed network servers should probably have this process run once per week at minimum, whereas workstations with relatively light disk usage may be fine with a monthly or semimonthly disk defragmentation. You can use the disk fragmentation analysis tool included with your defragmentation software to determine the level of fragmentation that currently exists on each volume.

Figure 7-21 (http://www.windowsitlibrary.com/Content/435/07/files/fig7_21.html) shows a Windows NT disk defragmentation utility at work.

COOL PRODUCT TIP: At the time of this writing, there are three commercial disk defragmentation utilities available for Windows NT (http://www.windowsitlibrary.com/Content/435/07/8.html#): Executive Software’s Diskeeper for Windows NT, Norton Speedisk, part of the Norton Utilities for Windows NT available from Symantec Corporation, and Perfect Disk NT by Raxco Software. Information on Diskeeper can be found on Executive Software’s World Wide Web site at: http://www.execsoft.com/ Information on Diskeeper can be found on Executive Software’s (http://www.windowsitlibrary.com/Content/435/07/8.html#) World Wide Web site at: http://www.execsoft.com/ Information on Perfect Disk NT can be found at Raxco’s Web site at: http://www.raxco.com/
ON THE CD: Diskeeper (http://www.windowsitlibrary.com/Content/435/07/8.html#) by Executive Software, the original disk defragmentation utility for Windows NT, is an excellent disk defragmentation tool that works with both FAT and NTFS volumes. Diskeeper also includes a handy disk fragmentation analysis tool, which informs you about the current level of file fragmentation on each of your disk volumes. Diskeeper Lite, the shareware version of Diskeeper, is included on the Optimizing Windows NT CD-ROM. To install the software, follow the directions outlined in Appendix A, “What’s On the CD?,” or point your Web browser to the location of the Optimizing Windows NT CD-ROM in your system and follow the links to install the software.
TIP: When running disk-related benchmarks on your system, don’t forget to run a full file and free space defragmentation before each benchmark test iteration. Otherwise, varying levels of fragmentation may affect your tests and produce skewed or misleading results.
►Source: http://www.windowsitlibrary.com/Content/435/07/8.html

FullOfLove
12-17-2007, 09:21 PM
One of the most important components in Windows NT system performance is the paging file. The paging file, as you know from Chapter 5, serves as virtual memory and is used to swap pages to and from memory to balance the use of physical RAM between various processes on the system. The paging file provides supplemental memory to physical RAM and is used as part of Windows NT’s total memory address space. However, because it is disk-based memory and not actual physical RAM, the paging file is exponentially slower than real RAM and can become a performance bottleneck when it is heavily used by the system.

As a result, one of the most important things we can do in optimizing a Windows NT system is to ensure that we are achieving maximum performance from the paging file. Although job #1 in optimizing a Windows NT computer is to ensure that paging file activity is at a minimum (which basically means that there is plenty of memory available on the system), any Windows NT system, regardless of the amount of installed physical memory, is going to experience some degree of paging file activity (due to the construction of NT’s Virtual Memory Manager). However, we certainly don’t want to exacerbate a memory bottleneck with a slow paging file! Even on systems with plenty of memory, we want to be sure that the paging file isn’t slowing us down unnecessarily.

XREF: For information on detecting memory bottlenecks and the Windows NT paging file, see Chapter 5, “Optimizing Memory and Processing.”
Because the paging file is stored on one or more system volumes, the volumes themselves become a factor in paging file performance (and therefore, in overall system performance when paging file activity occurs). This means that to properly optimize the paging file, we must consider the following about any volume that stores the paging file:
File system: Is the NTFS or FAT file system used on the volume(s)?
Volume location: Is the volume on a physical disk with many partitions (and therefore a potentially high degree of activity), or is the sole volume on the physical disk?
How many physical disks are available containing free space that we can utilize for the paging file? GENERAL PAGING FILE CONFIGURATION TIPS
The first thing we can do to optimize paging file performance is to spread the file across multiple physical drives. Using more than one physical drive for the paging file provides multiple disk spindles that can be accessed by the operating system simultaneously; this translates to better paging file performance. However, to truly leverage the performance possibilities of using multiple drives, these drives should ideally be SCSI, because SCSI drives are better equipped to utilize NT’s asynchronous I/O capabilities than are (E)IDE drives. It is still advantageous in most instances to use a combination of SCSI and IDE drives if present in the system, and even the use of multiple IDE drives may yield better performance than a single drive. To determine which is best for your environment you need to do some experimentation and run benchmarks to evaluate the performance of each configuration.

NOTE: When using multiple drives for the paging file, be sure that you use multiple physical drives and NOT multiple logical drives on the same partition, because using multiple logical drives on the same partition won’t yield any performance benefits.
The Windows NT paging file is configured via the System Control Panel’s Performance tab. This dialog allows you to define a paging file on one or more drives and to set the minimum and maximum sizes on each volume.

Figure 7-22 (http://www.windowsitlibrary.com/Content/435/07/files/fig7_22.html) shows this configuration dialog.

In this dialog, we set the minimum and maximum size for the paging file on each partition to the same size. Preventing NT from dynamically adjusting its size by setting the same minimum and maximum size for the paging file is another method for improving paging file performance. This prevents the paging file from becoming fragmented (a natural result of being extended and reduced), a condition that slows the paging file’s performance. When configuring the paging file in this manner, you should ensure that the total size of the paging file is at least the minimum recommended size as displayed in the paging file configuration dialog box. Although the downside of doing this is that it will use more disk space (because it doesn’t allow NT to dynamically increase the file on an as-needed basis), it will prevent page file fragmentation and thus optimize its performance.

TIP: Although Windows NT will generally recommend a paging file size of physical RAM + 11MB, if disk space permits you should consider making the paging file 150 percent of physical RAM size. This will provide a higher ceiling in the event of extremely heavy paging usage, and act as a hedge against situations where physical memory is increased but a corresponding increase in the paging file size (which should coincide with such a change) is inadvertently omitted.
Creating a paging file that is guaranteed to be unfragmented requires that you either (1) have (or create) a new partition with a fresh format or (2) run a disk defragmentation program on a nonpaging file volume to defragment both files and free space on the volume. Once you’ve done this, you’re ready to create the paging file in the contiguous free space you’ve created.

To create a new, unfragmented paging file on a newly formatted volume or a fully defragmented volume, follow these steps:
Open the Performance Tab of the System Control Panel (Note: in NT 3.5x, you should instead choose the Virtual Memory button).
Select a new partition on which to locate the paging file.
Using the dialog, set the minimum and maximum paging file sizes to the same value (preferably greater than or equal to the recommended size listed) and click Set to commit the changes.
Next, select the existing paging file and set the minimum and maximum paging file sizes to zero; then choose Set to commit the changes.
Shut down and restart the system as instructed; when you reboot, the paging file should be contiguous. Another important aspect to paging file performance is the activity of the drive(s) used for the paging file. When selecting a drive (or drives) for the paging file, make sure that the drive is one that isn’t heavily bogged down with other system tasks. This helps balance the load on the disk subsystem and ensures the paging file receives faster servicing by the disk subsystem. If possible, place the paging file on its own dedicated partition with little or nothing else on the partition (or at least no data that is actively referenced by the system or applications on a continual basis). This eliminates the possibility of contention with other system processes accessing the disk, ensuring the fastest possible access to the paging file.

The only other thing you can do to further optimize paging file (other than increasing the speed of the disk hardware involved) is to place it on a RAID 0/striped set volume (a single logical volume consisting of two or more equally sized partitions across multiple physical disks). Although at first it may seem somewhat decadent and unnecessary to do, systems with heavy paging file usage may benefit greatly from this type of configuration.

TIP: If you do decide to place the paging file on a dedicated partition and are concerned about wasting disk space, consider placing static files that receive minimal access on the same volume. For example, you might place data such as hardware support files or even the contents of the Windows NT CD-ROM (or a portion of it) on this partition. The key criterion for the files you place here is that they be infrequently accessed files that are usually accessed in a read-only fashion. This will make better use of disk space on the volume and will not create contention with paging file access.
The last general tip regarding the paging file relates to the type of file system volume(s) you store the paging file on. Microsoft recommends placing the paging file on an NTFS partition. However, except in cases where this is necessary for security reasons, we recommend that you place the paging file on FAT volumes for maximum performance. Because FAT is generally faster than NTFS on smaller volume sizes, placing the paging file on a smaller, dedicated FAT volume will yield faster performance than placing it on a comparable NTFS volume. Again, this recommendation assumes that the volume(s) used are under 2GB in size where FAT maintains a performance advantage over NTFS.

TIP: You should never place your paging file on a stripe set with parity (RAID 5 (http://www.windowsitlibrary.com/Content/435/07/9.html#)) volume, because doing so will degrade its performance. If you want to place the paging file on a fault-tolerant volume, choose a mirror set (RAID 1) volume instead.
DEFRAGMENTING THE PAGING FILE
Although we’ve discussed ways to prevent paging file fragmentation (namely, setting the minimum and maximum size to the same value when creating the file on a new or fully defragmented partition), you may be in a situation where the paging file is already fragmented. For example, you may have already created your paging file, in which case setting the minimum and maximum sizes equally may not create an unfragmented paging file (i.e., the file is already fragmented or there is insufficient contiguous disk space to create a new, contiguous paging file). Another possibility is that you have disk space limitations that prevent you from setting the minimum and maximum paging file sizes to the same value; as a result, your paging file becomes fragmented over time as it expands and reduces in size.

In any case, it is possible defragment the paging file using a special procedure. However, as you might have already guessed, defragmenting the paging file using this procedure requires access to a commercial disk defragmentation utility (Executive Software’s Diskeeper Lite is included on the CD and can be used for this purpose). We can’t just run the defragmenter and have the paging file be automatically defragmented along with the volume because the file is constantly in use by the system and therefore cannot be fragmented. The following procedure allows you to defragment the paging file using a roundabout method.

This method requires at least two partitions and adequate free space to install a second, temporary copy of Windows NT.

To defragment an existing paging file, follow these steps:
Install a second, temporary installation of Windows NT in a separate directory. If possible, this should be a partition other than the one(s) containing the existing fragmented paging file.
Boot the temporary installation of Windows NT.
While booted under this temporary copy of NT, set the paging file location for that installation of Windows NT to a volume other than the one containing the paging file for your original Windows NT installation.
Install a commercial disk defragmentation utility on the system.
Rename the original fragmented paging file, called PAGEFILE.SYS and located in the volume’s root folder, to another name of your choosing (e.g., PAGEFILE.ORI.)
Defragment the partition where the original fragmented paging file (now renamed) exists. This will defragment not only that volume but the paging file as well.
Rename the now defragmented original paging file back to PAGEFILE.SYS.
Reboot your system back into your original Windows NT installation (assuming the system boots properly, it is now also safe to remove your temporary second copy of NT). Directory optimization
In addition to optimizing files, volume free space, and the paging file, there is one other disk entity that you may wish to optimize: the directory. The directory is basically a database of all of the files and folders on a volume, including information such as the starting and ending cluster for each folder and file.

Like these other entities, a volume’s directory becomes fragmented over time as many folders and files are created, modified, and deleted. Because the directory is constantly being updated, it is beneficial to have it be as unfragmented as possible. In addition, it is also beneficial to move the directory to the outside of the disk’s platters, because it is always preferable to have frequently accessed data on the outside of the disk’s platters.

The reason for this preference is simple: the outside of a disk has a higher rotational rate, and therefore a faster data transfer rate than the inner parts of the disk. If you don’t believe us, try this experiment: go to your local playground and stand on one of those spinning carousels, first sitting on the inside, and then the outside. You’ll quickly see which makes you feel more seasick.

As a result of this phenomenon, it would be ideal if we could move the directory to the outside of the disk where the performance is faster. However, there is no easy way to do this, because under NT even defragmentation utilities aren’t allowed to move the directory; doing so risks data corruption and isn’t supported by the operating system. However, if you are really interested in optimizing a volume’s directory, there is a method to accomplish this. Although it’s somewhat tedious to implement, it does work.

Source: http://www.windowsitlibrary.com/Content/435/07/9.html

Main book content: http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID=435

amg99999
12-17-2007, 10:18 PM
Tiếng anh làm sao mà hiểu được cho xin 500đ tiếng việt với thanks sờ kiu!!!