性能诊断与调优FAQ-文件存储NAS-阿里云

本文介绍NAS SMB/NFS协议文件系统性能相关的常见问题及解决方案。

NAS的性能与存储容量之间的关系是什么？

通用型NAS
单个文件系统的读写性能上限（峰值）与文件系统的当前使用容量线性相关且成正比例关系，即使用容量越大，吞吐性能上限（峰值）越高。更多信息，请参见通用型NAS。
极速型NAS
单个文件系统的读写性能随配置容量的增长呈阶梯式增长。更多信息，请参见极速型NAS。

NAS的性能与目录大小之间的关系是什么？

在执行目录遍历操作时，以下情况可能导致响应速度变慢：

目录正在被修改：例如，创建、删除或重命名文件时，缓存可能频繁失效。
目录体量过大：对大目录执行目录遍历操作时，由于缓存淘汰导致响应非常慢。

解决方案：

避免目录体量过大，控制单目录下文件数量小于1万个。
执行目录遍历操作时，不要频繁对目录进行修改。
对于大目录遍历，若不需频繁修改，可考虑使用NFS v3协议挂载并添加nordirplus参数，以提升效率，请您验证后使用。

挂载参数对NAS性能有什么影响？

挂载参数对NAS性能有显著的影响，以下是挂载参数对性能的具体影响：

rsize 和 wsize：
- 影响：这两个参数定义了客户端与服务器之间数据交换的块大小。较大的块大小可以减少网络请求的次数，进而提高吞吐量，特别是在处理大文件时。
- 建议值：1048576（1 MB）。建议您尽可能使用最大值。较小的块大小可能导致更多的网络开销，从而降低性能。
hard：
- 影响：启用该选项后，如果文件存储NAS不可用，客户端会不断重试请求，直到文件系统恢复。这确保了数据的完整性和一致性。
- 建议：启用。该参数有助于避免数据丢失，但可能导致应用程序暂时挂起。因此，适用于对可用性要求较高的场景。
timeo：
- 影响：这个参数定义了客户端在重试之前的等待响应时间。设置过短的超时可能会导致频繁请求重试，从而降低性能，尤其是在网络不稳定的情况下。
- 建议值：600（60秒）。以确保网络有足够的时间恢复，从而减少重试次数。
retrans：
- 影响：该参数定义了NFS客户端在请求失败后重试的次数。更高的重试次数可以增加成功请求的可能性，但也可能导致延迟。
- 建议值：2。平衡性能与数据可靠性。
noresvport：
- 影响：启用该选项后，网络重连时将使用新的TCP端口，从而确保在网络故障恢复期间不会中断连接。以提高网络的可靠性。
- 建议：启用。该参数保障网络连接的稳定性。

重要

不建议使用soft选项，有数据一致性风险。如果您要使用soft选项，相关风险需由您自行承担。
避免设置不同于默认值的任何其他挂载选项。如果更改读或写缓冲区大小或禁用属性缓存，可能会导致性能下降。

云服务器ECS实例的带宽对NAS性能有何限制？

吞吐量最大不会超过ECS内网带宽，如果内网带宽太小，则吞吐量会受到流量控制。

读写吞吐超过阈值会有什么影响？

如果您或应用程序发出的请求吞吐量超过阈值时，NAS会自动对该请求限速，进而导致延迟增高。

通用型NAS可以通过Truncate命令提升吞吐阈值。具体操作，请参见如何提升通用型NAS文件系统的读写吞吐阈值？。

极速型NAS可以通过扩容文件系统提升吞吐阈值。具体操作，请参见极速型NAS扩容。

关于通用型NAS文件系统和极速型NAS文件系统的吞吐阈值，请参见通用型NAS性能指标和极速型NAS性能指标。

如何提升通用型NAS文件系统的读写吞吐阈值？

通用型NAS文件系统的读写吞吐量随文件系统的使用容量线性增长。文件系统读写吞吐与使用容量的关系，请参见通用型NAS产品规格。

通过在文件系统写入空洞文件或使用Truncate命令生成一个文件来增加文件系统使用容量，从而提升文件系统的读写吞吐量。同时，空洞文件和Truncate命令生成的文件在阿里云NAS上占用实际容量，按实际大小计费。更多信息，请参见通用型NAS计费。

例如在容量型文件系统写入1 TiB文件，其读写吞吐量可提升150 MB/s；在性能型文件系统写入1 TiB文件，其读写吞吐量可提升600 MB/s。

Linux
支持使用Truncate命令生成文件提升读写吞吐。
```
sudo truncate --size=1TB /mnt/sparse_file.txt
```
其中，/mnt为文件系统在计算节点上的挂载路径。
Windows
支持通过在文件系统写入空洞文件提升读写吞吐。
```
fsutil file createnew Z:\sparse_file.txt 1099511627776
```
其中，Z:\为文件系统在计算节点上的挂载路径。

