{"id":34335,"date":"2019-10-31T21:57:43","date_gmt":"2019-10-31T18:57:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\/"},"modified":"2019-10-31T21:57:43","modified_gmt":"2019-10-31T18:57:43","slug":"analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","title":{"rendered":"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/0c077a1754c2e32c1f339999ceacf03a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIf you manage a virtual infrastructure based on VMware vSphere (or any other technology stack), you probably hear complaints from users frequently: \"The virtual machine is running slowly!\" In this series of articles, I will discuss performance metrics and explain what causes the \"slowdown\" and how to prevent it.<\/p>\n<p>I will consider the following aspects of virtual machine performance:<\/p>\n<ul>\n<li>CPU,<\/li>\n<li>RAM,<\/li>\n<li>DISK,<\/li>\n<li>Network.<\/li>\n<\/ul>\n<p>\nLet's start with CPU.<\/p>\n<p>To analyze performance, we will need:<\/p>\n<ul>\n<li><b>vCenter Performance Counters<\/b> \u2013 performance counters, the graphs of which can be viewed through the vSphere Client. Information from these counters is available in any version of the client (the \u201cthick\u201d client in C#, web client in Flex, and web client in HTML5). In these articles, we will use screenshots from the C# client simply because they look better in thumbnail view :)<\/li>\n<li><b>ESXTOP<\/b> \u2013 a utility that runs from the ESXi command line. It allows you to obtain real-time performance counter values or export those values over a specified period to a .csv file for further analysis. I will discuss this tool in more detail and provide some useful links to documentation and articles on the subject.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>A Bit of Theory<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/bc415aace7653c45850d26b7104483c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn ESXi, each vCPU (virtual machine core) is managed by a separate process called a world in VMware terminology. There are also system processes, but from the perspective of VM performance analysis, they are less interesting.<\/p>\n<p>A process in ESXi can be in one of four states:<\/p>\n<ul>\n<li><b>Run<\/b> \u2013 the process is performing some useful work.<\/li>\n<li><b>Wait<\/b> \u2013 the process is not doing any work (idle) or is waiting for input\/output.<\/li>\n<li><b>Costop<\/b> \u2013 a condition that occurs in multi-core virtual machines. It arises when the CPU scheduler of the hypervisor (ESXi CPU Scheduler) cannot schedule simultaneous execution on the server's physical cores for all active virtual machine cores. In the physical world, all CPU cores operate in parallel, and the guest OS within the VM expects similar behavior; therefore, the hypervisor has to throttle the VM cores that can complete a cycle faster. In modern versions of ESXi, the CPU scheduler uses a mechanism called relaxed co-scheduling: the hypervisor monitors the gap between the \"fastest\" and the \"slowest\" core of the virtual machine (skew). If the gap exceeds a certain threshold, the \"fast\" core enters the costop state. If the VM cores spend a lot of time in this state, it can lead to performance issues.<\/li>\n<li><b>Ready<\/b> \u2013 the process enters this state when the hypervisor has no resources available to allocate for its execution. High values of ready can cause performance problems for the VM.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Key performance counters for the virtual machine's CPU<\/h3>\n<p>\n<b>CPU Usage, %<\/b> Shows the percentage of CPU usage over a specified period.<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/7a5da7dcd45329c3aae8e394c5d35a30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>How to analyze?<\/b> If the VM consistently uses 90% CPU or has spikes up to 100%, then we have issues. Problems can manifest not only as \"slow\" application performance within the VM but also as network unavailability of the VM. If the monitoring system shows that the VM periodically disconnects, pay attention to the spikes on the CPU Usage graph.<\/p>\n<p>There is a standard Alarm that shows the CPU load of the virtual machine:<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/9bfd9bb5b43b9b02e8bbfac307d6c9f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>What to do?<\/b> If the VM's CPU Usage constantly exceeds limits, consider increasing the number of vCPUs (unfortunately, this doesn't always help) or migrating the VM to a server with more powerful processors.<\/p>\n<h3>CPU Usage in MHz<\/h3>\n<p>\nIn the vCenter Usage charts in %, you can only view the total for the entire virtual machine, as there are no individual core graphs (in Esxtop, core values in % are available). You can check Usage in MHz for each core.<\/p>\n<p><b>How to analyze?<\/b> Sometimes an application is not optimized for multi-core architecture: it only utilizes one core at 100%, while the others remain idle. For example, with default MS SQL backup settings, the process runs only on a single core. As a result, the backup slows down not due to slow disk speeds (which is what the user initially complained about), but because the processor is overwhelmed. The problem was resolved by changing the parameters: the backup began running in parallel across multiple files (and consequently, in multiple processes).<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/d1bce5fe5ef89a69c31a6a8f043d5d24.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Example of uneven core workload.<\/i><\/p>\n<p>There can also be a situation (as shown in the graph above) when the cores are unevenly loaded, with some peaking at 100%. Just like with the load on a single core, the CPU Usage alarm will not trigger (it applies to the entire VM), but performance issues will occur.<\/p>\n<p><b>What to do? <\/b>If the software in the virtual machine loads the cores unevenly (utilizing only one core or part of the cores), it makes no sense to increase their number. In this case, it\u2019s better to move the VM to a server with more powerful processors.<\/p>\n<p>You can also check the power settings in the server's BIOS. Many administrators enable the High Performance mode in BIOS, thereby disabling energy-saving technologies like C-states and P-states. Modern Intel processors use Turbo Boost technology, which increases the frequency of individual processor cores at the expense of others. However, this only works when energy-saving technologies are enabled. If we disable them, the processor cannot reduce the power consumption of cores that are not under load. <\/p>\n<p>VMware recommends not to disable energy-saving technologies on servers, but to choose modes that give maximum control of power consumption to the hypervisor. In the hypervisor\u2019s power settings, the High Performance mode should be selected. <\/p>\n<p>If you have certain VMs (or VM cores) in your infrastructure that require higher CPU frequencies, properly configuring power consumption can significantly improve their performance.<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/59aec2b77fa87e413d90371a11388629.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>CPU Ready (Readiness) <\/h3>\n<p>\nIf the VM core (vCPU) is in the Ready state, it is not performing any useful work. This state occurs when the hypervisor cannot find a free physical core to assign the vCPU process of the virtual machine.<\/p>\n<p><b>How to analyze?<\/b> Typically, if the virtual machine cores are in the Ready state for more than 10% of the time, you will notice performance issues. In simple terms, more than 10% of the time the VM is waiting for physical resources to become available.<\/p>\n<p>In vCenter, you can view 2 counters related to CPU Ready:<\/p>\n<ul>\n<li>Readiness,<\/li>\n<li>Ready.<\/li>\n<\/ul>\n<p>\nThe values of both counters can be viewed both for the entire VM and for individual cores.<br \/>\nReadiness shows the value in percentage, but only in Real-time (data from the last hour, measurement interval of 20 seconds). This counter is best used only to identify 'in-the-moment' issues.<\/p>\n<p>The values of the Ready counter can also be viewed historically. This is useful for identifying patterns and for deeper analysis of the problem. For example, if a virtual machine starts experiencing performance issues at a certain time, you can correlate the intervals of increased CPU Ready with the overall load on the server where that VM operates and take steps to reduce the load (if DRS has not resolved it).<\/p>\n<p>Unlike Readiness, Ready is displayed in milliseconds instead of percentages. This is a Summation type counter, meaning it shows how much time the VM core was in the Ready state over the measurement period. You can convert this value to a percentage using a simple formula:<\/p>\n<p>(CPU ready summation value \/ (chart default update interval in seconds * 1000)) * 100 = CPU ready %<\/p>\n<p>For example, for the VM in the chart below, the peak Ready value for the entire virtual machine will be as follows: <\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/3e2df8bca55b572502d88b838cbc306e.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f0371c9cd655c1e4785e90debde61dc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWhen calculating the Ready value in percentages, it is important to pay attention to two points:<\/p>\n<ul>\n<li>The Ready value for the entire VM is the sum of Ready across the cores.<\/li>\n<li>The measurement interval. For Real-time, it is 20 seconds, and for daily charts, it is 300 seconds.<\/li>\n<\/ul>\n<p>\nDuring active troubleshooting, these simple points can easily be overlooked, wasting valuable time trying to resolve non-existent issues. <\/p>\n<p>We will calculate Ready based on the data from the chart below. (324474\/(20*1000))*100 = 1622% for the entire VM. If we look at the cores, it doesn't seem as alarming: 1622\/64 = 25% per core. In this case, it's quite easy to spot the issue: the Ready value is unrealistic. However, if we're talking about 10\u201320% for the entire VM with multiple cores, the value per core may be within the normal range.<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/703ab2b1f1fab8bda10aad781c2cef78.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>What to do? <\/b>A high Ready value indicates that the server lacks CPU resources for the proper functioning of virtual machines. In this situation, the only option is to reduce the CPU overcommitment (vCPU:pCPU). Obviously, this can be achieved by either reducing the parameters of existing VMs or by migrating some VMs to other servers.<\/p>\n<h3>Co-stop<\/h3>\n<p>\n<b>How to analyze?<\/b> This counter also has a Summation type and is translated into percentages similar to Ready:<\/p>\n<p>(CPU co-stop summation value \/ (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %<\/p>\n<p>You should also pay attention to the number of cores on the VM and the measurement interval.<br \/>\nIn a co-stop state, the core is not performing useful work. With the proper VM size selection and normal server load, the co-stop counter should be close to zero.<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/e226afbf91155c2d5d3fdc4571e7383a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>In this case, the load is clearly abnormal :)<\/i><\/p>\n<p><b>What to do?<\/b> If multiple VMs with a large number of cores are running on one hypervisor and there is CPU overcommitment, the co-stop counter may increase, leading to performance issues for those VMs. <\/p>\n<p>Co-stop will also increase if active cores of one VM are using threads on a single physical core of the server with hyper-threading enabled. This situation may arise, for example, if the VM has more cores than physically available on the server it runs on, or if the 'preferHT' setting is enabled for the VM. You can read about this setting <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.vmware.com\/vsphere\/2014\/03\/perferht-use-2.html\">here<\/a><\/noindex>. <\/p>\n<p>To avoid performance issues for VMs due to high co-stop, choose the VM size according to the recommendations of the software vendor that runs on that VM and the capabilities of the physical server hosting the VM. <\/p>\n<p>Do not add extra cores as a backup; this may cause performance issues not only for the VM itself but also for its neighboring VMs on the server.<\/p>\n<h3>Other useful CPU metrics<\/h3>\n<p>\n<b>Run<\/b> \u2013 how much time (ms) in the measurement period the vCPU spent in the RUN state, meaning it was actually performing useful work.<\/p>\n<p><b>Idle<\/b> \u2013 how much time (ms) during the measurement period the vCPU was idle. High Idle values are not a problem; it simply means the vCPU had \"nothing to do.\"<\/p>\n<p><b>Wait<\/b> \u2013 how much time (ms) during the measurement period the vCPU was in a Wait state. Since IDLE is included in this counter, high Wait values also do not indicate a problem. However, if IDLE is low while Wait is high, it means the VM was waiting for I\/O operations to complete, which may indicate a performance issue with the hard disk or other virtual devices in the VM.<\/p>\n<p><b>Max limited<\/b> \u2013 how much time (ms) during the measurement period the vCPU was in a Ready state due to a resource limit set. If performance is unexplainably low, it is useful to check this counter value and the CPU limit in the VM settings. The VM may have limits set that you are unaware of. For example, this can happen when a VM is cloned from a template that had a CPU limit set.<\/p>\n<p><b>Swap wait<\/b> \u2013 how much time during the measurement period the vCPU waited for operations with VMkernel Swap. If this counter's value is above zero, the VM definitely has performance issues. We will discuss SWAP in more detail in the article about memory counters.<\/p>\n<h3>ESXTOP<\/h3>\n<p>\nWhile performance counters in vCenter are good for analyzing historical data, real-time problem analysis is better done in ESXTOP. Here, all values are presented in a ready-to-use format (no need for translation), and the minimum measurement period is 2 seconds.<br \/>\nThe ESXTOP screen for CPU is invoked by pressing the \"c\" key and looks as follows:<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f4f3611bc383007bdbaa0948001923c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor convenience, you can display only the processes of virtual machines by pressing Shift-V.<br \/>\nTo view metrics for individual VM cores, press \"e\" and enter the GID of the VM of interest (30919 in the screenshot below):<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/5f2c0226cee6e4e43128537bd4da843f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI will briefly go over the columns that are displayed by default. Additional columns can be added by pressing \"f.\"<\/p>\n<p><b>NWLD (Number of Worlds)<\/b> \u2013 the number of processes in the group. To expand the group and see metrics for each process (e.g., for each core of a multi-core VM), press \"e.\" If there is more than one process in the group, the metric values for the group equal the sum of the metrics for the individual processes.<\/p>\n<p><b>%USED<\/b> \u2013 how many CPU cycles the server uses for the process or group of processes.<\/p>\n<p><b>%RUN<\/b> \u2013 the amount of time during the measurement period that the process was in the RUN state, i.e., performing useful work. This differs from %USED in that it does not account for hyper-threading, frequency scaling, and time spent on system tasks (%SYS).<\/p>\n<p><b>%SYS<\/b> \u2013 time spent on system tasks, such as processing interrupts, input\/output, network operations, etc. The value can be high if there is significant input\/output on the VM.<\/p>\n<p><b>%OVRLP<\/b> \u2013 the amount of time a physical core executing the VM process spent on tasks of other processes.<\/p>\n<p>These metrics relate to each other as follows:<\/p>\n<p>%USED = %RUN + %SYS \u2014 %OVRLP.<\/p>\n<p>Typically, the %USED metric is more informative.<\/p>\n<p><b>%WAIT<\/b> \u2013 the amount of time during the measurement period that the process was in the Wait state. Includes IDLE.<\/p>\n<p><b>%IDLE<\/b> \u2013 the amount of time during the measurement period that the process was in the IDLE state.<\/p>\n<p><b>%SWPWT<\/b> \u2013 the amount of time during the measurement period that the vCPU waited for VMkernel Swap operations.<\/p>\n<p><b>%VMWAIT<\/b> \u2013 the amount of time during the measurement period that the vCPU was in a waiting state for an event (typically input\/output). There is no equivalent counter in vCenter. High values indicate issues with input\/output on the VM.<\/p>\n<p>%WAIT = %VMWAIT + %IDLE + %SWPWT.<\/p>\n<p>If the VM does not use VMkernel Swap, it is advisable to focus on %VMWAIT when analyzing performance issues, as this metric does not take into account the time when the VM did nothing (%IDLE).<\/p>\n<p><b>%RDY<\/b> \u2013 the amount of time during the measurement period that the process was in the Ready state.<\/p>\n<p><b>%CSTP<\/b> \u2013 the amount of time during the measurement period that the process was in the costop state.<\/p>\n<p><b>%MLMTD<\/b> \u2013 the amount of time during the measurement period that the vCPU was in the Ready state due to a set resource limit.<\/p>\n<p>%WAIT + %RDY + %CSTP + %RUN = 100% \u2013 the core of the VM is always in one of these four states.<\/p>\n<h3>CPU on the hypervisor<\/h3>\n<p>\nvCenter also has CPU performance counters for the hypervisor, but they offer nothing interesting \u2013 they are just the sum of counters across all VMs on the server.<br \/>\nThe easiest way to view the CPU state on the server is on the Summary tab:<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/15b6b9a6da136d892fbaf7f80fc206c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFor the server, as for the virtual machine, there is a standard Alarm:<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/c3ae19ce3acd55cfff40d71437ee3a08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUnder heavy CPU load on the server, VMs running on it begin to experience performance problems.<\/p>\n<p>In ESXTOP, CPU load data for the server is presented at the top of the screen. In addition to the standard CPU load, which is not very informative for hypervisors, there are three other metrics:<\/p>\n<p><b>CORE UTIL(%)<\/b> \u2013 load on the physical server core. This counter shows how much time the core spent working during the measurement period.<\/p>\n<p><b>PCPU UTIL(%)<\/b> \u2013 if hyper-threading is enabled, each physical core corresponds to two threads (PCPU). This metric shows how much time each thread spent working.<\/p>\n<p><b>PCPU USED(%)<\/b> \u2013 the same as PCPU UTIL(%), but takes into account frequency scaling (either reducing the core frequency for energy saving or increasing the core frequency due to Turbo Boost technology) and hyper-threading.<\/p>\n<p>PCPU_USED% = PCPU_UTIL% * effective core frequency \/ nominal core frequency.<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/dd8562ea91bee55bbf630358df26c217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>In this screenshot, for some cores, due to Turbo Boost operation, the USED value is above 100%, as the core frequency is higher than the nominal frequency.<\/i><\/p>\n<p>A few words on how hyper-threading is accounted for. If processes are executed 100% of the time on both threads of the physical server core, and the core operates at nominal frequency, then:<\/p>\n<ul>\n<li>CORE UTIL for the core will be 100%,<\/li>\n<li>PCPU UTIL for both threads will be 100%,<\/li>\n<li>PCPU USED for both threads will be 50%.<\/li>\n<\/ul>\n<p>\nIf both threads did not operate 100% of the time during the measurement period, then in the periods when the threads worked in parallel, PCPU USED for the cores is divided by two.<\/p>\n<p>ESXTOP also has a screen with CPU power consumption parameters for the server. Here you can check whether the server is using energy-saving technologies: C-states and P-states. It is accessed by pressing the 'p' key:<\/p>\n<p><img decoding=\"async\" alt=\"Performance analysis of a virtual machine in VMware vSphere. Part 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/531bf847b99f86bec0bd90e005919c79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Standard CPU Performance Issues<\/h3>\n<p>\nLastly, I will briefly cover the typical reasons for CPU performance issues in VMs and provide some quick tips for their resolution:<\/p>\n<p><b>Insufficient core clock frequency.<\/b> If it's not possible to move the VM to more powerful cores, try changing the power settings to enable Turbo Boost to work more effectively.<\/p>\n<p><b>Incorrect VM sizing (too many\/few cores).<\/b> If too few cores are allocated, there will be high CPU load on the VM. If too many, you will encounter high co-stop.<\/p>\n<p><b>High CPU overcommitment on the server.<\/b> If the VM shows high Ready, reduce the CPU overcommitment.<\/p>\n<p><b>Incorrect NUMA topology on large VMs.<\/b> The NUMA topology visible to the VM (vNUMA) should match the server's NUMA topology (pNUMA). There is a discussion about diagnostics and possible solutions for this issue in the book <noindex><a rel=\"nofollow\" href=\"https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html\">\u201cVMware vSphere 6.5 Host Resources Deep Dive\u201d<\/a><\/noindex>. If you don't want to delve deeply into it and have no licensing restrictions for the OS installed on the VM, create multiple virtual sockets with one core each. You won't lose much \ud83d\ude42<\/p>\n<p>That's all I have on CPU. Feel free to ask questions. In the next part, I'll discuss RAM.<\/p>\n<p><b class=\"spoiler_title\">Useful links<\/b><noindex><a rel=\"nofollow\" href=\"http:\/\/virtual-red-dot.info\/vm-cpu-counters-vsphere\/\">http:\/\/virtual-red-dot.info\/vm-cpu-counters-vsphere\/<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/kb.vmware.com\/kb\/1017926\">https:\/\/kb.vmware.com\/kb\/1017926<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.yellow-bricks.com\/2012\/07\/17\/why-is-wait-so-high\/\">http:\/\/www.yellow-bricks.com\/2012\/07\/17\/why-is-wait-so-high\/<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/communities.vmware.com\/docs\/DOC-9279\">https:\/\/communities.vmware.com\/docs\/DOC-9279<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/www.vmware.com\/content\/dam\/digitalmarketing\/vmware\/en\/pdf\/techpaper\/performance\/whats-new-vsphere65-perf.pdf\">https:\/\/www.vmware.com\/content\/dam\/digitalmarketing\/vmware\/en\/pdf\/techpaper\/performance\/whats-new-vsphere65-perf.pdf<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html\">https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html<\/a><\/noindex><br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataline\/blog\/452884\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0415\u0441\u043b\u0438 \u0432\u044b \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0438\u0440\u0443\u0435\u0442\u0435 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043d\u0430 \u0431\u0430\u0437\u0435 VMware vSphere (\u0438\u043b\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0434\u0440\u0443\u0433\u043e\u0433\u043e \u0441\u0442\u0435\u043a\u0430 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439), \u0442\u043e \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u0447\u0430\u0441\u0442\u043e \u0441\u043b\u044b\u0448\u0438\u0442\u0435 \u043e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0436\u0430\u043b\u043e\u0431\u044b: \u00ab\u0412\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0430\u044f \u043c\u0430\u0448\u0438\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043c\u0435\u0434\u043b\u0435\u043d\u043d\u043e!\u00bb. \u0412 \u044d\u0442\u043e\u043c \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u0440\u0430\u0437\u0431\u0435\u0440\u0443 \u043c\u0435\u0442\u0440\u0438\u043a\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0438 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u0447\u0442\u043e \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u00ab\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442\u00bb \u0438 \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0442\u0430\u043a, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u00ab\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u043b\u043e\u00bb. \u0411\u0443\u0434\u0443 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0435 \u0430\u0441\u043f\u0435\u043a\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d: CPU, RAM, DISK, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25892,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34335","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u043d\u0430\u043b\u0438\u0437 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u044b \u0432 VMware vSphere. \u0427\u0430\u0441\u0442\u044c 1: CPU | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:57:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:57:43+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Performance analysis of virtual machines in VMware vSphere. Part 1: CPU | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u043d\u0430\u043b\u0438\u0437 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u044b \u0432 VMware vSphere. \u0427\u0430\u0441\u0442\u044c 1: CPU | ProHoster","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:57:43+00:00","article:modified_time":"2019-10-31T18:57:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34335","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 18:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:23:17","updated":"2026-01-21 18:48:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/34335","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=34335"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/34335\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/25892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=34335"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=34335"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=34335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}