Como [educadamente?] Dizer ao fornecedor de software que eles não sabem do que estão falando


62

Não é uma questão técnica, mas válida, no entanto. Cenário:

HP ProLiant DL380 Gen 8 com 2 CPUs Xeon E5-2667 de 8 núcleos e 256 GB de RAM executando o ESXi 5.5. Oito VMs para o sistema de um determinado fornecedor. Quatro VMs para teste, quatro VMs para produção. Os quatro servidores em cada ambiente desempenham funções diferentes, por exemplo: servidor web, servidor de aplicativos principal, servidor OLAP DB e servidor SQL DB.

Compartilhamentos de CPU configurados para impedir que o ambiente de teste afete a produção. Todo o armazenamento na SAN.

Tivemos algumas perguntas sobre desempenho e o fornecedor insiste que precisamos fornecer ao sistema de produção mais memória e vCPUs. No entanto, podemos ver claramente no vCenter que as alocações existentes não estão sendo atingidas, por exemplo: uma visualização mensal da utilização da CPU no servidor de aplicativos principal fica em torno de 8%, com um aumento ímpar de até 30%. Os picos tendem a coincidir com o início do software de backup.

História semelhante sobre a RAM - o número mais alto de utilização entre os servidores é de ~ 35%.

Portanto, estamos pesquisando, usando o Process Monitor (Microsoft SysInternals) e o Wireshark, e nossa recomendação ao fornecedor é que eles façam algum ajuste de TNS na primeira instância. No entanto, isso está além do ponto.

Minha pergunta é: como podemos fazê-los reconhecer que as estatísticas da VMware que enviamos são evidências suficientes para que mais RAM / vCPU não ajude?

--- ATUALIZAÇÃO 12/07/2014 ---

Semana interessante. Nosso gerenciamento de TI disse que devemos fazer a alteração nas alocações da VM e agora estamos aguardando algum tempo de inatividade dos usuários corporativos. Estranhamente, são os usuários de negócios que afirmam que certos aspectos do aplicativo estão rodando lentamente (em comparação com o que eu não sei), mas eles vão "nos avisar" quando podemos derrubar o sistema (resmungar , resmungar!).

Como um aparte, o aspecto "lento" do sistema aparentemente não é o elemento HTTP (S), ou seja: o "aplicativo thin" usado pela maioria dos usuários. Parece que as instalações do "cliente gordo", usadas pelos principais órgãos financeiros, são aparentemente "lentas". Isso significa que agora estamos considerando a interação cliente e servidor em nossas investigações.

Como o objetivo inicial da pergunta era procurar ajuda para seguir a rota "cutucar", ou apenas fazer a alteração, e agora estamos fazendo a alteração, eu a fecharei usando a resposta do longneck .

Obrigado a todos por sua contribuição; como sempre, serverfault tem sido mais do que apenas um fórum - é como o sofá de um psicólogo :-)



5
Esse continua sendo o meu LART preferido: laughingsquid.com/cat-5-o-nine-tails-ethernet-cable-whip É para diagnóstico de rede. Honesto.
Sobrique

17
Por interesse, você verificou o desempenho do armazenamento? Pedir mais CPU / RAM pode ser apenas uma resposta leiga ao desempenho ruim, que pode ser facilmente causado pela alta profundidade da fila de disco. Parece que um monte de gente se esqueceu de armazenamento SQL melhores práticas quando a virtualização entrou.
Ashigore

7
resmungar . É isso mesmo, culpe o armazenamento! Mas mais a sério - é um bom ponto. Se houver um problema e a RAM / CPU não estiver ajudando, pode ser IO. Especialmente se estivermos falando do VMWare, porque não é incomum para ... bem, o lado do desempenho do armazenamento de um sistema ser quase totalmente ignorado - ao mesmo tempo em que esquece que você intrinsecamente obtém um gargalo maciço se alimenta muitas VMs em um espaço limitado. número de HBAs.
Sobrique

6
A HP é seu fornecedor neste caso? Porque eu trabalho lá. Posso confirmar que não nos importamos.
Christopher Wirt

Respostas:


94

Sugiro que você faça os ajustes solicitados. Em seguida, avalie o desempenho para mostrar a eles que não fez diferença. Você pode ir tão longe para compará-lo com menos memória e vCPU para fazer o seu ponto.

