Cache louco de agentes de teste
Boa tarde a todos!
Deparei-me com o seguinte problema:
Ter 32 processadores lógicos no sistema - usando 32 agentes para otimização respectivamente (+ outros 40 remotos)
Cada agente constrói rapidamente um cache de tamanho completamente inadequado de 2-2,6GB, o que no total totaliza mais de 70GB em um dia! O cache em si não é apagado, e está em constante crescimento. A única coisa que impediu a loucura foi o esgotamento do espaço em disco. Depois disso, os agentes, estupidamente, param de trabalhar.
As perguntas são as seguintes:
Alguém já se deparou com tal problema? Como lidar com isso? O que pode estar causando tais tamanhos de cache?
Escreveu um pedido para Servicedesk, até agora silêncio.
O tamanho do cache depende do número de carrapatos gerados (ou seja, quanto maior o período de teste e o número de caracteres, maior o cache).
No seu caso, provavelmente o principal problema é o número de agentes, porque agora (construa 1495) cada agente usa sua própria instância de cache!
O espaço de cache é liberado após 5 minutos de inatividade do agente.
Além disso, o histórico do carrapato dos agentes no testador pode ocupar espaço, se os agentes forem usados na nuvem (o histórico do carrapato é eventualmente limpo, também, mas passa por dias ou semanas).
A propósito, os agentes das nuvens e os agentes locais são diferentes. Na foto os agentes de nuvem no mesmo computador são adicionados à fazenda da rede local - Voilà! Temos 8 agentes de teste em um processador com dois núcleos e quatro processadores lógicos (se vale a pena fazer isso é outra questão).
В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!
O testador não tem nenhuma configuração, portanto é impossível otimizá-lo para o seu sistema. Na saída obtemos abuso de disco rígido com um grande número de pequenos arquivos reescritos (até 800GB/dia em SSD 120GB a 32 agentes no sistema), e o que é engraçado, os núcleos no momento estão ociosos.
Resolveu parcialmente o problema executando 4 diferentes testadores em modo portátil em diferentes acionamentos físicos. Incluindo RAM-diske, já que o testador deixa uma grande quantidade de memória sem supervisão.
A propósito, rodar um agente com cache em um disco de carneiro, muitas vezes aumenta o desempenho em até 3 vezes! O que mais uma vez aponta para a forma nojenta como o provador está organizado.
A propósito, os agentes das nuvens e os agentes locais são diferentes. Na foto os agentes de nuvem no mesmo computador são adicionados à fazenda da rede local - Voilà! Temos 8 agentes de teste em uma CPU com dois núcleos e quatro processadores lógicos (se você deve fazer isso é outra pergunta).
Esta é a estupidez (perdoem-me os desenvolvedores) da organização de testes, onde o número de agentes é transformado de uma vantagem em um problema.
O testador não tem nenhuma configuração, portanto é impossível otimizá-lo para o seu sistema. Na saída obtemos abuso do disco rígido com um grande número de pequenos arquivos sobrescritos (até 800GB/dia em SSD 120GB a 32 agentes no sistema), e o que é engraçado, os núcleos permanecem ociosos durante este tempo.
...
A propósito, a execução de um agente com um cache em um frame-disk, muitas vezes aumenta o desempenho em até 3 vezes! O que mais uma vez aponta para a forma nojenta como o provador está organizado.
...
Escreva para o Service Desk.
Ter que ler vários gigabytes de dados de uma unidade é "organização nojenta"? Mesmo apenas a leitura de 1gb de dados de um ssd a uma velocidade média de 200mbps levará 5 segundos. E se houver 4-32 agentes lá fora?
Você só pensa no lado técnico da tarefa. Nada é grátis e ninguém multiplica as exigências técnicas por zero.
A solução técnica e o nível de otimização dos agentes é surpreendente - colocamos uma quantidade enorme de trabalho e riscamos milissegundos de todos os processos. Não se esqueça dos volumes de dados, coloque mais RAM, coloque ssd's maiores, coloque discos de moldura e tudo será acelerado.
Os preços de todas essas coisas já são razoáveis, mas a classe e o volume a ser resolvido requerem uma abordagem séria.
Cada agente está construindo rapidamente um cache de tamanho completamente inadequado, 2-2,6GB, totalizando mais de 70GB em um dia! O cache não se apaga sozinho, e está em constante crescimento. A única coisa que impediu esta loucura foi o esgotamento do espaço em disco. Depois disso, os agentes, estupidamente, param de trabalhar.
O que há para armazenar em tais volumes?!
Tudo está bem com os caches de dados. Nós o mantemos em disco e o guardamos na memória à espera de novas execuções. Por favor, observe como o recálculo é mais rápido no mesmo agente (leve um agente e uma corrida para demonstrar o efeito).
Mais uma coisa - trabalhamos muito parcimoniosamente com os discos. Escrevemos em grandes múltiplos e entendemos claramente as peculiaridades dos discos ssd.
Os comerciantes geralmente preferem verificar o tamanho da pasta sem notar que existem cerca de 10 Gbytes de logs grandes, gerados pessoalmente.
Resolveu parcialmente o problema executando 4 diferentes testadores em modo portátil em diferentes discos físicos. Incluindo RAM-diske, uma vez que o testador deixa uma grande quantidade de memória sem supervisão.
A propósito, rodar um agente com cache em um disco de carneiro, muitas vezes aumenta o desempenho em até 3 vezes! O que mais uma vez aponta para a organização nojenta do provador.
Qual a razão para a organização do disco RAM aumentar o desempenho muitas vezes, se o nível de otimização dos agentes é "maravilhoso"? Na minha opinião, perguntas lógicas, embora desagradáveis.
ZS Precisamos obter algum software que apague os logs dos agentes. Eles são inúteis em tais quantidades. O Print+Alert deve ser desativado pelo usuário no código durante as otimizações.
fxsaber:
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?
Em vez de fazer declarações no fórum, dê uma olhada por si mesmo.
Qual é a razão para organizar o RAMdisk para multiplicar o desempenho se o nível de otimização do agente é "incrível"? Na minha opinião, perguntas lógicas, embora desagradáveis.
Porque não temos o direito de comer 100% da memória RAM para o cache e mantê-la indefinidamente. Mas se uma pessoa criou ela mesma uma estrutura de disco de 32-64gb, moveu agentes para lá e começou a trabalhar ativamente com o disco, então sim, é possível obter a velocidade das operações do disco muitas vezes.
Mas especificamente operações em disco, não "todas ao mesmo tempo por um fator de N".
Que o testador trata os dados de forma surpreendente é evidente para qualquer um que os usa em modo constante e obtém muitos benefícios de caches de testadores aquecidos, esperando por novas corridas em segundo plano. A experimentação é geralmente dezenas ou centenas de testes com recompilação constante do código.
HH Precisamos de algum tipo de software para apagar os logs do agente. Não precisamos deles em quantidades tão grandes. E Print+Alert deve ser desativado pelo usuário no código durante as otimizações.
Os logs do testador são apagados automaticamente. Aqueles que usam o testador sabem disso. E as caches do testador são limpas pelo terminal assim que ele entende que o testador não é mais usado.
O topikstarter iniciou a linha no modo "quanto tempo?" e fez algumas reivindicações não fundamentadas. Se ele tivesse fornecido dados devidamente coletados, 50% das perguntas teriam caído na fase de coleta de dados.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Bom dia a todos vocês!
Deparei-me com o seguinte problema:
Ter 32 processadores lógicos no sistema - usando 32 agentes para otimização respectivamente (+ outros 40 remotos)
Cada agente constrói rapidamente um cache de tamanho totalmente inadequado de 2-2,6GB, que no total é mais de 70GB por dia! O cache não se apaga sozinho, e está em constante crescimento. A única coisa que impediu a loucura foi o esgotamento do espaço em disco. Depois disso, os agentes, estupidamente, param de trabalhar.
As perguntas são as seguintes:
Alguém já se deparou com tal problema? Como lidar com isso? O que pode causar tamanhos de cache tão grandes?
Escreveu um pedido para Servicedesk, até agora silêncio.