Windows存储子系统性能分析

102 浏览量更新于2024-07-14 收藏 528KB PDF 举报

"Windows - Disk Subsystem Performance Analysis (March 2004)" 是一篇关于分析运行Windows 2000、Windows XP或Windows Server 2003系列操作系统的计算机存储子系统的性能分析报告。这篇论文旨在探讨在硬件和软件层面的性能表现，并提供了存储子系统分析和设计的工具，以及解决特定配置中性能瓶颈的规则和指南。本文从以下几个方面进行了深入讨论： 1. **引言**：简要介绍论文的目的和范围，强调分析存储子系统性能的复杂性，因为每个系统设计者或管理员可能面临不同的硬件配置和软件工作负载。 2. **定义和术语**：为了确保读者对讨论内容的理解，文章首先定义了关键的存储相关术语，这对于后续的分析至关重要。 3. **应用程序特征和考虑**：这部分分析了不同类型的应用程序如何影响存储子系统的性能，包括简单工作负载的特点、数据布局和冗余策略等。 4. **简单工作负载特征考虑**：讨论了不同工作负载（如读写操作比例、随机和顺序访问模式）如何影响存储子系统性能。 5. **数据布局和冗余考虑**：解释了数据在存储设备上的组织方式（如JBOD - Just a Bunch Of Disks）对性能的影响，以及冗余策略如RAID（冗余磁盘阵列）的不同级别（RAID-0、RAID-0+1、RAID-5）。 6. **通过复制实现的冗余**：详细介绍了如RAID-1和RAID-0+1这样的冗余技术，它们通过磁盘镜像来提供数据保护。 7. **通过旋转奇偶校验实现的冗余**：这部分可能涉及到RAID-6或者更高级别的冗余技术，这些技术在提供数据冗余的同时，能够容忍更多的磁盘故障。 8. **磁盘阵列的权衡**：分析了各种RAID级别的性能和冗余之间的折衷，例如，RAID-0提供高性能但无冗余，而RAID-1提供冗余但牺牲了存储效率。 9. **性能测试和分析工具**：论文还涵盖了用于监控和分析存储子系统性能的工具，这些工具对于识别和解决问题至关重要。 10. **系统设计和优化指南**：提供了设计高效存储子系统的规则和建议，帮助系统设计者和管理员解决性能瓶颈问题。通过这篇论文，读者可以了解到如何评估和优化Windows环境下存储子系统的性能，从而提高整体系统效能并确保数据安全。

Disk Subsystem Performance Analysis for Windows — 6

have resulted in larger-numbered RAID labels without any change to the array data

layout or management strategy.

Reliability and Availability Terms

Reliability

Refers to issues of data loss or corruption. A storage subsystem is reliable if a

read request eventually returns (with very high degree of probability) the same

data sent to the media by the most previous write request to the same LBN (or

requests to the same LUNs).

Availability

Refers to timeliness in accessing data. A highly-available storage subsystem

continues to offer data access even if there are multiple hardware failures along

the path (or paths) between host and spindles.

Hot spare

An empty disk kept available for immediate inclusion into a failed array. That is,

it can quickly take on the responsibility of a failed mirror disk or a failed disk in a

RAID-5 array. The data that was on the failed disk is regenerated or

reconstructed from the remaining disks and placed on the hot spare, after which

array performance and reliability resume normal levels.

Application Characteristics and Considerations

Understanding application behavior is essential for both storage subsystem

planning and performance analysis. The better the workloads on the system are

understood, the more accurate the planning and analysis.

If possible, the system’s aggregate workload should be divided into the individual

contributors—applications, operating system background, backup requests, and so

on. Often they are directed at different pieces of the storage subsystem, which

makes them easier to separate. Each workload can be characterized using the

following axes of freedom:

 Read:write ratio

 Sequential/random (some measure of temporal and spatial locality)

 Request sizes

 Interarrival rates, burstiness, concurrency (interarrival patterns)

Each workload will most likely be composed of a mixture of sub-workloads—for

example, sequential 8K reads mixed with random 4K writes. This paper discusses a

number of tools available to help separate and characterize workloads.

Ideally, the aggregate system workload can be reduced to a set of individual

components, such as:

 Random 4K reads to the main database files, fairly constant during business