Além disso, "estamos pagando para oferecer suporte ao software com soluções reais, e não suposições".


10
...palavras sábias. Acho que esse pode ser o caminho a seguir, por mais que nos doa fazer a mudança. O bom (?) É que as alterações exigirão uma reinicialização e podemos esclarecer aos usuários comerciais que isso se deve à solicitação do fornecedor ... o que quase certamente será inútil. Parece que estou ficando mesquinho, mas estamos ficando cansados ​​da aparente falta de solução de problemas adequada do fornecedor.
Simon Catlin

6
Não é incomum que os vendedores joguem esse tipo de acrobacia. Eu acho que isso se deve em parte às métricas de nível de serviço - adquira, solicite mais informações e sugira uma solução alternativa (sem sentido), porque pelo menos uma parte do tempo, o problema desaparece / é corrigido nesse meio tempo. Se você "puxou" o fornecedor, conversar com o gerente da conta pode ajudar. Mas não prenda a respiração.
Sobrique

11
Teve uma situação semelhante uma vez com um servidor SQL para SCCM (system center config mgr) 4 CPU 30% util avg. Console terrivelmente lento. Colidido com 8 CPU ainda 30% util, o console finalmente responde de maneira normal.
Clayton

2
Excelente sugestão. Não há nada como dados para calar as pessoas. "Faremos a mudança que você sugerir. Se não der a melhoria projetada, você reduzirá o custo". Não sei quantos sistemas são afetados aqui, mas seu tempo para provar que estão errados RAPIDAMENTE se torna mais caro do que conectar uma RAM extra.
Floris

67

Desde que você tenha certeza de que está dentro das especificações de sistema fornecidas por eles.

Então, qualquer reclamação que eles estejam fazendo sobre exigir mais RAM ou CPU que eles devem poder fazer backup. Como especialistas em seu sistema, convido as pessoas a prestar contas disso.

Pergunte-lhes detalhes.

  • Quais informações fornecidas no sistema indicam que mais RAM é necessária e como você interpretou isso?

  • Quais informações fornecidas no sistema indicam que mais CPU é necessária e como você interpretou isso?

  • Os dados que tenho - à primeira vista - contradiz o que você está me dizendo. Você pode me explicar por que posso estar interpretando isso incorretamente?

  • Estou interpretando essa [série óbvia de dados] como significando [interpretação óbvia]. Você pode confirmar que estou interpretando corretamente no que diz respeito ao meu problema?

Tendo lidado com apoio no passado, fiz as mesmas perguntas. Às vezes eu estava certo e eles não estavam concentrando sua atenção no meu problema corretamente. Outras vezes, no entanto, eu estava errado e estava interpretando os dados incorretamente ou deixando de incluir outros dados que eram importantes em minha análise.

De qualquer forma, essas duas situações foram um benefício líquido para mim, ou aprendi algo novo que não conhecia antes - ou solicitei às equipes de suporte que pensassem mais sobre o meu problema para obter uma causa raiz decente.

Se a equipe de suporte não conseguir fornecer uma expansão lógica de seus argumentos para uma base com a qual você esteja satisfeito (você precisa ter uma mente aberta para se comprometer, seja razoável aceitar que sua interpretação dos dados está errada), deve tornar-se muito presente em sua resposta. Mesmo no pior cenário, você pode usar isso como base para escalar o problema.


10
+1 pelo reconhecimento de que o erro humano pode ser de duas maneiras (e fazendo com que o suporte se contorça um pouco quando eles realmente tentam "adormecer").
Cosmic ossifrage

17

O importante é provar que você está usando as práticas recomendadas para a alocação do sistema, principalmente reservas de RAM e CPU para o servidor SQL.

Tudo isso dito, a coisa mais fácil é fazer os ajustes solicitados, pelo menos temporariamente. Se nada mais, isso tende a levar os fornecedores a arrastar os pés. Não posso contar o número de vezes que precisei fazer algo louco como esse para satisfazer uma tecnologia do outro lado da linha que realmente é o software deles não se comportando.


17

Para essa situação específica (em que você tem desenvolvedores de VMware e aplicativos ou terceiros que não entendem a alocação de recursos), utilizo as métricas de uma semana obtidas no vCenter Operations Manager (vCops - faça o download de uma demonstração, se necessário ) para identificar as reais restrições. , gargalos e requisitos de dimensionamento das VMs do aplicativo.

