当前位置： 首页 > news >正文

商城网站建设预算要多少钱大学做视频网站

news 2025/11/6 12:25:42
商城网站建设预算要多少钱,大学做视频网站,网页美工制作流程,高端酒店网站模板免费下载本文内容 适用于增加预读大小以提高读取吞吐量Nconnect另请参阅 本文介绍如何提高 NFS Azure 文件共享的性能。 适用于 展开表 文件共享类型SMBNFS标准文件共享 (GPv2)、LRS/ZRS 标准文件共享 (GPv2)、GRS/GZRS 高级文件共享 (FileStorage)、LRS/ZRS 增加预读大…

本文内容

  1. 适用于
  2. 增加预读大小以提高读取吞吐量
  3. Nconnect
  4. 另请参阅

本文介绍如何提高 NFS Azure 文件共享的性能。

适用于

展开表

文件共享类型SMBNFS
标准文件共享 (GPv2)、LRS/ZRS

No, this article doesn't apply to standard SMB Azure file shares LRS/ZRS.

NFS shares are only available in premium Azure file shares.

标准文件共享 (GPv2)、GRS/GZRS

No, this article doesn't apply to standard SMB Azure file shares GRS/GZRS.

NFS is only available in premium Azure file shares.

高级文件共享 (FileStorage)、LRS/ZRS

No, this article doesn't apply to premium SMB Azure file shares.

Yes, this article applies to premium NFS Azure file shares.

增加预读大小以提高读取吞吐量

Linux 中的 read_ahead_kb 内核参数表示应在顺序读取操作期间“预读”或预提取的数据量。 5.4 之前的 Linux 内核版本将预读值设置为装载的文件系统 rsize（读取缓冲区大小的客户端装载选项）的等效值 15 倍。 这会将预读值设置为足够高，以便在大多数情况下提高客户端顺序读取吞吐量。

但是，从 Linux 内核版本 5.4 开始，Linux NFS 客户端使用默认 read_ahead_kb 值 128 KiB。 此小值可能会减少大型文件的读取吞吐量。 从具有较大预读值的 Linux 版本升级到具有 128 KiB 默认值的版本的客户可能会遇到顺序读取性能下降的问题。

对于 Linux 内核 5.4 或更高版本，建议将 read_ahead_kb 设置为 15 MiB 以提高性能。

若要更改此值，请在 Linux 内核设备管理器 udev 中添加规则来设置预读大小。 执行以下步骤：

  1. 在文本编辑器中，通过输入并保存以下文本来创建 /etc/udev/rules.d/99-nfs.rules 文件：

    输出复制

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. 在控制台中，通过以超级用户身份运行 udevadm 命令并重新加载规则文件和其他数据库来应用 udev 规则。 只需运行此命令一次，即可了解新文件。

    Bash复制

    sudo udevadm control --reload

Nconnect

Nconnect 是客户端 Linux 装载选项，通过允许在客户端与 NFSv4.1 的 Azure 高级文件服务之间使用更多 TCP 连接来大规模提高性能，同时保持平台即服务 (PaaS) 的复原能力。

nconnect 的优势

借助 nconnect，可以使用更少的客户端计算机大规模提高性能，以降低总拥有成本 (TCO)。 Nconnect 通过在一个或多个 NIC 上使用多个 TCP 通道或者使用一个或多个客户端来提高性能。 如果没有 nconnect，则需要大约 20 台客户端计算机，才能达到最大高级 Azure 文件共享预配大小提供的带宽规模限制 (10 GiB/s)。 使用 nconnect，只需使用 6-7 个客户端即可达到这些限制。 这几乎减少了 70% 的计算成本，同时大规模地提高了 IOPS 和吞吐量，（请参阅表）。

展开表

指标（操作）I/O 大小性能提升
IOPS（写入）64K、1024K3x
IOPS（读取）所有 I/O 大小2-4x
吞吐量（写入）64K、1024K3x
吞吐量（读取）所有 I/O 大小2-4x

先决条件

  • 最新的 Linux 发行版完全支持 nconnect。 对于较旧的 Linux 分发版，请确保 Linux 内核版本为 5.3 或更高版本。
  • 仅当每个存储帐户通过专用终结点使用单个文件共享时，才支持按装载配置。

nconnect 的性能影响

在 Linux 客户端上将 nconnect 装载选项与 NFS Azure 文件共享大规模配合使用时，我们实现了以下性能结果。 有关如何实现这些结果的详细信息，请参阅性能测试配置。

Screenshot showing average improvement in IOPS when using nconnect with NFS Azure file shares.

Screenshot showing average improvement in throughput when using nconnect with NFS Azure file shares.

有关 nconnect 的建议

遵循这些建议，从 nconnect 中获得最佳结果。

设置 nconnect=4

虽然 Azure 文件存储支持将 nconnect 设置为最大设置 16，但我们建议使用最佳设置 nconnect=4 配置装载选项。 目前，超出四个通道后，Azure 文件存储使用 nconnect 没有增益。 事实上，由于 TCP 网络饱和，单个客户端中单个 Azure 文件共享连接的通道超过四个可能会对性能产生负面影响。

仔细调整虚拟机大小

根据工作负载要求，请务必正确调整客户端计算机的大小以避免受到预期网络带宽的限制。 无需多个 NIC 也可实现预期的网络吞吐量。 虽然通常使用具有 Azure 文件存储的常规用途 VM，但根据工作负载需求和区域可用性，可以使用各种 VM 类型。 有关详细信息，请参阅 Azure VM 选择器。

将队列深度保持小于或等于 64

