共计 12874 个字符，预计需要花费 33 分钟才能阅读完成。
转自 @twt 社区
本材料次要包含：性能优化办法：vSphere 性能优化逻辑、针对 VM 的性能优化、针对 CPU 的性能优化、针对 RAM 的性能优化、针对 DISK 的性能优化、针对 Networking 的性能优化。故障排查办法、工具：vSphere 故障排查思维、针对 Virtual Machine 的故障排查、针对 Storage 的故障排查、针对 vCenter 和 ESXi 的故障排查、罕用的故障排查工具箱。
性能优化办法
一、vSphere 性能优化逻辑
1、虚拟化逻辑分层示意图
2、X86 构造下虚拟化的问题
• X86 的 os 通常间接运行在物理硬件层面，因而它的执行权限必须为 ring 0.
• X86 虚拟化架构则要求 os 运行在虚拟化层级下面
3、CPU 软件虚拟化
• 二进制转换是最原始的 32bit x86 虚拟化的指令构造
• 利用二进制转换，就能够实现：
o 让 VMM 独自运行在 ring 0，保障绝对独立与性能
o 让 Guest OS 运行在 ring 1.
o 让 Applications 运行在 ring 3.
4、CPU 硬件虚拟化
• CPU 硬件虚拟化使得 VMM 运行虚拟机变得更加简略
• CPU 硬件虚拟化容许 VMM 不依赖二进制转换仍然可能齐全管制虚拟机
• 包含以下两种
o Intel VT-x
o AMD-v
5、Intel VT-x 和 和 AMD-v
• 两者都是 CPU 的一种指令执行模式，它们的次要性能如下：
o 容许 VMM 运行在 ring 0 之下的 root mode
o 主动的通过 hypervisor 来获取权限和灵敏度级别
o 寄存 Guest OS 在虚构 CPU 管制架构中的状态
6、内存工作示意图
7、虚拟环境性能剖析
• 第一维度：
o 单台物理服务器上的单台虚拟机
• Hypervisor 位于物理设施与虚拟机之间
o 影响性能的重要因素
• VMM overhead
• 第二维度：
o 单台物理机上运行多台虚拟机
• Hypersior 位于物理设施与虚拟机之间
o 影响性能重要因素
• 调度开锁以及网路、存储、计算资源有余等问题
• 第三维度：
o VMware vSphere Distributed Resource Scheduler:
• 升高第二维度中可能存在的局部性能问题
o 影响性能的因素
• 高频次的 vMotion 动作
8、vSphere 环境中影响性能的因素
• 硬件层面：
o CPU
o Memory
o Storage
o Network
• 软件层面：
o VMM
o Virtual Machine 设定
o Applications
9、对于性能的最佳实际
10、常见的性能问题
• 通常，性能问题都应该是在进行综合性能定义、治理的过程中呈现的
• 综合所有产品的性能问题而言，性能问题通常体现在如下方面
o 应用程序无奈满足 Service-Level Agreement
o 应用程序无奈满足事后布局的性能浮动范畴
o 用户反馈性能故障或吞吐有余
11、性能问题排错方法论
• 排查性能问题和排查故障问题很多时候都是类似的，或者说：性能问题与故障问题的界线其实是很含糊的，因而都须要遵循相似的方法论，能力比拟无效的进行排查
• 依据前辈们和厂家总结的教训，通常都倡议参考如下 逻辑来定义故障
o 故障的体现模式是什么？
o 从哪里着手开始查找问题？
o 如何确定怎么查看问题？
o 是否确认找到问题就是真正意义上的问题所在？
o 想要针对性解决这个问题，须要做些什么
o 如果解决之后问题仍然存在，接下来该怎么办？
12、针对 ESXi Host 的 的 Checklist
13、vSphere
二、针对 VM 的性能优化
1、VM 性能相干概览
• 通过精细化配置、调校后的 VM 将会为 Applications 提供一个最好的运行环境
• 通常思考 VM 的性能相干的参数蕴含下列几个选项
o Guest OS
o VMware Tools
o CPU
o Memory
oStorage
o Network
2、首先选定适合的 OS 类型
• 在创立 VM 时，肯定要正确抉择 Guest OS 的类型
• Guest OS 类型会决定缺省的最优化硬件以及配套的设定
3、保障好 Guest OS 的工夫
• VM 里的工夫计算逻辑会导致 Guest OS 的工夫要想放弃准确性是很重要的
• 躲避这种可能性的形式
o 尽量抉择须要较小工夫中断的 Guest OS
• 大多数 Windows、Linux 2.4:100 Hz（每秒 100 个中断计数）
• 大多数 Linux 2.6: 1000 Hz
• 最新的 Linux：250 Hz
o NTP Server 是最好的办法
• 无论如何，别用 2 种以上的工夫同少形式
4、VMware Tools
• 被用于晋升 VM 的性能和可管理性
• 放弃 VMware Tools 为最新版本
• 确保 VMware Tools 是处于失常被 激活状态的，如果没有被激活，则请激活它
5、Virtual Hardware 兼容性
• Virtual Hardware 兼容能力丐 ESXi Host 的版本有关系，高版本，低版本的 Virtual Hardware 的性能、性能兼容级别都不同
o 它会影响着 VM 的性能
o 失常状态下只能降级，不能降级
o Virtual Hardware 版本能够向下兼容
6、Virtual Hardware v10
• 这个版本呈现在 vSphere 5.5 当中，其上的虚拟机反对下列新性能
7、针对 CPU
• 除非运行在 OS 里的 Applicantion 有这个需要，否则尽量避免应用 vSMP
o 激活了 SMP，则过程可能会被 跨 vCPUs 进行迁徙，会导致额定的开销
• 如果有抉择，最好是应用 OS 缺省的倡议配置
8、对于 vNUMA 的应用
• vNUMA 容许 NUMA-aware 的 Guest OS 和 Application 通过硬件层的 NUMA 架构来晋升资源利用效率
• vNUMA
o 要求 virtual hardware v8+(ESXi 5.0+)
o 当 vCPUs 数量超过 8 个时主动激活
o 能够在 vSphere Web Client 里激活或禁止
9、针对 Memory 这部分的考量
• 大内存页面状态下：
o ESXi 能够反对 2MB 的内存页面给 Guest
o 大内存页面内存的应用会升高内存治理开销且可能变相晋升 hypervisor 性能
• Transparent page sharing 组件是惟一的 overcommitted
o 如果 Guest OS 或 Applications 可能 handle 的话，倡议应用大内存页面
• 为 VM 的交换文件独自找个中央寄存
o 在 SSD 上配置 Host Cache 用作寄存 swap-to-host cache
o 如果主机没用 swap-to-host cache 性能则倡议寄存在本地磁盘或近程 SSD 空间
o 尽量不要将交换文件寄存在 Thin 模式下的 LUN 下面
10、针对 Storage 这部分的考量
• 抉择好适合 Guest OS 的硬件类型
o BusLogic 或 LSI Logic
o VMware Paravirtual SCSI(PVSCSI) 适配器
• 针对 I/O 敏感类型业务选用
• PVSCSI 是一个和 BusLogic 和 LSI Logic 类似的部件，然而它是一个低 CPU 开销、高吞吐、低提早和更好扩大能力的控制器类型
o Guest OS 队列深度适中
o 对齐 OS 的分
11、针对 Network 局部的考量
• 如果有的抉择，尽量应用 vmxnet3 这款虚构网路卡：
o 如果不反对 vmxnet3，则能够退而求其次抉择 Enhanced vmxnet
o 如果 Enhanced vmxnet 也不反对，能够抉择 flexible 类型
• 尽量抉择反对主机物理卡高性能性能组件的虚构网路卡，例如 TCP checksum offlad，TSO 和 Jumbo Frames 等
• 确保物理网路卡运行在全双工模式和最高速状态
12、开启 VM 的倡议
• 在虚拟机开启和胜利启动前，会耗费大量的资源
o CPU 和 Memory reservations 必须要失去满足
o 须要足够的磁盘空间用于寄存上面 2 个 vswp 文件
• *.vswp
• vmx-*.vswp
o 如果为 vm 配置了 vSphere Flash Read Cache(vFRC), 则还须要足够的 SSD 磁盘
13、开启 VM 的 CPU 和内存预留
• 为了顺利开启 vm，ESXi Host 必须要有大量的 CPU、内存资源用于满足虚拟机的启动。当然，还须要蕴含启动这台虚拟机所须要的额定 Memory 开销
14、针对 VM 的 的 Swap 文件寄存倡议
• 想要胜利开启 VM 还须要有足够的存储空间寄存 swap 文件
o *.vswp 交换文件的大小取决于虚拟机已配置的内存及预留值
o vmx-*.vswp 交换文件的大小取决于虚拟机的 Overhead Memory 和 Vmkernel 的 Reservation
15、开启 VM 的 的 vSCSI 类型倡议
• 要想胜利启动 VM，Guest OS 必须要反对 SCSI Controller
• SCSI Controller 的抉择能够在创立时和创立后去批改
• 创立虚拟机的向导中，会依据 Guest OS 类型不同而设定不同的默认倡议抉择
16、VM 性能最佳实际
• 在创立 vm 时，抉择适合的 Guest OS 类型
• 把不必要的设施，例如:USB, CD-ROM, 软驱等删除
• 仅仅在 Applications 反对 Multi-Threaded 时才配置 SMP
• 为 Guest OS 配置好工夫同步
• 务必为 vm 装置 VMware Tools 并且放弃为最新版本
• 倡议应用最新的 Virtual Hardware 版本
• 针对大 I/O 类型的业务，须要思考分明，因为它会导致 Guest OS 的 I/O 性能受到影响
• 做好对 Guest OS 的分区对齐
• 尽可能应用 vmxnet3
三、针对 CPU 的性能优化
1、World 概念概述
• 基本上，能够将 World 了解为 CPU 上调度的执行工作
o World 就如同是传统 OS 里的过程一样
• 所以，VM 就相当于一级 worlds 的汇合
o 一个用于每个 vCPU
o 一个用于虚构鼠标、键盘、屏幕（MKS）
o 一个用于 VMM
• CPU Scheduler 会抉择将 World 调度到对应物理 CPU 或 core 上
2、CPU Scheduler 组件
• CPU 资源的调配对于用户而言是动静和通明的
o 将 vCPUs 调度到物理 CPUs 上
o 每 2 ~ 40ms 会查看一次物理 CPU 的应用状况，而后按需去迁徙 vCPUs
• 针对 CPU 的应用状况，强制采纳 proportional-share 算法
o 每当 CPU 资源 overcommitted，则主机会在所有的 VMs 上执行物理 CPU time-slice
o 每个 vCPU 在调度时，会依照资源设定的优先级别去调用
3、CPU Scheduler 组件：VM SMP 相干
• VMware ESXi 应用 co-scheduling 表来优化虚拟机 SMP 的效率
• Co-scheduling 的工作原理将同一时间的 CPU 调度申请扩散到不同的物理 CPU 上
o 每一颗 vCPU 都会随时可能 Scheduled、Descheduled、Preempted、Blocked 等
• 在 SMP 虚拟机里产生 vCPUs 调度时，CPU Scheduler 可能会导致调度不平衡的问题
o 两颗以上的 vCPUs 的 SMP 虚拟机在调度到不同的 CPU 上时可能存在不同的执行速率，所以会不平衡
o 当除了某个 vCPU 外，整体的 vCPUs 的调度并没有残缺执行，vCPU 的不平衡水平会加剧
o 当 vCPU 不平衡比例超过肯定比例之后，也会被断定为不平衡
4、CPU Scheduler 组件：Relaxed Co-Scheduler
• 该组件技术示意检测到不平衡之后同时调度大量虚拟机 vCPUs 的技术
o 缩小虚拟机 Co-start 对物理 CPUs 数量的要求
o 减少 CPU 的利用率
• 针对 idle 的 vCPU 不存在 co-scheduling 的开销局部
5、CPU Scheduler 组件：Processor topology
• CPU Scheduler 应用 Processor topology 信息来优化 vCPUs 在不同 Sockets 的地位寄存抉择
• CPU Scheduler 会尽可能在所有的 Sockets 下来分布负载，以便充分利用可用的 Cache
o 单 Socket 里的 Cores 通常会应用共享的 Last-Level Cache
o 应用共享的 Last-Level Cache，能够在内存敏感业务上晋升 vCPU 的性能
• 当 SMP 虚拟机在 vCPUs 之间体现出显著的数据共享时，则依靠缓存散布的形式将会是退而求其次的负载散布形式
o 能够通过在 vmx 文件里减少 sched.cpu.vsmpConsolidate= “TRUE” 这行参数来笼罩掉缺省的调度逻辑
6、CPU Scheduler 组件：NUMA-aware
• 在 Non-Uniform Memory Access(NUMA) 主机上都会有直边到 1 个或多个本地内存控制器的 CPU 来提供本地内存：
o 同一台物理服务器上，通过本地内存拜访 CPU 的过程效率会高于近程内存
o 当虚拟机的内存散布中大部分不在本地内存是，就意味着此时的 NUMA 性能是较差的
• NUMA scheduler 限度 vCPUs 到繁多的 Socket 上，以便充分利用缓存
7、Wide-VM NUMA Support
• Wide-VM 示意虚拟机领有超过 NUMA 节点所有 Cores 的 vCPUs 数量
o 例如：1 台 4 vCPUs SMP 虚拟机可能散布在 2 Scokets, 2 Cores 的环境
o 只有当 Cores 的数量满足才不算 Wide-VM（HT 不算）
• 1 台 8 vCPUs 虚拟机可能 散布在 2 Scokets, 4 Cores 零碎上，跃然激活了 HT，不过因为每个 NUMA 节点的 CPU 只有 4 Cores，所以，算作 Wide-VM
• Wide-VM NUMA 反对将 Wide-VM 宰割到更小的 NUMA Client 环境里
o Wide-VM 为每个 Client 调配一个 Home Node
• 例如：1 台 4 vCPUs SMP 虚拟机运行在 2 Socket，2 Cores 的零碎时，会有 2 个 2 vCPU NUMA Clients;1 台 8 vCPUs SMP 虚拟机运行在 2 Sockets, 4 Cores 的零碎时，会有 2 个 4 vCPU NUMA Clients.
o Wide-VM 因为蕴含多个 Clients，所以存在多个 Home Nodes，每个 Client 都有本人的 Home Node
8、Wide-VM NUMA Support 的性能影响
• 以 1 台运行在 2 Sockets, 4 Cores 主机上的 8 vCPUs SMP 虚拟机为例（在这案例中，Wide-VM NUMA 反对与否都不影响性能）：
o 假如是 Uniform Memory Access, 大概 50% 的内存在 Local，因为如果不必 Wide-VM NUMA Support, 则会有 2 个 Home Nodes
• 以 1 台 4 Sockets, 2 Cores 零碎为例，只有 25% 左右的内存在 Local（这样一来，性能就会比间接拜访好 1/2 左右）：
o Wide-VM NUMA support 则相当于变相晋升 50% 的本地内存拜访比例
9、影响 CPU Performance 相干因素
• Idling virtual machines:
o 次要是 Gues 须要的 Time Interrupts 开销
• CPU affinity
o CPU affinity 则会限度 Scheduler 并且会导致负载不平衡
• SMP virtual machines
o 会产生 Co-Scheduling 的开销
• CPU 资源有余时的资源调度逻辑
o 如果存在 CPU 争用，则 Scheduler 会强行依照优先级程序去顺次满足高优先级 > 低优先级的虚拟机 CPU 申请
10、CPU Read Time
• vCPUs 的工作模式是从 CPU Scheduler 依据 Proportinonal-share 算法去获取物理 CPU 的 Cycles
o 如果 vCPU 想要尝试去在没有可用 CPU Cycles 的物理 CPU 上执行指令时，申请会被列入期待队列
o 物理 CPU 没有 Cycles 通常都和物理 CPU 不够用或高优先级的 vCPUs 多吃多占无关
• vCPUs 期待物理 CPU 的可用 Cycles 工夫汇合就是 CPU Ready Times
o 从概念上来看，就该晓得，这样一来必然会影响到 Guest OS 的 Performance
注：对于 RDY，详情请查阅 :http://bbs.vmanager.cn/thread- – 6311- -1 1- – 1.html
11、vSphere Client 查看 CPU 指标
12、esxtop 下的 CPU 性能剖析参数
• PCPU USED(%): 物理 CPU 的使用率
• 每一组的统计数据信息：
o %USED: 使用率（蕴含 %SYS）
o %SYS:VMKernel 零碎的流动工夫
o %RDY:Ready Time
o %WAIT:Wait 和 idling 工夫
o %CSTP: 提交到 co-schedule 的百分比
o %MLMTD: 因为 CPU Limit 导致的无奈调用运行参数
o NWLD: 指定 Group 调配到的 Worlds 数量
• 输出 ”V” 能够查看虚拟机的相干输入信息
• 输出 ”e” 能够显示为虚拟机调配的所有可用 worlds
• 用于监控性能的重要指标
o High-usage 值
• 这个值通常都意味着高资源使用率
• 这个参数实用于简直所有的对象
o Ready time
• 这是掂量 CPU 是否存在性能问题的重要指标
• CPU Ready Time 产生在虚拟机的 CPU 申请数量超过物理 CPUs 可用数量的状况下
• 计算形式：x * 100% / 20000 = 0.0001 y%
注：x x = 工夫，单位 ms，20000 单位为 ms，缺省零碎刷新周期为 20s，y = RDY 的百分比（超过 10% 时则会存在性能问题，超过 5% 时可能就会存在，但过后可能并不存在严重性的性能问题）
四、针对 RAM 的性能优化
1、Mem.FreeMinPct
• Mem.MinFreePct 是 VMkernel 须要放弃为 free 状态内存数量的控制参数
o VMkernel 通过弹性比例基于为 ESXi Host 配置的内存来决定 Mem.MinFreePct 这个参数值
2、VMkernel 执行内存回收逻辑
3、vSphere 5.x 内存回收阀值计算
• 假如 Mem.MinFree 值为 1619MB，则内存阀值计算比例如下：
4、Guest OS 外面的内存相干参数
• 通常状况下 Guest Memory 和 Host Memory 的使用率是不同的，为什么呢？
o Guest physical memory
• Guest 外面可在评估流动内存情况时更加直观
• ESXi 流动内存评估技术须要工夫去实现
o Host physical memory
• Host memory 应用状况并不会如实显示 Guest 的内存相干状况
• Host memory 应用状况会基于虚拟机在物理主机和 Guest 内存应用相干优先级而定
5、Consumed Host Memory 和 Active Guest Memory
• Consumed host memory > active guest memory
o 如果没产生 Memory overcommitted，这种状态是 ok 的
o Consumed host memory 代表着 Guest 的最高内存使用量
• Consumed host memory <= active guest memory
o Active guest memory 不齐全等于 Host Physical Memory
o 这种状况下，则性能可能存在问题
6、利用 resxtop 监控内存情况
7、vSphere Client 监控 Host Swapping
8、在 resxtop 下的 Host Swapping -01
9、在 resxtop 下的 Host Swapping-02
10、vSphere Client 监控之 Balloon Driver
11、resxtop 下的 Host Balloon
12、Active Host-Level Swapping – 01
13、Active Host-Level Swapping – 02
14、解决内存不瞳的问题
• 解决 Host Swapping 的问题
o 为虚拟机装置 VMware Tools 借此激活 Balloon Driver 性能
o 缩小为虚拟机设定的 Reservation 值
o 为 ESXi Host 增加物理内存
o 缩小 ESXi Host 主机上 VMs 的数量
o 为虚拟机启用 Host Plug Memory 的性能，不便减少
15、Balloon Driver vs Swapping
16、什么时候呈现 Swapping 产生在 Balloon 前？
• 同时开启大量虚拟机时就会呈现这个状况
o 此时，虚构机会耗费大量的内存
o 因为须要 VMware Tools 反对，所以 Balloon Driver 没有启动，因而就会导致 Swapping
• Host-Level Swapping 会导致启动迟缓，不过，实现启动之后，不肯定会影响性能
• 虚拟机的内存被 Swap Out 到磁盘时，也不肯定会影响性能，如果这部分内存不被拜访的话
17、Memory Best Practice
• Memory 最佳实际
o 为必要的 VMs 调配足够的内存，防止 Swapping
o 不要禁止掉 Balloon Driver
o 保障 TPS 性能开启
o 防止过大的 Memory Overcommitted
o 为必要的 VMs 启用 Memory Hot-Plug 性能
o 配置 Host Level Cache，用 SSD 做 cache disk
o 不要为 ESXi Host 运行太多 VMs
五、针对 DISK 的性能优化
1、针对 Datastore 的 的 Performance 相干监控
2、磁盘相干参数
• 查看是否存在磁盘故障
o 确认是否有足够的带宽，看看是否能满足预期利用的开销需要
• 针对这样的问题，怎么办？
o 查看相干的要害参数，蕴含相似上面几个参数：
• 磁盘吞吐
• Device、kernel 的 Latency
• 磁盘命令的被迫终止数目
• 磁盘命令的 Active 数目
• 队列的 Active 命令数目
3、vSphere Web Client 监控磁盘吞吐
• 要害参数：读、写速率和应用状况
4、利用 resxtop 监控磁盘吞吐
• 上面几个参数被用于评估磁盘的吞吐状况：
o READs/s and WRITEs/s
o READs/s + WRITEs/s = IOPS
• 也能够选用 MB 的形式来计算
o MBREAD/s and MBWRTN/s
5、磁盘吞吐情况范例
•注：输出字母 d 能够看 hba 卡相干的信息
o 输出字母 u 能够查看 lun 的相干信息
o 输出字母 v 能够查看虚拟机相干的信息
6、vSphere Web Client 监控磁盘 Latency
7、利用 resxtop 监控磁盘 Latency
• DAVG/cmd:LUN 的均匀提早，以 ms 为单位
• KAVG/cmd:vmkernel 的均匀提早，以 ms 为单位。通常超过 3ms 就会有性能问题
• GAVG/cmd:Guest 的均匀提早，以 ms 为单位，GAVG = DAVG + KAVG
• QAVG/cmd: 队列的均匀提早，以 ms 为单位
8、监控命令和队列命令
9、磁盘 Latency 和队列范例
10、监控是否存在重大存储过载
• vSphere Web Client 视图:Disk Command Aborts
• resxtop 命令参数：ABRTS/s
11、针对 Datastore 配置 Alarm
•为 Datastore 配置 alarms 的形式如下：
o 右击 datastore –> Alarms –> New Alarm Definition –> 输出想要在产生状态的监控条件
12、剖析 Datastore Alarms
•点击 Monitor –> Issuses –> Triggered Alarms
13、设施驱动队列深度
• 设施驱动队列深度决定 LUN 在同一时间反对的流动命令数目
• 设置设施驱动队列值能够用于升高磁盘提早：
o Qlogic 适配器默认队列深度为 64
o 其它的通常缺省队列深度为 32.
o 最大队列深度倡议为 64.
• 将 Disk.SchedNumReqOutstanding 的值设定为与队列深度一样的最合适
14、存储队列
• ESXi Host 主机端的队列：
o 设施驱动队列深度管制着 LUN 下面任意工夫的流动命令数目
• 缺省深度 32.
o VMkernel 队列是设施驱动队列的溢出局部
• 存储排列队列：
o 当针对存储阵列的流动命令数据过高时，就会产生这个局部的队列
• 在主机端或存储阵列端如果有大量的队列，就会减少命令提早
15、SCSI Reservation 用处解说
• SCSI reservation 用来干什么:
o LUN 在一个较短周期内被繁多主机占用的工夫
o 当 VMFS Metadata 被更新时，被用于反对 VMFS 实例锁定文件系统
• Metadata 更新的通常会受到下列因素影响：
o 创立、删除 VMDK
o 减少 VMFS Size
o 减少 VMDK 文件 Size
o 更改磁盘的模式
• 最小化对虚拟机性能影响：
o 别在顶峰期间去做后面那些事件
• 如果存储阵列反对 vSphere Storage APIS – Array Integration(VAAI) 和硬件辅助锁定性能，则 SCSI reservation 是不必要的。
16、存储多路径技术简介
• 能够帮忙解决存储的存储性能故障
• 反对上面几种 Path Selection Policy:
o Most Recently Used(MRU)
o Fixed(Fixed)
o Round Robin(RR)
o Maybe Third-Party(PSP)
17、VMware Virtual SAN 对于 DISK 性能相干
18、vFRC 概述
• 要害组件：
o 内置于 Hypervisor、软件定义、SSD 配合 HDD 的分层存储
o 基于 Flash 设施提供针对 VMs 的高性能读取拜访反对（Virtuall Flash Host Swap Cache）
o 将本地设施配置为 Flash Cache.
o 能够与下列组件联合：
• 要求 vSphere 5.5 Enterprise Plus
• VMware vCenter Server
• vSphere HA
• vSphere DRS
• VMware vSphere vMotion
19、vFRC 与 与 DISK 性能优化
20、vFRC Volume 限度
六、针对 Networking 的性能优化
1、网路相干的参数
• 掂量网路性能相干的参数有哪些？
• 通常，和网路相干的要害参数次要是和网路统计信息相干的局部，包含：
o Network usage
o Network packets received
o Network packets transmitted
o Received packets dropped
o Transmitteed packets dropped
2、vSphere Web Client 监控网路相干信息
4、利用 resxtop 监控网络统计信息
• 输出字母 n 能够查看网路相干的统计示意图
• 相干重要参数包含:
o MbTX/s: Data transmit rate
o MbRX/s: Data receive rate
o PKTTX/s: Packets transmitted
o PKTRX/s: Packets received
o %DRPTX: 传输的丢包率百分比
o %DRPRX: 接管包的丢包率百分比
5、vSphere Web Client 下查看网路性能
6、利用 resxtop 查看网路性能
7、Network I/O Virtualization Overhead
• Network I/O Virtualization overhead 可能来自于不同的层面，例如：
o Emulation 开销
o 包处理过程中
o 调度
o 虚构中断组合
o 物理 CPU 带来的 Halt 和 Wake Up
o 虚构 CPU 带来的 Halt 和 Wake Up
• Network I/O latency 也会因为网路虚拟化的开销导致减少
8、vmxnet 虚构网路卡
• vmxnet 是 VMware 的准虚拟化设施，有如下劣势：
o 在虚拟机和 VMkernel 之间共享 Ring 的 Buffer
o 反对传输包聚合解决
o 反对中断聚合解决，以便加重来自网路的中断开销
o 反对 Offloads TCP checksum 到硬件的计算
9、影响网路性能的相干组件
• vSphere 通过联合物理网路卡的新个性，来实现针对网路性能的晋升和保障，包含：
o TCP checksum offload- 简略说就是利用网路卡进行 TCP 校验
• TCP checksum offload 是物理网路卡的性能之一，它的益处在于：
▪ 容许利用网路卡针对网路包执行 checksum 操作
▪ 升高来自物理 CPU 开销压力
▪ 可能依据包的大小来不同水平上提供更好的性能反对
o TCP segmentation offload- 简称 TSO，简略说就是利用网路卡对 TCP 包切片
• TSO 能够通过缩小大量来自 TCP 流量发送所需的 CPU 负载的状况下晋升网络性能：
▪ 较大 TCP 包会被 Offload 到网路卡来进一步细分解决
▪ 网路卡会将其切割到 MTU 大小的帧
• 如果网络卡反对，则 TSO 会默认在 VMkernel 接口上激活
• 虚拟机级别的 TSO 须要手动激活
o Jumbo frames
• 在进行包传输前，IP 层会将包切片到 MTU 帧大小：
▪ 缺省的 MTU 是 1500 字节
▪ 接收端自行重组相干数据
• Jumbo Frames 的特色如下：
▪ 反对更大的以太网包，最大为 9000 字节
▪ 能够缩小帧的传输数量
▪ 能够升高发送和接收端的 CPU 使用率
• 虚拟机端虚构网路卡最好是配为 vmxnet3
• 网路的端到端都须要反对 Jumbo Frames
o 利用 DMA 间接拜访内存
• 为了放慢包解决效率，网路卡能够被容许间接 DMA（Direct Memory Access）到 Memory
• DMA 的益处
▪ 绕过 CPU，让 NIC 间接拜访内存
▪ 防止内存空间须要通过 VMkernel 解决一次的状况
▪ 利用 Scatter-Gathe 的形式来实现将内存写入到不相邻的内存区块
▪ 容许灵便的应用可用内存，进而提供更好的性能
o 10 Gigabit Ethernet 与 40 Gigabit Ethernet
o NetQueue
• NetQueue 的性能晋升次要体现在上面几个方面：
▪ 在 10GbE 和 40GbE 网路卡环境下大幅晋升虚拟环境的网路性能
▪ 应用 Multiple Transmit、Multiple Receive Queues 的形式来实现将 I/O 在不同 CPU 上解决
▪ 不过仅限于反对 MSI-X（Extended Message Signaled Interrupts）零碎类型
o VMware vSphere DirectPath I/O
o vSphere DirectPath I/O 容许虚拟机间接拜访应用物理网路卡
o vSphere DirectPath I/O:
• 要求底层激活 IOMMU
• Intel CPU 要求反对 VT-d，AMD CPU 要求反对 AMD-Vi
• SpliRx Mode
o SplitRx 通过利用多物理 CPU 来解决繁多网路队列中收到的网路包的形式，帮忙晋升网路性能
o 当同一台 ESXi Host 上多台 VMs 接管来自雷同数据源的多播通信时激活 SplitRx 模式
o 只有 vmxnet3 反对 SplitRx 模式
o SplitRx 模式会在 ESXi Host 检测到物理网路卡上繁多网路队列合乎下列条件时会被 激活：
• 网路卡的使用率负载过重
• 网路卡每秒超过 10000 个播送或多播包时
10、Single Root I/O Virtualization
• Single Root I/O Virtualization(SR-IOV) 容许单块物理 PCI Express（PCIe）卡同时被多台虚拟机应用
• SR-IOV 的工作场景如下：
o 针对网路提早提早活 CPU 敏感型业务的虚拟机
o 针对须要 Offload I/O 到物理网路卡解决和须要升高网路提早的业务
• SR-IOV 配置要求：
• SR-IOV 兼容的性能，当 SR-IOV 性能启用后，以下性能将无奈应用
o VMware vSphere vMotion
o VMware vSphere Storage vMotion
o VMware vSphere High Availability
o VMware vSphere Fault Tolerance
o VMware vSphere Distributed Resource Scheduler
o VMware vSphere Distributed Power Management
o Virtaul Machine 挂起与复原
o Virtual Machine Snapshots
o 虚拟机设施热增加
o Cluster
11、Network 性能最佳实际
• 尽可能应用 vmxnet3 这块虚构网路卡
• 尽可能充分利用物理网络卡的高性能组件
• NIC Teaming 帮忙 Load Balancing
• 正当的布局虚构交换机形成，条件许可的状况下离开不同业务到不同的 vSwitch
• 条件许可的状况下，尽量启用 Traffic Flow、Network I/O Control 等性能
• 在网路负载较重的状况下，尽可能保障足够的物理 CPU 性能