Às vezes, consegui satisfazer os consumidores mais obstinados modificando as reservas da VM ou alterando as prioridades para lidar com cenários de contenção; " Se a RAM | CPU estiver restrita, SUA VM terá precedência! ". Coisas ruins e ruins aconteceram quando permiti que os fornecedores de software determinassem seus requisitos nos meus clusters do vSphere sem análise real .

Mas, em geral, números e dados devem vencer.


Um exemplo de algo que eu usei para justificar o dimensionamento da VM para o desenvolvedor de um aplicativo Tomcat:

Dev : A VM precisa de CPU MOAR!

Eu : Bem, a memória é a sua maior restrição, e aqui está um mapa de desempenho do seu desempenho versus o tempo ... As quartas-feiras às 18h são os períodos mais estressantes, para que possamos especificar esse período de pico. Ah, e aqui está uma recomendação de tamanho com base nas últimas 6 semanas de métricas de produção ...

insira a descrição da imagem aqui

insira a descrição da imagem aqui

insira a descrição da imagem aqui


9
Devo acrescentar que a análise baseada em médias pode levar a resultados errados. Há condições em que o desempenho máximo é importante, mas você não vê os picos nas estatísticas de carga quando são significativamente mais curtos que o intervalo de coleta / média. Portanto, você pode ter um bom gráfico colorido de estatísticas "sua utilização geral é <60%", mas pode observar uma grave degradação do desempenho em picos de 1 minuto, ocorrendo 8 vezes por hora ao mesmo tempo.
the-wabbit

Talvez eu tenha interpretado mal completamente a pergunta, mas não é o oposto do que o OP perguntou? Eu pensei que eles eram os desenvolvedores, que sabiam que não precisavam de mais CPU, que o fornecedor estava tentando vendê-los - parece que você descreve o inverso, onde um desenvolvedor está pedindo mais CPUs que eles não precisam.
Benubird

11
Estou usando um exemplo conveniente. Eu adoto a mesma abordagem com fornecedores que possuem requisitos rígidos (4 vCPU e 16 GB de RAM), além de identificar sistemas de tamanho menor que precisam de recursos. Em termos de monitoramento da granularidade, você pode voltar às estatísticas no nível do host para lidar com picos ...
ewwhite

Obrigado por isso. Não temos vCops, mas acho que nossa "propriedade" do vSphere agora está madura o suficiente para exigir esse nível de detalhe. Vou adicionar isso à nossa lista de desejos de Capex para o próximo ano.
Simon Catlin

2
@SimonCatlin você não precisa comprá-lo. Você pode baixar a demo gratuitamente e usá-la por 60 dias. É perfeito para esse tipo de situação.
ewwhite

10

Eu costumava trabalhar no suporte - e parte do que você está perguntando parece altamente racional (e provavelmente é): mas há algumas perguntas a serem feitas antes de fazer o "aprimoramento de desempenho" que eles estão solicitando

  • você já está executando pelo menos os requisitos mínimos de sistema estabelecidos pelo fornecedor?
  • se você possui pelo menos sysreqs mínimos, já possui as configurações de sistema "recomendadas"?

Os fornecedores 99 vezes em 100 (na minha experiência - tanto do lado do suporte quanto do cliente / campo) nem sequer lidam com problemas relacionados ao desempenho até / a menos que os sistemas correspondam ao que a documentação exige. Talvez seja um sistema que funcione bem 99,5% do tempo com 1 CPU e 512M RAM - mas se os requisitos do sistema indicarem 4 CPUs e 4G RAM e você tiver apenas 2 CPUs e 1G RAM, eles estão dentro dos seus direitos de exige que mais recursos sejam atribuídos * .

É provável que eles estejam pedindo que você aumente os recursos do sistema por causa de algo que encontraram no laboratório / desenvolvimento em que um problema desaparece magicamente se você ultrapassar um limite específico; se for esse o caso, sim, é um exemplo de depuração potencialmente ruim no final, mas lembre-se de que eles não têm tempo para eliminar todos os possíveis problemas / problemas que possam surgir - alguns apenas precisam ser contornados e, se necessário, esse é o caso aqui, apenas vá em frente.

Há também uma chance não insignificante de que os problemas que você está vendo nem fazem parte do software "deles", mas um componente em que eles confiam em alguma outra fonte (fornecedor, biblioteca OSS, etc.). Eu me deparei com essa situação exata relacionada ao tamanho da troca, BEA WebLogic e Sun JRE em um cliente há alguns anos atrás.

