Estou tentando avaliar alguns SSDs para um caso de uso de vídeo sob demanda. Fizemos alguns testes de benchmarking, mas gostaríamos de ter uma ideia do número de fluxos de vídeo que eles podem suportar com um teste de carga mais realista do que as ferramentas típicas de benchmark.
Até agora, fiz isso:
--vout dummy --aout dummy --codec dummy para que ele solicite o arquivo continuamente, mas não decodifica nele para economizar na CPU) Eu também tenho um decodificador que decodifica a partir desse mesmo SSD. A ideia é ver se podemos notar visualmente quando o desempenho do SSD começa a desmoronar.
Estou obtendo resultados decentes, mas o principal problema é que os servidores de carga atingem um limite (no intervalo de 700-800 com 10-12GB de RAM) no número de fluxos que podem ser capturados. Parece que é devido a muita troca acontecendo ao mesmo tempo, empurrando iowait para o alto e tornando o servidor quase irresponsável.
Para resumir, minhas perguntas são:
/proc/sys/vm/swappiness mas não pareceu fazer diferença) Obrigado,
Tim
Eu faço vídeo sob demanda e não há substituto para realmente escrever um código que retrate com precisão as características reais da reprodução. Nós escrevemos um que chamamos de 'VODBasher', ele usa o mecanismo de transporte exato que realmente usamos na plataforma real e nós o executamos a partir de locais reais em todo o lugar. Isso nos ajudou a entender onde iríamos ver os problemas e onde não iríamos. Qualquer outra coisa é um trabalho de adivinhação.
Parece bastante razoável que você de fato ficaria sem memória RAM em seus "servidores de carga" (agindo como clientes nesse cenário) com 700-800 cópias de VLC em execução. Isso é apenas 12-17MB de RAM usada por instância, e lá vai o seu 10-12GB. (Portanto, não é de admirar que a troca de opções não te leve muito longe).
Existe alguma razão em particular para realmente carregar o filme com vlc (mesmo com saída fictícia), em vez de simplesmente descartá-lo para /dev/null ?