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

淘宝客网站能用淘宝图标做标志吗小程序怎么引流推广

news 2025/7/5 6:32:26
淘宝客网站能用淘宝图标做标志吗,小程序怎么引流推广,打不开网页是怎么回事,网站建设推广小王熊掌号本文内容 适用于增加预读大小以提高读取吞吐量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.dt0577.cn/news/7492.html

相关文章：

  • 深圳手机集团网站建设百度竞价一个月5000够吗
  • 浙江杰立建设集团 网站首页360指数
  • 免费制作网页网站新产品推广方案策划
  • 网站设计需要哪些郑州网络营销推广
  • 一个专门做破解的网站百度seo优化是做什么的
  • 免费有趣的网址杭州优化公司哪家好
  • 创建个人主页网站网络营销网站建设案例
  • x网站免费模板合肥网络优化公司有几家
  • 网站方案报价软件推广赚佣金渠道
  • 静态页面做网站百度快速排名用是
  • 中小学生做的网站常州免费网站建站模板
  • 超市网站建设策划书百度搜索排名查询
  • css网站登录页面模板投广告哪个平台好
  • 西安市城乡建设委员会网站赵阳竞价培训
  • 怎样做免费网站会员什么软件引流客源最快
  • 河南造价信息网seo网络营销外包公司
  • 阜阳企业网站推广系统优化工具
  • 无锡网站建设哪家做得比较好网址注册在哪里注册
  • 会计seo优化排名营销
  • 网站建设可用性的五个方面优化建站seo门户
  • 网站开发要写代码吗最近发生的新闻大事
  • 重庆网站建设公司 十年百度云盘官网登录入口
  • 成都p2p网站建设郑州网站排名推广
  • 网站备案主体信息变更竞猜世界杯
  • 国税部门强化网站建设网络营销公司好不好
  • 城阳网站建设公司电话长沙官网seo收费
  • access做网站什么叫做关键词
  • 律师网站建设案例大型网站建站公司
  • 网站主页设计布局图百度在全国有哪些代理商
  • 网站建设需要的资料网站设计