队列深度是存储资源可处理的待处理 I/O 请求数。 建议不要超过最佳队列深度 64。 如果这样做，则不会再看到任何性能提升。 有关详细信息，请参阅队列深度。

Nconnect 按装载配置

如果工作负荷需要从单个客户端使用采用不同 nconnect 设置的一个或多个存储帐户装载多个共享，则我们无法保证这些设置在通过公共终结点装载时会保留。 仅当每个存储帐户通过专用终结点使用单个 Azure 文件共享时，才支持按装载配置，如方案 1 中所述。

方案 1：（支持）使用多个存储帐户通过专用终结点进行 nconnect 按装载配置
  • StorageAccount.file.core.windows.net = 10.10.10.10
  • StorageAccount2.file.core.windows.net = 10.10.10.11
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1
方案 2：（不支持）通过公共终结点进行 nconnect 按装载配置
  • StorageAccount.file.core.windows.net = 52.239.238.8
  • StorageAccount2.file.core.windows.net = 52.239.238.7
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
    • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

 备注

即使存储帐户解析为其他 IP 地址，也不能保证该地址会保留，因为公共终结点不是静态地址。

方案 3：（不支持）在单个存储帐户上使用多个共享通过专业终结点进行 nconnect 按装载配置
  • StorageAccount.file.core.windows.net = 10.10.10.10
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
    • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

性能测试配置

我们使用以下资源和基准测试工具来实现并衡量本文中概述的结果。

  • 单个客户端：具有单个 NIC 的 Azure 虚拟机（DSv4 系列）
  • OS：Linux (Ubuntu 20.40)
  • NFS 存储：Azure 文件存储高级文件共享（预配 30 TiB，设置nconnect=4

展开表

大小vCPU内存临时存储 (SSD)最大数据磁盘数最大 NIC 数预期网络带宽
Standard_D16_v41664 GiB仅限远程存储32812,500 Mbps

基准测试工具和测试

我们使用了 Flexible I/O Tester (FIO)，这是一款免费的开源磁盘 I/O 工具，用于基准和压力/硬件验证。 要安装 FIO，请参照 FIO 自述文件中的“二进制软件包”部分，为所选平台进行安装。

虽然这些测试侧重于随机 I/O 访问模式，但使用顺序 I/O 时会获得类似的结果。

高 IOPS：100% 读取

4k I/O 大小 - 随机读取 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

8k I/O 大小 - 随机读取 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300
高吞吐量：100% 读取

64k I/O 大小 - 随机读取 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

1024k I/O 大小 - 100% 随机读取 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300
高 IOPS：100% 写入

4k I/O 大小 - 100% 随机写入 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

8k I/O 大小 - 100% 随机写入 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300
高吞吐量：100% 写入

64k I/O 大小 - 100% 随机写入 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

1024k I/O 大小 - 100% 随机写入 - 64 队列深度

Bash复制

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

nconnect 的性能注意事项

使用 nconnect 装载选项时，应密切评估具有以下特征的工作负载：

  • 单线程和/或使用低队列深度（小于 16）的延迟敏感型写入工作负载
  • 单线程和/或使用低队列深度与较小 I/O 大小的延迟敏感型读取工作负载

并非所有工作负载都需要大规模 IOPS 或吞吐量性能。 对于规模较小的工作负载，nconnect 可能没有意义。 使用下表来确定 nconnect 是否有益于工作负载。 建议使用绿色突出显示的方案，而红色突出显示的方案则不推荐。 黄色突出显示的方案则介于二者之间。

Screenshot showing various read and write I O scenarios with corresponding latency to indicate when nconnect is advisable.

另请参阅

  • 有关装载说明，请参阅将 NFS 文件共享装载到 Linux。
  • 有关装载选项的完整列表，请参阅 Linux NFS 手册页。
  • 有关延迟、IOPS、吞吐量和其他性能概念的信息，请参阅了解 Azure 文件存储性能。
http://www.yayakq.cn/news/831181/

相关文章：

  • 建设好网站网站标题第一个词
  • 如何优化网站目录结构两学一做教育网站
  • 淘客的手机网站wordpress采集网址
  • 国际站wap端流量广州知名网站设计
  • 建设一个门户网站价格wordpress教程 下载地址
  • asp做网站策划书网上代做论文的网站
  • 《学做网站论坛》视频下载外贸圈的尖子生
  • nodejs网站开发实例顺德大良做网站
  • 移动网站搭建wordpress 投稿
  • 宝格丽网站建设策划案物联网平台软件开发
  • 邢台市做网站网站优化关键词排名自己怎么做
  • 小鱼儿外贸建站网站建设与网络编辑综合实训课程指导手册pdf
  • 余姚做网站濮阳信息港网首页
  • 做网站怎么变现禄劝彝族苗族网站建设
  • 如何做网站内容架构分析北京自考网官方网站
  • 贵州微信网站建设手机wordpress主题
  • 婚恋网站如何做推广用主机宝建立的网站上传之后404
  • 网站侧边栏导航代码用html5做的静态网站
  • 企业网站建设论坛网站网页制作及优化
  • 芜湖小学网站建设新网站怎么做seo
  • 网站建设许可证网站首页被k咋办
  • 电商网站开发设计方法cpanel做wordpress
  • 企业网站宣传方案建设银行 福建分行招聘网站
  • 漳州网站建设哪家最权威做网站多大
  • 石景山富阳网站建设saas电商平台
  • 常州本地网站网站建设方面的书籍
  • 检查网站的死链接wordpress纯静态化插件
  • 北京网站外包公司论述网站推广的方法与技巧
  • 简述制作网站的流程百度seo最成功的优化
  • 网站备案完成后淘宝网站推广怎么做