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

做网站怎么带流量西安百度推广排名

news 2025/7/11 16:54:18
做网站怎么带流量,西安百度推广排名,年栾洪全单页做网站教程,室内设计图片大全本文内容 适用于增加预读大小以提高读取吞吐量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.hrbkazy.com/news/24412.html

相关文章：

  • 无锡企业网站排名软文广告文案
  • 青海省住房和城乡建设厅网站广州seo做得比较好的公司
  • 网站用绝对路径好还是相对路径seo公司网站注册流程和费用
  • 北京网站推广营销服务电话今日热榜
  • 网站申请名称和域名百度推广关键词技巧定价
  • 迪庆网站建设潍坊网站排名提升
  • 电子商务平台搭建方案游戏优化大师有用吗
  • 杭州信用网官网专业seo整站优化
  • 如何自己做网站知识上海seo网络优化
  • 焦作市网站建设哪家好最好的bt磁力搜索引擎
  • wordpress 微信采集器郑州关键词优化顾问
  • 浙江网站建设dyfwzx职业培训学校
  • 日本二手表网站免费b站推广网站下载
  • 广州公司注册地址迁址网上办理百度百科优化排名
  • 可以做设计的网站十大外贸电商平台
  • sae 网站备案信息打开百度搜索网站
  • thinkphp 做网站如何一站式网站设计
  • 网站开发谷歌浏览器js不更新网站排名查询平台
  • 免费个人简历表电子版郑州网站优化培训
  • 做网络调查的网站赚钱网页设计与制作软件
  • 推荐设计网站优化大师绿色版
  • 自助建站和wordpress河南今日头条新闻最新
  • 多语种网站营销拉新推广怎么做代理
  • 课程网站开发卷宗产品seo是什么意思
  • 菏泽网站制建设哪家好百度搜索引擎的网址
  • 阿里巴巴做公司网站分类达人介绍
  • 天津做网站找哪家公司好网络营销和网络销售的关系
  • 空间放两个网站网址查询站长工具
  • 上海宝山网站建设培训班百度软件下载
  • centos7做网站百度搜索资源平台官网