如何解决Linux操作系统上访问NAS性能不好？

方案一：通过nconnect参数提升单台ECS访问NAS的吞吐
nconnect参数是NFS客户端Linux挂载选项，通过在客户端和服务器之间建立更多的TCP传输连接来提高吞吐性能。经过测试，使用nconnect参数可以将单ECS访问NAS的吞吐提升3倍~6倍，达到3 GB/s。
适用场景
单ECS上多并发I/O读写（并发大于16）。
前提条件
Linux内核版本需5.3及以上版本。
操作步骤
在mount命令中增加nconnect参数，建议nconnect=4，命令示例如下。
```
sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,nconnect=4 
```
重要
nconnect提高的是单个ECS访问NAS的吞吐能力，并不会提高NAS文件系统自身的吞吐阈值。对于单并发，小数据块，延迟敏感型业务，开启nconnect会引起延迟增加，不建议开启。
方案二：通过修改sunrpc.tcp_slot_table_entries提升单台ECS访问NAS的吞吐
Linux kernel中sunrpc决定了NFS单个链接内的通信slot数量。不同的Linux版本采用了不同的配置。slot配置过高可能引起延迟增加，配置过低会引起吞吐不足。当您需要大吞吐时，建议slot配置为128。需要较低延迟时，slot配置为16及以下。
说明
调整sunrpc.tcp_slot_table_entries的配置效果远差于nconnect。建议5.3及以上内核操作系统使用nconnect参数进行调节。
适用场景
单ECS上多并发I/O读写，且内核版本低于3.10。
操作步骤
请参见如何修改同时发起的NFS请求数量？。

为什么使用Nginx写日志到文件系统耗时很长？

背景信息：
与Nginx日志相关的指令有两条。log_format用来设置日志的格式，access_log用来指定日志文件的存放路径、格式的名称和缓存大小。
问题描述：
Nginx写日志到文件系统耗时很长，写入性能差。
问题原因：
access_log指令中的日志文件路径包含变量，每次写日志时都会重新打开文件，再写入日志，然后关闭文件。NAS为了保证数据的可见性，会在关闭文件时将数据写回服务端，性能消耗较大。
解决方案：
- 方案一：删除access_log指令中的变量，使用固定路径存储日志文件。
- 方案二：使用open_log_file_cache指令设置经常被使用的日志文件描述符缓存，提高包含变量的日志文件存放路径的性能。具体配置，请参见open_log_file_cache。
  建议配置：
```
open_log_file_cache max=1000 inactive=1m valid=3m min_uses=2;
```

为什么SMB协议文件系统执行IO操作会延迟？

问题描述：
通过挂载点直接访问SMB协议文件系统，在执行IO操作会有几分钟的等待时间。
问题原因：
- 安装了NFS客户端，实际业务不使用，产生等待时间。
- 启用了WebClient服务，导致Internet文件服务器登录SMB协议文件系统失败。
- 注册表配置项中包含了NFS权限Nfsnp，导致打开文件失败。
解决方案：
1. 首次访问SMB文件系统时，请ping挂载点，查看计算节点和文件系统连通性，以及时延是否在正常范围。
  - 如果执行ping命令失败，请检查您的网络设置，确保网络连接正常。
  - 如果延时较长，请ping挂载IP。当ping IP比ping DNS延时小很多，判断可能是DNS问题，请检查您的DNS服务器配置。
2. 如果已安装NFS客户端，且用不到NFS服务，请删除NFS客户端。
3. 禁用WebClient服务。
4. 查看注册表配置项HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder，如果注册值包含Nfsnp，请删除Nfsnp，然后重启实例。

说明

您可以使用fio工具，查看性能指标是否异常。

fio.exe --name=./iotest1 --direct=1 --rwmixread=0 --rw=write --bs=4K --numjobs=1 --thread --iodepth=128 --runtime=300 --group_reporting --size=5G --verify=md5 --randrepeat=0 --norandommap --refill_buffers --filename=\\<mount point dns>\myshare\testfio1

建议您使用大数据块进行IO读写操作，如果数据块较小，会消耗更多的网络资源。如果不能修改数据块大小，可以通过构造BufferedOutputStream，将具有指定缓冲区大小的数据写入。

为什么Windows server SMB协议IO操作会延迟？

问题原因：
Windows SMB客户端默认不开启large mtu选项，因此影响IO性能的提升。
解决方案：
您可以通过修改注册表配置项来开启large mtu选项，注册表路径：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters
在该路径下，增加DWORD类型的键，命名为DisableLargeMtu，设置其值为0，重启后才能生效。

