一会儿，我玩了一些新的Win2008虚拟机，发现了一些严重的问题。 服务器是Dell T610。 16Gig，4核心，8逻辑，2.4ghz Xeon，5600系列。 ESXi 4.1.0 guest是2008 64bit，带有2vCPU 我一直在用400meg的文件使用7Zip来testingCPU性能。 我们的服务器需求特别需要单线程性能，所以我只用一个线程运行7Zip。 7zip在虚拟机上运行4:50。 为了比较，在最近的2ghz，4core服务器上，这个过程需要4点。 这里显然是一个问题。 所以我试着设置7Zip.exe进程的进程亲和力。 这一次压缩只花了3:20。 请注意，在物理机器上设置相似性没有区别。 （同样快，打开或closures）在物理和虚拟机上，当没有设置亲和性时，可以看到taskman中所有内核之间的进程） 具有讽刺意味的是，在负载很重的机器上，任务会更快完成，因为它们更有可能保持在同一个CPU上。 问题是，为什么Windows有这样一个失去处理器亲和力，当Linux不？
我需要replace我的XenServer 6.1资源池硬件。 我目前运行英特尔硬件，我不得不移动到AMD硬件（企业的政治和预算的东西，等等等等）。 我有停机时间，所以我可以使用冷迁移 – 不需要实时迁移。 除了旧硬件（英特尔）之外，我还将拥有新的硬件（AMD）。 XenServer文档说可能会出现问题，从一个拱出口，并导入到另一个“可能无法正常工作” – http://docs.vmd.citrix.com/XenServer/6.1.0/1.0/en_gb/guest.html#importing_vms -但没有提到closures一个拱门上的虚拟机，然后重新启动新拱门。 虚拟机是一个混合的操作系统 – 一些Windows，一些Linux，多个版本。 这是可以做到没有问题，或者我需要注意的问题吗？
AFAIK许多现代的CPU有计数器的内存caching未命中/命中。 有没有可以查询这个API /程序？ 有没有办法重置柜台？ 我对任何通用或CPU特定的程序感兴趣。 注：我知道cachegrind，但这是一个模拟，而不是实际的CPU计数器。
我正在search一个程序来显示我的KVM客人的RAM和CPU使用情况。 我发现昨天工作的virt-top非常好。 今天我又开始了，它不想工作： virt-top 19:46:51 – x86_64 2/2CPU 1795MHz 5713MB 4 domains, 0 active, 0 running, 0 sleeping, 0 paused, 4 inactive D:0 O:0 X:0 CPU: 0,0% Mem: 0 MB (0 MB by guests) ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME – (105) – (106) – (107) – (109) 它说“4无效”，但那是错误的。 请参阅qm列表：qm列表 VMID […]
我使用RHEV-M来pipe理具有多个RHEVpipe理程序节点的集群。 目前，每个节点有2个CPUsockets。 我的问题是，我可以在RHEV集群中添加另一个有4个套接字的节点，当我这样做时，调度将如何进行。 所有的CPU都是AMD，完全一样。
AMD Opteron CPU销售服务器，FX CPU销售台式机。 但是，两者都支持ECC，而只有Opteron支持注册RAM，这个问题与可靠性无关 。 那么，皓龙更适合服务器呢？ 他们是否更有弹性在CPU本身的单事件翻转？
我知道linux'top'报告的系统负载是等待CPU时间的平均进程数量，因此在解释负载时应考虑CPU核心数量。 因此，4核心系统上的4负载rougly等于单个核心系统上的负载1。 我的问题是：对于CPU内核不直接映射到处理器的虚拟服务器，情况也是这样吗？
在过去几天里，我遇到了一个问题：每隔10-15分钟，我的整个服务器就无法响应，closures所有TCP连接大约3分钟。 我终于发现连接被closures了，因为在这3分钟的时间内，所有16个内核都能稳定，稳定的100％CPU。 我正在积极尝试找出什么是最大的CPU，但是，作为服务器上的一切完全冻结（即使在控制台），我无法快速检查，以了解它是什么。 这显然是个大问题，我需要马上处理。 有什么方法可以logging这个CPU峰值并将其与其他stream量区分开来吗？
看来，IIS7默认情况下不会在其日志中启用发送的字节和字节接收字段。 我想启用它们，以便我可以观察个别站点的带宽消耗，但是我的服务器资源短缺，几乎无法保持现状。 这会不会影响内存消耗？ CPU使用情况如何？ 还是总体上有什么样的performance呢？
在Ubuntu 12.04系统上，我正在运行redis。 我们的监视看着redis进程，并抓住/ proc / pid / stats中的CPU利用率。 大。 几十秒钟，这个数字根本不增加，然后突然增加了几千。 它继续以这种方式爆发。 在不增加的时候，redis的响应速度非常快，报告已经完成了数百个操作。 很明显，它正在计划和运行。 （更新：对我们来说，它似乎只发生在我们的Ubuntu 3.13.0-48系统上，运行类似服务的内核3.5.x的系统没有遇到这个问题）。 这种方式（用户和系统）的使用方式是什么意思？ 有什么可以设置纠正吗？