Ontem o Enéas me apresentou um problema que estava ocorrendo numa PowerEdge 6800 com quatro processadores Xeon. Um processo Java, que funcionava direito numa PowerEdge 6600 com dois processadores Xeon, travava na 6800.
No final das contas o problema foi resolvido desabilitando a função de hyperthreading (HT) dos processadores, o que pode ser feito via BIOS ou via um argumento (noht) para o kernel do Linux. O efeito colateral da mudança é que com o HT habilitado cada Xeon se apresenta como dois processadores virtuais enquanto que com o HT desabilitado cada Xeon é um processador. Deste modo, ao desabilitar o HT, os usuários passaram a ver somente quatro ao invés de oito processadores.
Bem, o fato é que eu não sabia direito o que é hyperthreading. Então recorri à wikipedia. Vale a pena ler os tópicos sobre Hyper-threading e sobre Dual-core (DC).
Notem que são duas tecnologias diferentes cujo efeito é fazer com que um processador físico se apresente para o sistema operacional como dois processadores lógicos.
Os Xeons da 6800 implementam HT. Parece que a Intel está pra lançar novas versões do Xeon implementando DC, mas por enquanto só a AMD já vende este tipo de coisa.
Pelo que entendi, um processador DC contém realmente dois processadores num mesmo chip. Eles compartilham o barramento de I/O e o cache secundário, de modo que pode haver mais contenção pelo barramento do que numa solução com dois processadores físicos, mas há menor consumo de energia, de espaço e de dinheiro.
Já com HT é apenas um processador com dois conjuntos de registradores, de modo que ele pode manter simultaneamente o estado de duas threads do sistema operacional e melhor utilizar suas unidades de controle. Mas o ganho efetivo de desempenho é da ordem de 15% em relação a uma CPU sem HT. Bem menos que com DC.
A pergunta que não quer calar:
ResponderExcluirQual a real causa do travamento?
Seria por acaso problemas com a máquina virtual java ao usar o HT?
Um strace do processo não mostrou nada?
O tal processo Java tinha dezenas de threads. Fiz um strace em todas elas e quase todas estavam paradas na primitiva futex que é um mecanismo rápido de exclusão mútua entre processos.
ResponderExcluirEu acho que o problema está relacionado à implementação da futex em CPUs HT. Não encontrei nada específico, mas há vários patches circulando para corrigir problemas na implementação do futex. Provavelmente algum deles corrigiria o problema.
Logo o Enéas vai testar o RHEL 4 com kernel 2.6 (o que deu problema é 2.4) em outra máquina e creio que ele vá refazer o teste deixando o HT habilitado pra ver se o novo kernel não tem mais o problema.