tl; dr:

Em resumo, trabalhe com a equipe de suporte, escalando conforme necessário, até encontrar uma solução - mas não se surpreenda quando algumas das sugestões / etapas de depuração / correções parecerem inoportunas ou inúteis.


* Se realmente não "precisar" desses recursos extras, é provável que você possa registrar um erro de documento / RFE para versões futuras - mas não siga esse caminho até demonstrar que não é o problema em questão
^ um e-book que escrevi, pode ser útil para você no tópico: Depurando e suportando sistemas de software


2
Qualquer coisa relacionada ao desempenho leva muito tempo e recursos para solucionar problemas e diagnosticar. Afinal, não há nada quebrado, então você precisa rastrear dolorosamente.
Sobrique

11
@Sobrique absolutamente - e eles são geralmente em muito remotamente relacionadas (mesmo aparentemente não relacionada) segmentos do produto na mão
Warren

Esse é um bom ponto, muitas etapas de depuração podem ser muito contra-intuitivas, embora eu não ache irracional insistir que elas forneçam um motivo para isso. Se eles não podem dizer que benefício fazer algo trará (mesmo que seja apenas "ver se isso afeta X"), então eles estão trabalhando em uma lista de verificação que eles não entendem ou não têm idéia e estão fazendo palpites malucos, ou estão escondendo algo - nada disso é muito encorajador.
21714 Benubird

@Benubird - infelizmente algumas dessas coisas se resumem ao instinto ou "consertou-o em outro lugar ..." :(
warren

2
"consertou em outro lugar" é uma terrível razão para fazer alguma coisa. É verdade que, às vezes, não há tempo para depurar corretamente um problema, e você precisa seguir por instinto, mas o pensamento ainda me faz estremecer. Eu já vi muitos bugs que "pareciam" ser corrigidos com o X, apenas para descobrir mais tarde que o problema estava realmente em algo aparentemente totalmente não relacionado, que passou a causar mais problemas em outros lugares até descobrirmos.
Benubird 9/07/14

8

Peça para escalar o ticket ou peça um representante diferente. Dependendo do fornecedor, sua escalação pode ajudar se você disser que acha que o nível atual de suporte não resolve adequadamente o problema. Se eles não aumentarem, pedir um representante diferente pode ajudar, pois isso requer muito menos "justificativa", pois tudo o que precisa é não ser feliz com a atual.

Se for um fornecedor grande, simplesmente fechar o ticket e abrir um novo no mesmo problema pode funcionar, pois pode ser roteado para um representante diferente, mas eu aconselho isso porque é uma forma ruim.

Você também pode defender sua posição e pedir uma justificativa para o quanto mais RAM / vCPU ajudará, ou você pode simplesmente fornecer mais RAM / vCPU para provar que não ajudará.


4

Vou jogar meus dois centavos. Temos sido bem-sucedidos com essa abordagem - resultados muito melhores e menos frustração por parte de todos. Requer muito mais esforço do que o jogo da culpa e a adição cega de recursos, mas também tem melhores chances de encontrar o problema subjacente.

Quando temos sérios problemas com nossos aplicativos locais, que são apoiados por contratos de suporte de fornecedores, e os fornecedores começam sua dança esquiva de embaralhamento (que sempre parece incluir demandas estranhas e não orientadas por dados por mais CPU ou RAM), tendemos a faça estas 3 coisas:

  1. Escale a prioridade para o equivalente ao sistema inativo - eles geralmente se recusam, mas geralmente recuam quando você explica que é efetivamente inutilizável, mesmo que tecnicamente esteja "funcionando". Trate-o como um problema sério para eles resolverem. Por aqui, nos referimos a isso como uma equipe de tigres, que se reúne diariamente para obter atualizações de status de todas as partes interessadas. Normalmente, o fornecedor solicita que você troque as coisas. Se for um sistema de prod, isso é problemático, mas se você quiser que eles ajudem, será necessário aceitar a responsabilidade de ajudá-los a isolar o problema, por isso ajuda se você tiver um ambiente de desenvolvimento / teste em que possa executar testes.

  2. Diga ao fornecedor que você deseja que ele replique seu ambiente, para que eles possam isolar o problema em seu laboratório. Eles podem até hospedar coisas em algum ambiente de nuvem, se necessário. Não precisa ser uma correspondência exata do seu ambiente, embora isso seja ideal. O ponto é que você deseja que o FORNECEDOR esteja tentando replicar seu problema ativamente, para que eles possam testar suas suposições no sistema em vez do seu. Peça-lhes os diagramas, especificações, etc. desse ambiente replicado para garantir que eles estejam fazendo isso.

  3. Forneça a eles (sob a NDA, é claro) seu conjunto de dados real para que eles possam executá-lo / reproduzi-lo de verdade, em vez de adivinhar. No nosso caso, a maioria dos problemas de aplicativos fornecidos pelo fornecedor (tanto transitórios quanto crônicos) freqüentemente se tornam problemas com os bancos de dados fornecidos pelo fornecedor. Não posso contar o número de vezes que fizemos isso e eles finalmente identificaram o problema em algo inesperado nos dados reais - artefatos estranhos de atualizações de aplicativos há dois anos em que algo não se converteu corretamente; registros antigos que expõem um problema com as configurações do GC; as consultas não estão funcionando corretamente porque nossos valores de dados quebram alguma rotina de transmissão no código do fornecedor etc. Coisas que nunca poderíamos identificar por conta própria.

Fizemos isso com alguns fornecedores nos últimos anos, e eles são inicialmente muito resistentes a fazê-lo do nosso jeito. No entanto, depois que funciona, sempre aparece como um destaque positivo nas revisões trimestrais que mantemos com nossos fornecedores. E isso ajuda a consolidar nosso relacionamento técnico com esses fornecedores. Eles não querem problemas vagos. Eles querem problemas específicos que possam analisar para melhorar seus produtos.

Espero que a sugestão ajude. Sei que não é uma abordagem única, mas se você puder usá-la, acho que vai valer a pena.


3

A verdadeira questão é: quem está no comando aqui? Se você não pode mudar realisticamente para um fornecedor alternativo, eles têm o poder, e tudo o que você pode fazer é seguir o que eles dizem e esperar que dê certo. Não é uma situação feliz! Caso contrário, sugiro que você solicite outro representante (como outros já disseram), mas deixe claro que não está satisfeito com o serviço e procurará em outro lugar se não puderem fazer o trabalho.

Não apenas "faça os ajustes sugeridos" se tiver certeza de que eles não funcionarão, pois isso está estabelecendo um padrão para o seu relacionamento que o machucará a longo prazo. Você está pagando a eles para lhe prestar um serviço, e eles não devem poder ditar suas ações, assim como alguém que eu contratei para pintar minha casa pode ditar qual será a cor.

Isso pode parecer drástico, pois parece que essa não é uma questão extremamente crítica, mas o fato é que, se eles estão brincando com algo menor, provavelmente farão o mesmo por algo grande, e a última coisa que você deseja é encontre algum tipo de horrível charlie foxtrot seis meses depois e tenha o mesmo problema com o fornecedor.

Certifique-se de que as medidas que você tomar para resolver o problema agora funcionem igualmente bem quando você estiver dois dias após o prazo e tudo quebrar ...


4
Eu teria pensado que isso daria munição em contra-argumento - você nos pediu para fazer essa coisa sem sentido da última vez; fizemos como um gesto de boa vontade. Desta vez, queremos mais detalhes sobre o seu raciocínio sobre por que isso fará alguma diferença.
Sobrique

@Sobrique Isso faz sentido, e pode funcionar dessa maneira - não conheço psicologia suficiente para dizer de uma maneira ou de outra. Meu instinto, porém, é que, se você fez algo agora apenas porque eles disseram - admitindo efetivamente que sabem mais do que você -, eles esperam o mesmo no futuro. De qualquer maneira, se você tiver que discutir com eles (munição ou não), já estará perdendo tempo que poderia ser gasto resolvendo o problema.
Benubird

"Fizemos do seu jeito da última vez. Você estava errado. Você está preparado para aceitar que pode estar errado de novo? Temos precedentes aqui."
Sobrique

3

Vou postar uma exibição do lado do fornecedor.

Tínhamos um cliente com esse problema recorrente, em que o desempenho do software diminuía a cada poucas horas, aproximadamente, para uma taxa realmente abismal, e voltava algumas horas depois.

O perfilador de bulitina no sistema indicava que a velocidade da CPU do sistema (ou possivelmente memória) era repugnantemente lenta, algo como 100MHZ em vez dos 2GHZ esperados. Dobrar a CPU fornecida pela VM não mudou o sintoma e eles pensaram que estávamos sendo um desperdício.

Como eles não podiam obter uma CPU mais rápida (mais CPUs não ajudariam), tentamos trocar as VMs TEST e PROD. O problema apareceu no teste no dia seguinte. Em seguida, tentamos promover um dos clientes para uma instância autônoma (sem servidor). Não há problema nessa estação de trabalho enquanto o servidor estava bloqueado.

Eles produziram relatórios do host da VM, indicando que não havia problemas de desempenho, e tentaram novamente afirmar que era um problema de aplicativo.

Finalmente, eu [um engenheiro] (eu não tinha suporte daqueles em funções de suporte dedicadas) solicitei especificamente uma caixa física. O cliente gritou assassinato sangrento, mas como ninguém tinha outra solução em potencial, eles o fizeram. O que você sabe, o problema desapareceu magicamente.

Nunca descobrimos qual era o problema. Todos os programas de benchmark mostraram-se normais, mas o criador de perfil de aplicativos estava nos dizendo que os recursos de computação simplesmente não eram adequados. Existe um tipo de assinatura específica que procuramos no criador de perfil agora. Se o virmos, sabemos que, antes de avançarmos mais, o problema é a interação com a VM, mas na época não era conhecido.

Eles com certeza pensaram que eu estava cheio disso. Eu não estava. Eu estava sem opções.

EDIT, atualização de anos depois:

Com mais e mais clientes querendo rodar em VMs e gerenciamento dispostos a tentar resolver o problema a todo custo, obtivemos um bom hardware de VM. Consegui construir um programa especializado de gravação de VMs que rodava no espaço do usuário (e não exigia privilégios) em duas VMs de núcleo único com 512mb de RAM, capaz de drenar o desempenho da memória 1/3 de outra VM de núcleo único com apenas 4 total de núcleos de 16 em uso no host da VM e a maior parte de sua ram ainda está livre. O programa não emitiu alarmes e não mostrou nada fora do comum no host da VM nem em nenhum dos convidados, exceto pelo acesso à memória que era lento.

Agora podemos dizer aos clientes que sabemos que há um problema com as VMs e esse não é o nosso software. Ainda recebemos solicitações de clientes de tempos em tempos para software compatível com VM. Eu me pergunto por que o gerenciamento não deixa o suporte dizer que conseguimos desenvolver um software que reduz a velocidade de todas as outras VMs no mesmo host.

O mais assustador é que a técnica envolvida é uma simples transformação da técnica de programação conhecida que envolve sincronização sem bloqueio. Centenas de fornecedores de software poderiam ter esse escorredor de VM em seu software e não o conhecer. Conseguir um bloqueio de instruções atômicas que contestava calorosamente deve ser raro, mas não impossível. A parte divertida de tudo isso é que eu estava conseguindo o bloqueio para contestar as VMs do ACROSS.


-3

Eu sugeriria uma abordagem muito diferente das mencionadas até agora. Antes de discutir com o fornecedor, por que não olhar mais de perto o problema relatado e ver o que isso lhe diz?

Quais são os problemas reais relatados e quais são as expectativas dos usuários. Se um usuário estiver dizendo algo "demore muito", pergunte a ele exatamente o que é (para que você possa reproduzi-lo), quanto tempo eles acham que deve levar e por que eles acham que deve demorar tanto. Se suas expectativas forem razoáveis, meça o desempenho real e o impacto no sistema do que eles estão tentando fazer. O fato de seu sistema apresentar um pico de 30% ao longo de um mês não significa que ele não esteja funcionando a> 100% quando o usuário estiver tentando sua consulta. Se você puder demonstrar ao seu fornecedor que a CPU e a memória não estão sendo sobrecarregadas pela tarefa problemática, peça ao fornecedor que justifique as recomendações que lhe custarão dinheiro.


11
A primeira metade da sua sugestão parece já ter sido feita. Toda a segunda metade é exatamente o que o OP está pedindo.
Chris S

Eu discordo. Não há evidência apresentada de análise de problemas e os números de CPU e MEM citados são agregações mensais que não têm aparente relevância para o problema em questão.
Paul Smith
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.