跳转到主内容

NetApp_Insight_2020.png 

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

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

适用于

ONTAP 操作系统

解答

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

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

 

部分写入的常见源是 LUN I/O 未对齐未对齐 I/O 的指示符是stats 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 块的写入:

 

1002868-1.jpg

 

: 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