如何提升IIS访问NAS的性能？

问题原因：
IIS采用NAS Share的方式访问NAS，在访问一个文件时，IIS后台会多次访问NAS。不同于访问本地文件系统，每次访问NAS至少要有一次网络交互，虽然每次访问的时长很短，但是多次访问时长叠加可能会造成客户端响应总时间较长。
解决方案：
1. 请您使用SMB重定向器组件，进行优化。具体操作，请参见SMB2 Client Redirector Caches Explained。
  其中，注册表路径为HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters。请将如下三个配置项调至600及以上。
  - FileInfoCacheLifetime
  - FileNotFoundCacheLifetime
  - DirectoryCacheLifetime
  说明
  如果三个注册表配置项都不存在：
  1. 请确认使用的是SMB文件系统。
  2. 确认Windows版本是否支持这三个注册表项配置项。如果Windows版本支持而注册表配置项不存在，请手动创建。具体操作，请参见Performance tuning for file servers。
2. 建议把IIS访问频繁的JS/CSS等网页程序相关的内容存放在本地。

如果当前IIS读写性能无法满足您的业务需求，请提交工单处理。

为什么执行ls命令时，有卡顿或者无响应？

问题现象
在执行目录遍历的操作中出现卡顿或无响应。例如，执行ls命令、包含通配符*?的操作、执行rm -rf命令及getdents系统调用等。
原因分析
- 执行目录遍历操作时，如果此目录同时正在被修改（如创建、删除、重命名文件），目录遍历会由于缓存频繁失效而响应非常慢。
- 对大目录执行目录遍历操作时，目录遍历会由于缓存淘汰而响应非常慢。
解决方案
- 避免目录体量过大，控制单目录下文件数量小于1万个。
- 执行目录遍历操作时，不要频繁对目录进行修改。
- 执行目录遍历操作时，如果目标目录体量较大（包含大于1万个文件），且不需要频繁修改目录，您可以通过NFSv3挂载，并添加nordirplus参数，该措施能在一定程度上提速，请您验证后使用。更多信息，请参见挂载参数。

如何提升Linux 5.4及以上版本内核的NFS顺序读取性能？

NFS read_ahead_kb参数定义了Linux内核在顺序读取操作期间要提前读取或预取的数据大小（以KB为单位）。

对于5.4.* 之前的Linux内核版本，read_ahead_kb参数的值是通过NFS_MAX_READAHEAD乘以rsize（在挂载选项中设置的客户端读取数据大小）的值来设置的。从Linux内核版本5.4.*开始，NFS客户端使用默认的read_ahead_kb值128 KB。因此建议使用推荐的挂载选项时，read_ahead_kb参数的值增加到15 MB。

挂载文件系统后，可以使用以下命令重置read_ahead_kb参数值。其中，nas-mount-point请替换为挂载文件系统的本地路径；read-ahead-kb请替换为所需的读取或预取的数据大小（以KB为单位）。

device_number=$(stat -c '%d' nas-mount-point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo read-ahead-kb > /sys/class/bdi/$major:$minor/read_ahead_kb"

以下命令以挂载文件系统的本地路径为/mnt为例，将read_ahead_kb的读取或预取数据大小设置为15 MB。

device_number=$(stat -c '%d' /mnt)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 15000 > /sys/class/bdi/$major:$minor/read_ahead_kb"

为什么第一次连接SMB时很慢？

问题原因：
首次连接SMB共享缓慢，通常是由于Windows客户端在连接时，尝试了多种无效的网络提供程序，或者存在DNS解析延迟。
解决方案：
警告
修改注册表有风险，请在操作前创建系统快照或备份注册表。
步骤一：优化网络提供程序顺序
1. 按 Win+R，输入regedit打开注册表编辑器。
2. 导航至以下路径： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
3. 在右侧窗格中，找到名为 ProviderOrder 的值，并双击打开。
4. 在数值数据编辑框中，查找并删除Nfsnp 和 WebClient 这两个条目（注意保留其他提供程序之间的逗号）。
5. 单击确定保存。
6. 重启客户端ECS服务器使更改生效。
步骤二：排查DNS解析延迟
如果完成步骤一后问题依旧，可以进一步排查是否存在DNS解析缓慢的情况。
1. 打开命令提示符（CMD）。
2. 执行 ping <挂载点地址>，记录下延时。
3. 执行 ping <挂载点对应的IP地址>，记录下延时。
4. 对比结果：如果ping IP地址的延迟远低于ping挂载点地址，则表明存在DNS解析缓慢的问题。请检查您ECS服务器的DNS配置。