hours, 2000 requests per second

 Random 16K writes to the main database files, in bursts of 50–100 requests, 10

requests per second (on average)

 Sequential 8K writes to the database log file, fairly constant during business

hours, 100 requests per second

 Sequential 64K writes to the backup subsystem, constant from midnight to 1:00

a.m., 1000 requests per second

 Sequential 64K reads from the main database files, constant from midnight to

1:00 a.m., 1000 requests per second

Disk Subsystem Performance Analysis for Windows — 7

Such data combined with reliability, availability, and cost constraints can be used to

analyze an existing system or design a new one capable of meeting specific criteria.

This data can be refined even further if more detailed analysis is required. For

example, the individual distributions of locality, request size, and interarrival rates

can be tracked for each workload, rather than just mean values. However, the

correlations between the various characteristics compound the difficulty of the

analysis, so the typical system designer or administrator should focus on first-order

effects.

If workload characteristics are known in advance, whether obtained from empirical

data or detailed modeling, an understood hardware configuration can be evaluated

as to how it will perform under that workload. This section contains many guidelines

to aid in understanding the trade-offs made in designing and configuring a storage

subsystem to service a given workload while meeting specific performance,

reliability, availability, and cost criteria.

Simple Workload Characteristic Considerations

Read requests can result in prefetching activity at one or more points along the

storage path. In the case of sequential read workloads, this will usually provide a

performance advantage. However, for random read workloads, any prefetching

activity is wasted and might in fact interfere with useful work by delaying

subsequent request service or polluting any caches at or below the prefetcher.

Write requests can be combined or coalesced if a buffer or cache along the way

can collect multiple sequential writes and if the cache controller can issue a large

write request covering all of the write data. Completion status is returned in the

same manner as if all of the writes completed at the same time. That is, if the

individual writes at the coalescing point would normally have immediately

responded with completions to the issuing entities from that point, then they will still

do so. If they would have waited for completion confirmation from farther along the

path before responding, then they will wait until the completion confirmation comes

for the large (combined) write request. The typical scenario is a battery-backed

controller cache providing immediate completion responses and allowing long

streams of potentially-serialized small writes to be coalesced.

Caches are used to improve performance for both spatial and temporal locality.

Prefetching into a read cache is an example of a locality optimization; it assumes

that if LBN N is read, then LBN N+1 will probably be read soon. Write-back caches

provide a similar optimization, assuming that dirty data will either be overwritten

(temporal locality) or can be coalesced as adjacent LBNs are dirtied (spatial

locality). Write-back caches also allow disk requests to be reordered (or scheduled).

Disk schedulers are usually designed to reduce disk request service time, but other

criteria might be added to the scheduling heuristic, such as starvation avoidance or

prioritization of specific request types.

Request size is of particular significance in striped arrays and is covered in more

detail in “Stripe Unit Size” later in this paper. In some cases, Windows might divide

disk requests into 64K chunks.

Few systems experience a steady-state workload where the characteristics of the

requests do not fluctuate over time. Most systems experience bursts of activity and

idle periods, often tied to the 24/7 cycles of the work day/week. For example, the

activities performed online at a local bank can differ dramatically as the day

progresses: the bank staff first arrives in the morning, the bank opens its doors, the

lunch hour, the bank closes its doors, the bank staff leaves, and finally automated

剩余30页未读，继续阅读

weixin_38740328

粉丝: 4
资源: 863

Windows存储子系统性能分析

win7电脑一直弹出16 bit MS-DOS Subsystem

Simulink高级仿真技术 s-function subsystem

Hospital--Subsystem-document.rar_hospital_系统文档_药品管理 C#

Windows-Subsystem-for-Linux-2-WSL-2-Tips-Tricks-and-Techniques:Packt发布的Windows 2 Linux子系统（WSL 2）技巧，窍门和技巧

AS400资料（5）------Separation ODBC jobs into user-defined subsystem.zip

Lost-and-Stolen-Device-Subsystem-Frontend

Device-Registration-Subsystem-Frontend

Device-Verification-Subsystem-Authority-Frontend

积分java源码-Astronomer-Subsystem-Rewrite:天文学家-子系统-重写

Museum-News-CollectionAnalyze-Subsystem:博物馆新闻采集分析子系统

最新资源