Melhor sistema operacional para implantar um aplicativo Java de baixa latência?

Question

Temos um sistema de negociação de baixa latência (manipuladores de feeds, análise, entrada de pedidos) escritos em Java. Ele usa extensivamente o TCP e o UDP, não usa o Infiniband ou outras redes não padrão.

Alguém pode comentar sobre as compensações de várias configurações de sistemas operacionais ou operacionais para implantar este sistema? Embora a taxa de transferência seja obviamente importante para acompanhar os alimentos modernos de preços, a latência é a nossa prioridade número 1.

Solaris parece um candidato natural desde que criaram Java; Devo usar processadores SPARC ou X64?

Ouvi coisas boas sobre Rhel e Slet, são as versões certas do Linux para usar em nosso benchmarking.

Alguém testou o Windows contra os OSs acima? Ou supõe -se que não acompanhe?

Eu gostaria de deixar o debate Java vs C ++ para um thread diferente.

Answer 1

Os fornecedores adoram esse tipo de referência. Você tem código, certo?

IBM, Sun/Oracle, a HP vai adorar executar seu aplicativo em seus equipamentos para demonstrar suas vantagens.

Faça -os fazer isso. Se você tiver código, faça com que os fornecedores executem uma demonstração em seu equipamento para mostrar o que é melhor para suas necessidades.

É fácil, indolor, gratuitamente, e factual. A decisão final será fácil e óbvia. E você saberá como instalar e sintonizar para maximizar o desempenho.

---

O que eu odeio fazer é prever esse tipo de coisa antes da o código está escrito. Muitos clientes pediram uma recomendação de H/W e OS antes de terminarmos de identificar todos os casos de uso. Pedir esse tipo de precognição é uma loucura simples.

Mas você tem código. Você pode produzir casos de teste que exercem seu código. Perfeito.

Answer 2

Para um ambiente de negociação, além de baixa latência, você provavelmente está preocupado com a consistência e a latência, portanto, o foco em reduzir o impacto das pausas do GC o máximo possível pode muito bem fornecer mais benefícios do que as opções diferentes.

• o G1 Coletor de lixo Nas versões recentes do Hotspot SUNS, a VM melhora a parada do mundo em pausa, de maneira semelhante à JROCKIT VM
• Para garantias de desempenho real, porém, Sistemas Azul A versão do compilador de hotspot em seu aparelho Java fornece as pausas mais baixas disponíveis - também é escala para um tamanho massivo - 100s de pilha GB e 100s de núcleos.
• Eu descontaria o Java Real Time - embora você tenha garantias de resposta, sacrificaria a taxa de transferência para obter essas garantias

No entanto, se você planeja usar seu sistema de negociação em um ambiente em que todas as contagens de microssegundos, você realmente terá que conviver com a falta de consistência que você receberá da geração atual de VM - nenhuma delas (exceto em tempo real) garantias Pussas com baixo microssegundos GC. Obviamente, nesse nível, você encontrará os mesmos problemas da atividade do sistema operacional (Processo Pré-Emption, Manuseio de Interrupção, Falhas de Página, etc.). Nesse caso, uma das variantes em tempo real do Linux vai ajudá -lo.

Answer 3

Eu não descartaria o Windows disso apenas porque é o Windows. Minha expiração nos últimos anos foi que as versões do Windows da JVM Sun geralmente eram o desempenho mais maduro em contraste com o Linux ou Soaris x86 no mesmo hardware. A JVM para Solaris Sparc também pode ser boa, mas acho que com o Windows no x86 você terá mais energia por menos dinheiro.

Answer 4

Eu recomendo fortemente que você procure um sistema operacional com o qual já tenha experiência. Solaris é uma besta estranha se você conhece apenas Linux, por exemplo,

Além disso, eu recomendo fortemente usar uma plataforma na verdade suportado Por Sun, pois isso tornará muito mais fácil obter assistência profissional quando você realmente precisar.

http://java.sun.com/javase/6/webnotes/install/system-configurações.html

Answer 5

Eu provavelmente me preocuparia com a coleta de lixo causando latência bem antes do sistema operacional; Você já olhou para ajustar isso?

Se eu estivesse disposto a gastar tempo para testar diferentes OSS, tentaria Solaris 10 e NetBSD, e provavelmente uma variante Linux para uma boa medida.

Eu experimentaria arquiteturas de 32-VS-64; 64 bits fornecerão um espaço de endereço de heap maior ... mas levará mais tempo para abordar cada bit de memória.

Suponho que você tenha perfilado sua inscrição e saiba onde estão os gargalos; Pelo comentário sobre o GC, você fez isso. Nesse caso, seu aplicativo não deve estar ligado à CPU, e a arquitetura de chip não deve ser uma preocupação principal.

Answer 6

Não acho que os ambientes de código gerenciados e o processamento em tempo real se juntem muito bem. Se você realmente se preocupa com a latência, remova a camada imposta pelo código gerenciado. Este não é um argumento Java vs C ++, mas um argumento java/c#/... vs c/c ++/fortran/..., e acredito que essa é uma discussão de design válida.

E sim, quero dizer fortran, executamos vários sistemas quase em tempo real com uma fundação Fortran.

Answer 7

Uma maneira de gerenciar a latência é ter várias JVM dividindo o trabalho com pilhas menores, para que uma coleta de lixo para parar o mundo não consuma tão tempo quando acontece e afeta menos processos.

Outra abordagem é carregar um conjunto de JVMs com memória suficiente e alocar os processos para garantir que não haja uma coleta de lixo para parar a World durante as horas em que você se preocupa com a latência (se este não é um aplicativo 24 horas por dia, 7 dias por semana), e reinicie os JVMs no horário de folga.

Você também deve observar outras implementações da JVM como uma possibilidade (como o JRocket). Obviamente, se algum deles for apropriado depende inteiramente do seu aplicativo específico.

Se alguma das opções acima importa para sua abordagem, isso afetará a escolha do sistema operacional. Por exemplo, se você for com outra implementação da JVM, isso poderá limitar as opções do sistema operacional e, se você for agrupado ou executando várias JVMs para o aplicativo, isso pode exigir algumas ferramentas de sistema operacional subjacentes melhores para gerenciar efetivamente, influenciando ainda mais a opção do sistema operacional .

Answer 8

A escolha do sistema operacional ou configurável é completamente redundante, considerando a disponibilidade de tecidos de rede mais rápidos.

Olhe para 10Gige com NICs de dedo do pé, ou a solução mais rápida de 4x QDR (40Gbs) Infiniband, mas com Ipoib Apresentando uma interface Ethernet padrão e roteamento.