跳转到主内容
NetApp adopts Microsoft’s Business-to-Customer (B2C) Identity Management
Effective December 3 - NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources. For accounts that did not pre-register (prior to Dec 3) access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity. To learn more, Read the FAQ and Watch the video. Need assistance? Complete this form and select “Registration Issue” as the Feedback Category. 

由于 I/O 未对齐、数据库日志记录是什么?

Views:
17
Visibility:
Public
Votes:
0
Category:
data-ontap-7
Specialty:
perf
Last Updated:

适用场景

ONTAP OS

问题解答

关于 NetApp Filer 的性能问题、文件管理器性能降低的常见原因之一是部分写入。Data ONTAP 和 WAFL 通常可以快速完成用户写入请求、因为一旦写入 NVRAM ,写入请求就会成功存储。此操作通常需要不到 1 毫秒的时间、可为 NAS 和 SAN 用户提供快速写入性能。

这假设写入请求从 4K WAFL 块边界开始、可被 4K 整除、大小不小于 4K 。未满足此标准的结果是部分写入、包括读取、与数据读取一起写入的数据合并、然后将结果写入新块。此过程可能导致写入在其他情况下挂起、从而增加操作处理时间并增加延迟。

 

部分写入的常见源是 LUN I/O 未对齐未对齐 I/O 的指示符是tats perfstat_lun在 perfstat 部分的写入对齐直方图中找到的 LUN 。

OEM 注释 

有关未对齐的 I/O 的详细信息,请参见 KB :什么是未对齐的 I/O ?

本文旨在讨论 MS SQL (或其他数据库)日志写入导致 I/O 不对齐的情况,以及确定它们是否影响存储器性能的方法。 

这种类型的 I/O 通常被视为写入方式,写入方式可以包含多个非 0 存储桶、其中的一定百分比write_partial_blocks也可以: 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.0:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 1:4% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.2:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 3:6% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.4:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 5:57% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo. 6:21% 

lun:/vol/sql_log/lundggtHJeWTKaT:write_align_histo.7:0% 

lun:/vol/sql_log/lundggtHJeWTKaT:read_partial_blocks: 4% 

lun:/vol/sql_log/lundggtHJeWTKaT: write_partial_blocks:6%

 

通常,如上所示的直方图会被错误解释为未对齐的 LUN ,但对 LUN 类型的进一步调查将显示 LUN 是主机应用程序的正确类型。事实上,上述模式在数据库日志应用程序中很常见。在这种情况下、在讨论 MS SQL Server 事务日志记录时、这些主体可能也适用于其他数据库应用程序和其他工作负载。

 

本文用于回答在这种情况下经常出现的问题:

 

“当 LUN 类型正确且主机端的正确对齐已得到确保时,为什么此 LUN 上存在未对齐的 I/O ?”

 

在此示例中,将考虑使用 Windows 2008 服务器。NetApp LUN 类型应为 windows_2008 。对于在此 LUN 上创建的 NTFS 文件系统的 I/O 应自动对齐,因为启动偏移将默认更正、 NTFS 使用系统缓冲缓存、确保写入操作可被 4K 整除。

 

因此,如果 NTFS 能够确保正确对齐写入、 SQL Server 如何登录此 NTFS 分区会导致 I/O 不对齐?

 

答案是、 Windows CreateFile 函数提供FILE_FLAG_NO_BUFFERING了在读取或写入文件时禁用此系统缓存的标志。当前可用的 SQL Server 版本使用此标志、并且不会始终关注对齐问题、因此写入可能会不一致。有关此标志的详细信息,请参见 Microsoft 有关文件缓冲的文章。

 

虽然 SQL Server 事务日志记录可以创建未对齐的 I/O ,但并不一定会对文件管理器的性能产生重大影响。例如,下面的图示涉及一个由一批 SQL 日志组成的 512K SAN 块的写入:

 

SAN

 

: 512k SAN 写入占用 128k WAFL 块。如果 SAN 块未对齐、从 WAFL 块的中间开始、如上述操作中所示、从第一个 WAFL 块的第 5 层开始、则认为该操作未对齐、此操作将显示在write_align_histo.5(第 5 层)中。此外,用于服务此请求的第一个和最后一个 WAFL 块将是部分写入。但是,在这种情况下、对于这两个部分块、有 126 个非部分块、因此此方案的影响很小。

 

在评估写入对齐直方图时,应考虑 LUN 的平均操作大小。根据上述情形、较大的操作大小应比较小的操作大小产生的影响更小。

 

为了确定实际对文件管理器的影响程度、请观察 WAFL_SUSP-W 中的以下统计信息:

 
  • pw.over_limit 是wp.partial_write计数超过时发生的次数partial_write_limitpartial_write_limit曾经固定为 50 个、但在较新版本的 Data ONTAP 中、它依赖于平台。
  • WAFL_WRITE 是wafl_write文件管理器在迭代期间接收到的实际新消息数。
 

虽然pw.over_limit wafl_write新邮件之间的关系不是绝对的、但根据经验可以通过计算pw.over_limit与新WAFL_WRITE邮件的比率来确定影响。

 

例如:

pw.over_limit = 90145

 

WAFL_WRITE (from â??New Messagesâ?? section) = 603444

 

90145 / 603444\xa0= .15 or 15%

 

在这种情况下,每 100 个新 WAFL 写入中大约有 15 个必须同步读取块才能合并数据以完成写入,而只是将数据写入 NVRAM 。虽然 WAFL 在不阻止写入确认的情况下将异步处理少量部分写入、但一旦 WAFL 有 50 多个未完成的部分写入、它就会开始同步处理这些操作、这会显著增加完成写入所需的时间。pw.over_limit这些写入由计数器反映。上述百分比越高、就越可能对性能产生影响。要使性能影响达到一定的百分比的高程度取决于任意数量的因素、因此pw.over_limit/wafl_write '无法声明高水印。

追加信息

附加信息 _text