{"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\/pt\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","title":{"rendered":"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/0c077a1754c2e32c1f339999ceacf03a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe voc\u00ea administra uma infraestrutura virtual baseada em VMware vSphere (ou qualquer outro conjunto de tecnologias), provavelmente ouve frequentemente reclama\u00e7\u00f5es dos usu\u00e1rios: \"A m\u00e1quina virtual est\u00e1 lenta!\" Neste ciclo de artigos, vou abordar as m\u00e9tricas de desempenho e explicar o que e por que \"est\u00e1 lento\" e como evitar que isso aconte\u00e7a.<\/p>\n<p>Vou considerar os seguintes aspectos do desempenho das m\u00e1quinas virtuais:<\/p>\n<ul>\n<li>CPU,<\/li>\n<li>RAM,<\/li>\n<li>DISCO,<\/li>\n<li>Rede.<\/li>\n<\/ul>\n<p>\nCome\u00e7arei com a CPU.<\/p>\n<p>Para analisar o desempenho, precisaremos de:<\/p>\n<ul>\n<li><b>Contadores de Desempenho do vCenter<\/b> \u2013 contadores de desempenho cujos gr\u00e1ficos podem ser visualizados atrav\u00e9s do vSphere Client. As informa\u00e7\u00f5es desses contadores est\u00e3o dispon\u00edveis em qualquer vers\u00e3o do cliente (cliente \"gordo\" em C#, cliente web em Flex e cliente web em HTML5). Neste artigo, utilizaremos capturas de tela do cliente em C#, apenas porque ficam melhores em miniatura:)<\/li>\n<li><b>ESXTOP<\/b> \u2013 uma ferramenta que \u00e9 executada a partir da linha de comando do ESXi. Com ela, \u00e9 poss\u00edvel obter valores dos contadores de desempenho em tempo real ou exportar esses valores durante um per\u00edodo espec\u00edfico para um arquivo .csv para an\u00e1lise posterior. A seguir, falarei mais sobre essa ferramenta e fornecerei alguns links \u00fateis para documenta\u00e7\u00e3o e artigos sobre o tema.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Um pouco de teoria<\/h3>\n<p>\n<img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/bc415aace7653c45850d26b7104483c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo ESXi, cada vCPU (n\u00facleo da m\u00e1quina virtual) \u00e9 controlado por um processo separado \u2013 world, na terminologia da VMware. Tamb\u00e9m existem processos auxiliares, mas, do ponto de vista da an\u00e1lise de desempenho da VM, eles s\u00e3o menos interessantes.<\/p>\n<p>Um processo no ESXi pode estar em um dos quatro estados:<\/p>\n<ul>\n<li><b>Run<\/b> \u2013 o processo est\u00e1 realizando algum trabalho \u00fatil.<\/li>\n<li><b>Aguardar<\/b> \u2013 o processo n\u00e3o est\u00e1 realizando nenhum trabalho (inativo) ou est\u00e1 aguardando entrada\/sa\u00edda.<\/li>\n<li><b>Costop<\/b> \u2013 uma condi\u00e7\u00e3o que ocorre em m\u00e1quinas virtuais multin\u00facleo. Ela acontece quando o agendador de CPU do hypervisor (ESXi CPU Scheduler) n\u00e3o consegue agendar a execu\u00e7\u00e3o simult\u00e2nea em n\u00facleos f\u00edsicos do servidor para todos os n\u00facleos ativos da m\u00e1quina virtual. No mundo f\u00edsico, todos os n\u00facleos de processador operam em paralelo; o sistema operacional convidado dentro da VM conta com um comportamento semelhante, portanto, o hypervisor precisa desacelerar os n\u00facleos da VM que t\u00eam a capacidade de completar um ciclo mais rapidamente. Nas vers\u00f5es modernas do ESXi, o agendador de CPU utiliza um mecanismo chamado co-agendamento relaxado: o hypervisor considera a diferen\u00e7a entre o n\u00facleo<\/li>\n<li><b>Pronto<\/b> \u2013 o processo entra neste estado quando o hiperconector n\u00e3o consegue alocar recursos para a sua execu\u00e7\u00e3o. Valores altos de ready podem causar problemas de desempenho na VM.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Principais contadores de desempenho de CPU da m\u00e1quina virtual<\/h3>\n<p>\n<b>Uso de CPU, %.<\/b> Mostra a porcentagem de utiliza\u00e7\u00e3o da CPU durante um per\u00edodo determinado.<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/7a5da7dcd45329c3aae8e394c5d35a30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Como analisar?<\/b> Se a VM utiliza a CPU de forma est\u00e1vel a 90% ou apresenta picos de at\u00e9 100%, isso indica problemas. Os problemas podem se manifestar n\u00e3o somente com a lentid\u00e3o do aplicativo dentro da VM, mas tamb\u00e9m com a indisponibilidade da VM na rede. Se o sistema de monitoramento mostra que a VM est\u00e1 desconectando periodicamente, preste aten\u00e7\u00e3o aos picos no gr\u00e1fico de Uso de CPU.<\/p>\n<p>H\u00e1 um Alarme padr\u00e3o que mostra a carga da CPU da m\u00e1quina virtual:<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/9bfd9bb5b43b9b02e8bbfac307d6c9f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>O que fazer?<\/b> Se a Utiliza\u00e7\u00e3o de CPU da VM est\u00e1 constantemente alta, considere aumentar o n\u00famero de vCPUs (infelizmente, isso nem sempre ajuda) ou mover a VM para um servidor com processadores mais potentes.<\/p>\n<h3>Uso de CPU em Mhz<\/h3>\n<p>\nNos gr\u00e1ficos de Uso no vCenter em %, \u00e9 poss\u00edvel visualizar apenas para toda a m\u00e1quina virtual, n\u00e3o h\u00e1 gr\u00e1ficos para n\u00facleos individuais (no Esxtop, os valores em % por n\u00facleo est\u00e3o dispon\u00edveis). Para cada n\u00facleo, \u00e9 poss\u00edvel consultar o Uso em MHz.<\/p>\n<p><b>Como analisar?<\/b> \u00c0s vezes, um aplicativo n\u00e3o est\u00e1 otimizado para a arquitetura multicloud: utiliza 100% apenas um n\u00facleo, enquanto os outros permanecem ociosos. Por exemplo, com as configura\u00e7\u00f5es padr\u00e3o, o backup do MS SQL \u00e9 executado apenas em um n\u00facleo. Como resultado, o backup \u00e9 lento n\u00e3o por causa da baixa velocidade dos discos (que foi o que o usu\u00e1rio reclamou inicialmente), mas devido \u00e0 incapacidade do processador. O problema foi resolvido alterando as configura\u00e7\u00f5es: o backup come\u00e7ou a ser executado em paralelo em v\u00e1rios arquivos (portanto, em v\u00e1rios processos).<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/d1bce5fe5ef89a69c31a6a8f043d5d24.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Exemplo de carga desigual entre n\u00facleos.<\/i><\/p>\n<p>Tamb\u00e9m h\u00e1 situa\u00e7\u00f5es (como mostrado no gr\u00e1fico acima), onde os n\u00facleos est\u00e3o carregados de maneira desigual e alguns deles apresentam picos de 100%. Assim como ocorre ao carregar apenas um n\u00facleo, o alerta de Uso de CPU n\u00e3o ser\u00e1 acionado (ele \u00e9 geral na VM), mas haver\u00e3o problemas de desempenho.<\/p>\n<p><b>O que fazer? <\/b>Se o software na m\u00e1quina virtual sobrecarrega os n\u00facleos de maneira desigual (utiliza apenas um n\u00facleo ou parte dos n\u00facleos), n\u00e3o faz sentido aumentar sua quantidade. Nesse caso, \u00e9 melhor mover a VM para um servidor com processadores mais potentes.<\/p>\n<p>Voc\u00ea tamb\u00e9m pode tentar verificar as configura\u00e7\u00f5es de consumo de energia na BIOS do servidor. Muitos administradores ativam o modo Alto Desempenho na BIOS e, assim, desativam as tecnologias de economia de energia C-states e P-states. Nos processadores Intel modernos, \u00e9 utilizada a tecnologia Turbo Boost, que aumenta a frequ\u00eancia de n\u00facleos individuais do processador em detrimento de outros n\u00facleos. Mas isso s\u00f3 funciona quando as tecnologias de economia de energia est\u00e3o ativadas. Se as desativamos, o processador n\u00e3o consegue reduzir o consumo de energia dos n\u00facleos que n\u00e3o est\u00e3o carregados. <\/p>\n<p>A VMware recomenda n\u00e3o desativar as tecnologias de economia de energia nos servidores, mas sim escolher modos que entreguem ao hipervisor o m\u00e1ximo de controle sobre o consumo de energia. Nesse caso, nas configura\u00e7\u00f5es de consumo de energia do hipervisor, deve-se escolher o modo Alto Desempenho. <\/p>\n<p>Se em sua infraestrutura, VMs separadas (ou n\u00facleos de VMs) exigem uma frequ\u00eancia de CPU aumentada, a configura\u00e7\u00e3o correta do consumo de energia pode melhorar significativamente seu desempenho.<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/59aec2b77fa87e413d90371a11388629.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>CPU Ready (Prontid\u00e3o) <\/h3>\n<p>\nSe o n\u00facleo da VM (vCPU) estiver no estado Ready, ele n\u00e3o est\u00e1 realizando trabalho \u00fatil. Esse estado ocorre quando o hypervisor n\u00e3o encontra um n\u00facleo f\u00edsico livre ao qual pode atribuir o processo vCPU da m\u00e1quina virtual.<\/p>\n<p><b>Como analisar?<\/b> Geralmente, se os n\u00facleos da m\u00e1quina virtual estiverem no estado Ready por mais de 10% do tempo, voc\u00ea notar\u00e1 problemas de desempenho. Em termos simples, mais de 10% do tempo a VM est\u00e1 aguardando a disponibilidade de recursos f\u00edsicos.<\/p>\n<p>No vCenter, \u00e9 poss\u00edvel ver 2 contadores relacionados ao CPU Ready:<\/p>\n<ul>\n<li>Readiness,<\/li>\n<li>Ready.<\/li>\n<\/ul>\n<p>\nOs valores de ambos os contadores podem ser vistos tanto para toda a VM quanto para n\u00facleos individuais.<br \/>\nO Readiness mostra o valor imediatamente em porcentagens, mas apenas em tempo real (dados da \u00faltima hora, intervalo de medi\u00e7\u00e3o de 20 segundos). Esse contador \u00e9 melhor utilizado apenas para identificar problemas \"no calor do momento\".<\/p>\n<p>Os valores do contador Ready tamb\u00e9m podem ser vistos em uma perspectiva hist\u00f3rica. Isso \u00e9 \u00fatil para estabelecer padr\u00f5es e para uma an\u00e1lise mais profunda do problema. Por exemplo, se uma m\u00e1quina virtual come\u00e7a a ter problemas de desempenho em um determinado hor\u00e1rio, \u00e9 poss\u00edvel correlacionar os intervalos de aumento do valor do CPU Ready com a carga total no servidor onde a VM est\u00e1 operando, e tomar medidas para reduzir a carga (caso o DRS n\u00e3o tenha resolvido).<\/p>\n<p>Diferente do Readiness, o Ready \u00e9 mostrado n\u00e3o em porcentagens, mas em milissegundos. Este contador \u00e9 do tipo Summation, ou seja, ele indica quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o n\u00facleo da VM ficou no estado Ready. Esse valor pode ser convertido em porcentagens por uma f\u00f3rmula simples:<\/p>\n<p>(valor de soma\u00e7\u00e3o do CPU ready \/ (intervalo de atualiza\u00e7\u00e3o padr\u00e3o do gr\u00e1fico em segundos * 1000)) * 100 = CPU ready %<\/p>\n<p>Por exemplo, para a VM no gr\u00e1fico abaixo, o valor m\u00e1ximo de Ready para toda a m\u00e1quina virtual ser\u00e1 o seguinte: <\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/3e2df8bca55b572502d88b838cbc306e.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f0371c9cd655c1e4785e90debde61dc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAo calcular o valor de Ready em porcentagens, \u00e9 importante prestar aten\u00e7\u00e3o a dois pontos:<\/p>\n<ul>\n<li>O valor de Ready para toda a VM \u00e9 a soma do Ready nos n\u00facleos.<\/li>\n<li>O intervalo de medi\u00e7\u00e3o. Para Real-time, \u00e9 de 20 segundos, enquanto, por exemplo, nos gr\u00e1ficos di\u00e1rios, \u00e9 de 300 segundos.<\/li>\n<\/ul>\n<p>\nDurante uma solu\u00e7\u00e3o de problemas ativa, \u00e9 f\u00e1cil ignorar esses pontos simples e desperdi\u00e7ar tempo valioso resolvendo problemas inexistentes. <\/p>\n<p>Vamos calcular o Ready com base nos dados do gr\u00e1fico abaixo. (324474\/(20*1000))*100 = 1622% para toda a VM. Se olharmos por n\u00facleos, a situa\u00e7\u00e3o j\u00e1 n\u00e3o \u00e9 t\u00e3o assustadora: 1622\/64 = 25% por n\u00facleo. Neste caso, descobrir o engano \u00e9 bastante simples: o valor de Ready \u00e9 irrealista. Mas se estamos falando de 10\u201320% para toda a VM com v\u00e1rios n\u00facleos, ent\u00e3o o valor por n\u00facleo pode estar dentro da norma.<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/703ab2b1f1fab8bda10aad781c2cef78.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>O que fazer? <\/b>Um alto valor de Ready indica que o servidor carece de recursos de CPU para o funcionamento adequado das m\u00e1quinas virtuais. Nessa situa\u00e7\u00e3o, a \u00fanica solu\u00e7\u00e3o \u00e9 reduzir a super-aloca\u00e7\u00e3o de CPU (vCPU:pCPU). \u00c9 evidente que isso pode ser conseguido diminuindo os par\u00e2metros das VMs existentes ou migrando parte das VMs para outros servidores.<\/p>\n<h3>Co-stop<\/h3>\n<p>\n<b>Como analisar?<\/b> Esse contador tamb\u00e9m \u00e9 do tipo Summation e \u00e9 traduzido em porcentagens de forma semelhante ao Ready:<\/p>\n<p>(valor de soma da CPU co-stop \/ (intervalo de atualiza\u00e7\u00e3o padr\u00e3o do gr\u00e1fico em segundos * 1000)) * 100 = % de co-stop da CPU<\/p>\n<p>Aqui tamb\u00e9m \u00e9 importante prestar aten\u00e7\u00e3o ao n\u00famero de n\u00facleos na VM e ao intervalo de medi\u00e7\u00e3o.<br \/>\nNo estado co-stop, o n\u00facleo n\u00e3o est\u00e1 realizando trabalho \u00fatil. Com a escolha correta do tamanho da VM e uma carga normal no servidor, o contador de co-stop deve estar pr\u00f3ximo de zero.<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/e226afbf91155c2d5d3fdc4571e7383a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Neste caso, a carga est\u00e1 claramente anormal :)<\/i><\/p>\n<p><b>O que fazer?<\/b> Se v\u00e1rias VMs com muitos n\u00facleos estiverem em um \u00fanico hipervisor e houver super-aloca\u00e7\u00e3o de CPU, o contador de co-stop pode aumentar, levando a problemas de desempenho para essas VMs. <\/p>\n<p>O co-stop tamb\u00e9m aumentar\u00e1 se threads em um \u00fanico n\u00facleo f\u00edsico do servidor com hyper-threading estiverem sendo usadas para n\u00facleos ativos de uma VM. Essa situa\u00e7\u00e3o pode ocorrer, por exemplo, se a VM tiver mais n\u00facleos do que existem fisicamente no servidor onde est\u00e1 sendo executada, ou se a configura\u00e7\u00e3o \"preferHT\" estiver ativada para a VM. Sobre essa configura\u00e7\u00e3o, voc\u00ea pode ler <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.vmware.com\/vsphere\/2014\/03\/perferht-use-2.html\">aqui<\/a><\/noindex>. <\/p>\n<p>Para evitar problemas de desempenho na VM devido a um alto co-stop, escolha o tamanho da VM de acordo com as recomenda\u00e7\u00f5es do fabricante do software que est\u00e1 sendo executado nessa VM e com as capacidades do servidor f\u00edsico onde a VM opera. <\/p>\n<p>N\u00e3o adicione n\u00facleos em excesso, isso pode causar problemas de desempenho n\u00e3o apenas na pr\u00f3pria VM, mas tamb\u00e9m nas suas vizinhas no servidor.<\/p>\n<h3>Outras m\u00e9tricas \u00fateis de CPU<\/h3>\n<p>\n<b>Run<\/b> \u2013 quanto tempo (ms) durante o per\u00edodo de medi\u00e7\u00e3o a vCPU esteve no estado RUN, ou seja, realizando trabalho \u00fatil.<\/p>\n<p><b>Idle<\/b> \u2013 quanto tempo (ms) o vCPU esteve em estado de inatividade durante o per\u00edodo de medi\u00e7\u00e3o. Altos valores de inatividade n\u00e3o s\u00e3o um problema, simplesmente significam que o vCPU n\u00e3o tinha \"o que fazer\".<\/p>\n<p><b>Aguardar<\/b> \u2013 quanto tempo (ms) o vCPU esteve em estado de espera durante o per\u00edodo de medi\u00e7\u00e3o. Como este contador inclui o IDLE, altos valores de espera tamb\u00e9m n\u00e3o indicam necessariamente um problema. No entanto, se o IDLE for baixo enquanto a espera for alta, significa que a VM estava aguardando a conclus\u00e3o de opera\u00e7\u00f5es de entrada\/sa\u00edda, o que pode indicar problemas de desempenho do disco r\u00edgido ou de dispositivos virtuais na VM.<\/p>\n<p><b>Limite m\u00e1ximo<\/b> \u2013 quanto tempo (ms) o vCPU esteve em estado de pronto devido a um limite de recursos estabelecido. Se o desempenho estiver inexplicavelmente baixo, \u00e9 \u00fatil verificar o valor deste contador e o limite de CPU nas configura\u00e7\u00f5es da VM. A VM pode realmente ter limites que voc\u00ea desconhece. Isso acontece, por exemplo, quando a VM foi clonada a partir de um modelo onde havia um limite de CPU configurado.<\/p>\n<p><b>Espera por Swap<\/b> \u2013 quanto tempo o vCPU aguardou opera\u00e7\u00f5es com o Swap do VMkernel durante o per\u00edodo de medi\u00e7\u00e3o. Se os valores deste contador forem superiores a zero, a VM certamente est\u00e1 enfrentando problemas de desempenho. Vamos falar mais sobre SWAP no artigo sobre os contadores de mem\u00f3ria.<\/p>\n<h3>ESXTOP<\/h3>\n<p>\nSe os contadores de desempenho no vCenter s\u00e3o bons para an\u00e1lise de dados hist\u00f3ricos, uma an\u00e1lise r\u00e1pida do problema \u00e9 melhor realizada no ESXTOP. Aqui, todos os valores s\u00e3o apresentados de forma acess\u00edvel (n\u00e3o h\u00e1 necessidade de tradu\u00e7\u00e3o), e o per\u00edodo m\u00ednimo de medi\u00e7\u00e3o \u00e9 de 2 segundos.<br \/>\nA tela do ESXTOP para CPU \u00e9 chamada pela tecla \"c\" e se parece com isto:<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f4f3611bc383007bdbaa0948001923c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara facilitar, voc\u00ea pode deixar apenas os processos das m\u00e1quinas virtuais pressionando Shift-V.<br \/>\nPara visualizar m\u00e9tricas de n\u00facleos individuais da VM, pressione \"e\" e insira o GID da VM de interesse (30919 na captura de tela abaixo):<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/5f2c0226cee6e4e43128537bd4da843f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVou passar rapidamente pelas colunas apresentadas por padr\u00e3o. Colunas adicionais podem ser adicionadas pressionando \"f\".<\/p>\n<p><b>NWLD (N\u00famero de Mundos)<\/b> \u2013 n\u00famero de processos no grupo. Para expandir o grupo e ver as m\u00e9tricas para cada processo (por exemplo, para cada n\u00facleo em uma VM multi-core), pressione \u201ce\u201d. Se houver mais de um processo no grupo, os valores das m\u00e9tricas do grupo s\u00e3o iguais \u00e0 soma das m\u00e9tricas de cada processo individual.<\/p>\n<p><b>%USED<\/b> \u2013 quanto ciclos de CPU o servidor utiliza o processo ou grupo de processos.<\/p>\n<p><b>%RUN<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o processo esteve no estado RUN, ou seja, realizando trabalho \u00fatil. Difere de %USED por n\u00e3o considerar hyper-threading, escalonamento de frequ\u00eancia e o tempo gasto em tarefas do sistema (%SYS).<\/p>\n<p><b>%SYS<\/b> \u2013 tempo gasto em tarefas do sistema, como processamento de interrup\u00e7\u00f5es, entrada\/sa\u00edda, funcionamento da rede, etc. O valor pode ser alto se a VM tiver muita entrada\/sa\u00edda.<\/p>\n<p><b>%OVRLP<\/b> \u2013 quanto tempo o n\u00facleo f\u00edsico, no qual o processo da VM est\u00e1 sendo executado, gastou em tarefas de outros processos.<\/p>\n<p>Essas m\u00e9tricas est\u00e3o relacionadas da seguinte forma:<\/p>\n<p>%USED = %RUN + %SYS \u2014 %OVRLP.<\/p>\n<p>Normalmente, a m\u00e9trica %USED \u00e9 mais informativa.<\/p>\n<p><b>%WAIT<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o processo esteve no estado Wait. Inclui IDLE.<\/p>\n<p><b>%IDLE<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o processo esteve no estado IDLE.<\/p>\n<p><b>%SWPWT<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o vCPU esperou por uma opera\u00e7\u00e3o com o VMkernel Swap.<\/p>\n<p><b>%VMWAIT<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o vCPU esteve no estado de espera por um evento (normalmente entrada\/sa\u00edda). N\u00e3o h\u00e1 um contador correspondente no vCenter. Valores altos indicam problemas de entrada\/sa\u00edda na VM.<\/p>\n<p>%WAIT = %VMWAIT + %IDLE + %SWPWT.<\/p>\n<p>Se a VM n\u00e3o utiliza o VMkernel Swap, ao analisar problemas de desempenho, \u00e9 aconselh\u00e1vel observar o %VMWAIT, pois essa m\u00e9trica n\u00e3o considera o tempo em que a VM n\u00e3o estava fazendo nada (%IDLE).<\/p>\n<p><b>%RDY<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o processo esteve no estado Ready.<\/p>\n<p><b>%CSTP<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o processo esteve no estado costop.<\/p>\n<p><b>%MLMTD<\/b> \u2013 quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o vCPU esteve no estado Ready devido a um limite de recursos estabelecido.<\/p>\n<p>%WAIT + %RDY + %CSTP + %RUN = 100% \u2013 o n\u00facleo da VM est\u00e1 sempre em um desses quatro estados.<\/p>\n<h3>CPU no hipervisor<\/h3>\n<p>\nNo vCenter, tamb\u00e9m existem contadores de desempenho de CPU para o hipervisor, mas eles n\u00e3o representam nada interessante \u2013 s\u00e3o apenas a soma dos contadores de todas as VMs no servidor.<br \/>\n\u00c9 mais conveniente observar o estado da CPU no servidor na aba Resumo:<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/15b6b9a6da136d892fbaf7f80fc206c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara o servidor, assim como para a m\u00e1quina virtual, existe um Alarm padr\u00e3o:<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/c3ae19ce3acd55cfff40d71437ee3a08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSob alta carga na CPU do servidor, as VMs que nele operam come\u00e7am a ter problemas de desempenho.<\/p>\n<p>No ESXTOP, os dados de carga da CPU do servidor s\u00e3o apresentados na parte superior da tela. Al\u00e9m da carga padr\u00e3o da CPU, que \u00e9 pouco informativa para hipervisores, existem mais tr\u00eas m\u00e9tricas:<\/p>\n<p><b>UTILIZA\u00c7\u00c3O DO CORE(%)<\/b> \u2013 carga do n\u00facleo do servidor f\u00edsico. Este contador mostra quanto tempo, durante o per\u00edodo de medi\u00e7\u00e3o, o n\u00facleo esteve executando trabalho.<\/p>\n<p><b>UTILIZA\u00c7\u00c3O DO PCPU(%)<\/b> \u2013 se o hyper-threading estiver ativado, cada n\u00facleo f\u00edsico ter\u00e1 dois threads (PCPU). Esta m\u00e9trica mostra quanto tempo cada thread esteve executando trabalho.<\/p>\n<p><b>PCPU UTILIZADO(%)<\/b> \u2013 o mesmo que PCPU UTIL(%), mas considera o frequency scaling (ou seja, a redu\u00e7\u00e3o da frequ\u00eancia do n\u00facleo para economia de energia, ou o aumento da frequ\u00eancia do n\u00facleo atrav\u00e9s da tecnologia Turbo Boost) e o hyper-threading.<\/p>\n<p>PCPU_USED% = PCPU_UTIL% * frequ\u00eancia efetiva do n\u00facleo \/ frequ\u00eancia nominal do n\u00facleo.<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/dd8562ea91bee55bbf630358df26c217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Nesta captura de tela, para alguns n\u00facleos, devido ao trabalho do Turbo Boost, o valor USED \u00e9 superior a 100%, j\u00e1 que a frequ\u00eancia do n\u00facleo est\u00e1 acima da nominal.<\/i><\/p>\n<p>Algumas palavras sobre como o hyper-threading \u00e9 considerado. Se os processos s\u00e3o executados 100% do tempo em ambos os threads do n\u00facleo f\u00edsico do servidor, e o n\u00facleo opera na frequ\u00eancia nominal, ent\u00e3o:<\/p>\n<ul>\n<li>A UTILIZA\u00c7\u00c3O DO CORE para o n\u00facleo ser\u00e1 de 100%,<\/li>\n<li>A UTILIZA\u00c7\u00c3O DO PCPU para ambos os threads ser\u00e1 de 100%,<\/li>\n<li>O PCPU UTILIZADO para ambos os threads ser\u00e1 de 50%.<\/li>\n<\/ul>\n<p>\nSe ambos os threads n\u00e3o estiverem ativos 100% do tempo durante o per\u00edodo de medi\u00e7\u00e3o, ent\u00e3o, nos per\u00edodos em que os threads trabalharam paralelamente, o PCPU UTILIZADO para os n\u00facleos \u00e9 dividido por dois.<\/p>\n<p>No ESXTOP tamb\u00e9m h\u00e1 uma tela com os par\u00e2metros de consumo de energia da CPU do servidor. Aqui \u00e9 poss\u00edvel verificar se o servidor est\u00e1 utilizando tecnologias de economia de energia: C-states e P-states. \u00c9 acionado pela tecla 'p':<\/p>\n<p><img decoding=\"async\" alt=\"An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU\" src=\"\/wp-content\/uploads\/2019\/05\/531bf847b99f86bec0bd90e005919c79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Problemas padr\u00e3o de desempenho da CPU<\/h3>\n<p>\nPor fim, vou passar por causas t\u00edpicas de problemas de desempenho da CPU da VM e dar dicas breves para resolv\u00ea-los:<\/p>\n<p><b>Falta de frequ\u00eancia do n\u00facleo.<\/b> Se n\u00e3o houver como mover a VM para n\u00facleos mais potentes, experimente mudar as configura\u00e7\u00f5es de energia para que o Turbo Boost funcione de forma mais eficaz.<\/p>\n<p><b>Dimensionamento incorreto da VM (muitos\/poucos n\u00facleos).<\/b> Se houver poucos n\u00facleos, a carga da CPU da VM ser\u00e1 alta. Se houver muitos, voc\u00ea ter\u00e1 um co-stop alto.<\/p>\n<p><b>Grande sobrecarga de CPU no servidor.<\/b> Se a VM tiver um valor alto de Ready, reduza a sobrecarga de CPU.<\/p>\n<p><b>Topologia NUMA incorreta em grandes VMs.<\/b> A topologia NUMA que a VM (vNUMA) v\u00ea deve corresponder \u00e0 topologia NUMA do servidor (pNUMA). Sobre o diagn\u00f3stico e poss\u00edveis solu\u00e7\u00f5es para esse problema, escrito, por exemplo, no livro <noindex><a rel=\"nofollow\" href=\"https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html\">\u00abVMware vSphere 6.5 Host Resources Deep Dive\u00bb<\/a><\/noindex>. Se voc\u00ea n\u00e3o quiser se aprofundar e n\u00e3o tiver restri\u00e7\u00f5es de licen\u00e7a para o SO instalado na VM, fa\u00e7a v\u00e1rias soquetes virtuais na VM com um n\u00facleo cada. Voc\u00ea n\u00e3o vai perder muito \ud83d\ude42<\/p>\n<p>\u00c9 isso sobre CPU por enquanto. Fa\u00e7a suas perguntas. Na pr\u00f3xima parte, irei falar sobre mem\u00f3ria RAM.<\/p>\n<p><b class=\"spoiler_title\">Links \u00dateis<\/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 \/>Fonte: <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.3 - 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\/pt\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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\udd47An\u00e1lise de desempenho da m\u00e1quina virtual no VMware vSphere. Parte 1: CPU | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/34335","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=34335"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34335\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/25892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=34335"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=34335"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=34335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}