xenserver netback process解析&&调优

简介:

  在利用xenserver做性能测试的时候发现netback进程占用cpu很高(如下图),google了一下,才发现netback进程对xenserver性能调优有不小的影响。下面是摘录的E文,中文是我自己翻译的。E文水平有限,还请见谅。

image

Static allocation of virtual network interfaces (VIFs) and interrupt request (IRQ) queues among available CPUs can lead to non-optimal network throughput.

VIF的固定分配和各个cpu间的中断请求队列可能导致非最优的网络流量。

All guest network traffic is processed by netback processes in the control domain on the guest’s host.There is a fixed number of netback processes per host (four by default in XS 5.6 FP1), where each one is pinned to a speci?c control domain virtual CPU (VCPU).

所有客户端网络流量都被控制域的netback进程所控制。每个主机有固定数量的netback进程(XS 5.6 FP1中默认是4),每个netback进程被绑定在控制域的vcpu中。

All traffic for a specific VIF of a guest is processed by a statically-allocated netback process. The static allocation of VIFs to netback processes is done in a round robin fashion when virtual machines (VMs) are first started after XenServer restart. The allocation is not dynamic, since that would require further synchronisation mechanisms, and would close any active connection on every rebalance.

一个客户端的某个vif的所有流量被静态分配的netback进程控制。当xenserver重启后,虚拟机第一次启动时,vif以循环方式固定分配到某个netback进程。这种分配不是动态的,由于它需要更进一步地同步机制,并且在每次重新循环时会关闭所有活动连接。

For example, suppose we have a host with four CPUs, with four netback processes (running on four VCPUs in the control domain), and two physical network interfaces (PIFs). Furthermore, suppose the host has four VMs, where each VM has two VIFs that correspond to PIFs (in the same order for all VMs),and that VMs are started one after another (which is normally the case). Then,the first VIF of all four VMs will be allocated to odd-numbered netback processes, while the second VIF of all four VMs will be allocated to even-numbered netback processes. Therefore, if VMs send network trafficonly on their first VIF, then only two of the available four CPUs will be utilised. See Figure 1.With heavy network traffic on fast network interfaces, CPU can quickly become the bottleneck, so being able to utilise all available CPUs is crucial.

例如,假设有一个4cpu的主机,4个netback进程(在控制域中运行4个vcpus),并且两个物理网卡。另外,假设这个主机由4个vms,每个vm有2个vifs绑定到pifs(对于所有vms都是一样顺序),4个vms按顺序启动(一般情况下都是如此)。那么,4个vms的第一个vif将会被分配到奇数的netback进程,而第二个vif将会被分配给偶数的netback进程。因此,如果vms只通过它们的第一个vif发送网络流量,那么只有4cpu中的2个被使用(本例则只有1,3被使用,2和4不会被用到)例如图1。在快速网络接口中有很大的网络流量,cpu会迅速变成瓶颈。因此能够使用所有可用的cpu是决定因素。

image

图1

There are at least three ways to modify the allocation of VIFs on netback processes: 
modify the order in which VMs are first started; 
modify the order of declared VIFs (on VMs); and, 
add dummy VIFs to VMs.

Continuing with the working example from §3, suppose we find that all guest-level network traffic is going through the second VIF of each VM, and that all VMs require roughly the same network throughput. There are two simple solutions to achieving optimal network throughput here: 
  1. Add a VIF to each VM, restart host, start VMs in order — the second VIFs are allocated to netback processes (in this order) 2, 1, 4, and 3. 
  2. Switch the order of the two VIFs on the third and the fourth VMs, restart host, start VMs in order — the relevant VIFs (those that were previously the second VIFs) are allocated to netback processes (in this order) 2, 4,1, and 3.

考虑到上例,假设我们发现所有客户端网络流量都是通过每个vm的第二个虚拟网卡走,并且所有vms需要大概相同的网络流量。那么有两个简单的方法来达到最优的网络流量,如下:

  •   1、给每个vm加一个vif,然后重启xenserver主机,按顺序启动vms——第二个vifs将会按2,1,4,3的顺序分配给netback进程。
  •   2、对调第三个和第四个vm上两个网卡的顺序,重启xenserver主机,按顺序启动vms,相关的VIFS(之前的第二个vifs)将会分配按2,4,1,3的顺序分配给netback进程。

 

华丽的分割线

 

以上就是摘录的,最后两行调优例子,大家可以去看下。我按照方法对调,确实会用到4个cpu,顺序是2,4,1,3。有兴趣的童鞋可以试试。





本文转自 taojin1240 51CTO博客,原文链接:http://blog.51cto.com/taotao1240/774756,如需转载请自行联系原作者

目录
相关文章
|
3月前
|
应用服务中间件 Windows
129. SAP ABAP Update Process(更新进程)的概念和设计动机解析
129. SAP ABAP Update Process(更新进程)的概念和设计动机解析
37 1
|
3月前
|
应用服务中间件 调度 数据库
SAP ABAP Update Process(更新进程)的概念和设计动机解析试读版
SAP ABAP Update Process(更新进程)的概念和设计动机解析试读版
21 0
|
1月前
|
运维 Linux Apache
LAMP架构调优(十)——Apache禁止指定目录PHP解析与错误页面优化
LAMP架构调优(十)——Apache禁止指定目录PHP解析与错误页面优化
199 2
|
7月前
|
缓存 Java 大数据
深入解析JVM调优:解决OutOfMemoryError、内存泄露、线程死锁、锁争用和高CPU消耗问题
深入解析JVM调优:解决OutOfMemoryError、内存泄露、线程死锁、锁争用和高CPU消耗问题
94 0
|
9月前
|
存储 监控 算法
Java虚拟机 G1 GC 调优解析
在上篇文章中,我们解析了 Java 虚拟机体系生态中基于 CMS GC 策略的调优场景及基本案例,具体链接为:Java虚拟机 CMS GC 调优解析。本文则重点介绍另一款当前比较流行的 GC 策略 - G1。
229 0
|
9月前
|
前端开发 Java
Java虚拟机 CMS GC 调优解析
随着 JDK 版本的不断升级,其 GC 策略也随之不停革新,从早期的 1.4 到如今的 11(本文仅讨论在线上环境落地规模较大的版本),其对应的 GC 策略也随之由 Serial、Parallel、CMS 演进至当前的 G1 甚至即将落地的 ZGC 。每一次的调整无不是基于环境的适配性以及业务场景特性,无论如何,只要能够基于特定的操作系统内核、物理内存、JDK版本以及业务特性,达到收益最大化,采用何种实现策略都不为过。当然,还是建议大家以官方的推荐为准,基于自己的业务场景进行不断优化调整,这样才能保证万无一失,使得我们的业务能够健康发展。
92 0
|
机器学习/深度学习 缓存 分布式计算
建议收藏!详细解析如何对spark进行全方位的调优
建议收藏!详细解析如何对spark进行全方位的调优
157 0
建议收藏!详细解析如何对spark进行全方位的调优
|
缓存 Java 程序员
JVM参数调优实例解析
原文出处:http://developer.51cto.com/art/201003/186339.htm   关于JVM参数调优,对于很多程序员来说都是很头痛的问题,如果设置的不好,JVM不断执行Full GC,将导致整个系统变得很慢,网站停滞时间能达10秒以上,这种情况如果没隔几分钟就来一次,自己都受不了。
1627 0
|
Web App开发 关系型数据库 MySQL
mysql 协议的process kill包及解析
git https://github.com/sea-boat/mysql-protocol 概况 mysql客户端可以用process kill命令让服务端终止某个连接,正常会返回ok包。
1063 0
|
Java
JVM快速调优手册v1.0之四:堆内存分配的CMS公式解析
     一.JVM 堆内存组成 Java堆由Perm区和Heap区组成,Heap区由Old区和New区(也叫Young区)组成,New区由Eden区、From区和To区(Survivor)组成。
1132 0

推荐镜像

更多