[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Xeon quad - desempenho no debian



On 5/29/07, Jonathan Martins <jonathanrmartins@yahoo.com.br> wrote:
Tenho aqui duas maquinas, uma com dois processadores  Intel(R) Xeon(R) CPU
  5140  @ 2.33GHz 8GB ram disco rigido 80GB SAS e outra com dois
processadores  quad Intel(R) Xeon(R) CPU  E5345  @ 2.33GHz 8GB de ram e
disco rigido SAS 80GB, as duas com 4MB de cache. A quad é bem melhor, em
tese, que a 5140. As duas estao com debian etch, kernel 2.6.18-4-amd64. Os
8GB de ram estão reconhecidos corretamente, tudo certinho. Essa máquina é
utilizada para cálculos pesados, baseados em aplicaćões feitas em fortran.
"rodando" aplicaćões semelhantes nas duas máquinas estou percebendo que a
quad E5345 está mais lenta que a 5140, mas teoricamente a quad é bem
superior! O uso o compilador intel fortran 9.1. Isso não é estranho?
Gostaria de ouvir a opinião de colegas sobre como entender o uso dos
processadores no quad core, já que cada pastilha tem 4 nucleos, é como se
fossem processadores em paralelo? Se eu utilizar uma aplicaćão serial essa
aplicaćão vai utilizar apelas um dos processadores e ou outros ficarão
ociosos? Vejam a saida do top de cada um dos processadores
Eu tenho usado os compiladores da Intel justamente pelo ganho de
desempenho deles em relação ao GCC (e uso processadores da AMD, não
tenho máxima otimização mas ainda assim ajuda e *muito*). Basicamente,
quando se fala em desempenho tem de levar em conta dois fatores:
processamento e I/O.

O processamento tu otimiza customizando o kernel, a família x86_64 é
altamente otimizada mas ainda tem alguns pequenos tunnings referentes
ao processor type, e no teu caso, o multiprocessamento.

Há vários modelos de multiprocessamento, eu recomendo que tu use o
NUMA[1] para estes Xeon, já que usa uma vazão de dados monstruosa se
comparada com modelos UMA[2]. Nestes modelos é interessante desativar
o SMT (symetric multithreading), o conceito de multithread em
múltiplos núcleos é diferente do HT.

Atente também para os tempos de preempção, por ser multiprocessado,
use uma latência menor, 100Mhz, talvez 250Mhz.

Em relação ao I/O, a memória é double channel? Acredite, isso ajuda muito. :)

Também tome cuidado em relação ao sistema de arquivos: o simples fato
de montar a partição com os dados com a opção "noatime" dá um grande
aumento de memória, ao custo de não registrar datas de modificação nos
arquivos e diretórios.

O uso do sistema de arquivos adequado também é importante, se quer
desempenho e estabilidade XFS é uma excelente escolha para uso geral.
Para arquivos de dados muito grandes, EXT3 é seguro e tem um bom
desempenho. Para muitos arquivos pequenos o ReiserFS se comporta
melhor.

Dependendo da aplicação, usar um diretório temporário (/tmp) em
memória compartilhada (shmem) ao invés de um sistema de arquivos
normal pode ajudar.

No mais é só testar. :)



1 - http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access
2 - http://en.wikipedia.org/wiki/Uniform_Memory_Access

Reply to: