Descobrimos um problema de desempenho relacionado a E / S ao usar o kernel SLES11 SP2 padrão. Nossa mesma aplicação no mesmo hardware não teve nenhum problema com (o reconhecidamente antigo SLES9 SP3).
Tivemos a sensação de que isso tem algo a ver com o kernel e fizemos o seguinte experimento até agora:
3.0.13 do kernel.org. kernel-source-3.0.13-0.27.1 da Novell. Esta é a 3.0.13 source com todos os patches / ajustes da Novell já aplicados. 3.0.13 fez um make x86_64_defconfig para gerar um arquivo de configuração padrão, então usei make menuconfig para ativar o controlador de unidade e os drivers da placa de rede necessários para nosso hardware e construímos o kernel. Este kernel tinha no de problema de desempenho. 3.0.13-0.27.1 obtivemos o arquivo de configuração que a Novell vem com o kernel compilado, construímos com ele e tivemos o mesmo problema de desempenho que tivemos com o kernel compilado pela Novell. 3.0.13-0.27.1 , usei o arquivo de configuração usado em (3), construído com ele (aceitando os padrões de configuração adicionais que a versão do configurador da Novell queria incluir). Não houve nenhum problema de desempenho. 3.0.13 , pegou o arquivo de configuração usado em (4), construído com ele (perdendo as opções de configuração somente Novell no arquivo). Não houve nenhum problema de desempenho. 3.0.13-0.27.1 , pegou o arquivo de configuração usado em (4) e fez com que os drivers de dispositivo (mas nada mais) correspondessem ao arquivo de configuração em (3) (isto é, desativava muitos drivers de dispositivo que não eram não está sendo usado de qualquer maneira). Não houve nenhum problema de desempenho. Portanto, a árvore 3.0.13 do kernel.org não teve nenhum problema de desempenho. A árvore 3.0.13-0.27.1 da Novell só teve o problema quando construímos com o arquivo de configuração da Novell ou com um arquivo idêntico ao da Novell, mas com a maioria dos drivers de dispositivos configurados.
Dado que, parece que há alguma opção de configuração somente Novell (e implicitamente o código Novell é ativado) causando o problema, ou alguma interação ruim entre um patch Novell e alguma opção padrão (dado que o -close-as-possible-to-Novell's-config fez não ter o problema quando construído contra a fonte virgin kernel.org).
Enquanto continuamos a investigar, já que eu não sou um hacker de kernel (eu sei como construir o kernel, mas é sobre isso) eu estava me perguntando que "famílias" de opções de configuração seriam as melhores para focar a atenção. A idéia seria alterar algumas opções da configuração "Novell" para a configuração "kernel.org" e ver se o problema desaparece. Em seguida, defina-as novamente e tente outro conjunto, e assim por diante.Mas eu gostaria de restringir isso - daí a questão sobre quais opções de configuração seriam boas apostas para jogar primeiro.
Resolvemos o problema! Fazendo uma busca quasi binária nas diferenças de opções de configuração entre kernels "bons" e "ruins", descobrimos que o problema é devido ao SLES11 ativando ext3 escrever barreiras por padrão. Um kernel construído com barreiras de gravação desativadas por padrão não tem o problema. E quando usamos um kernel com o problema, mas colocamos barrier=0 nas opções de montagem em /etc/fstab , o problema desapareceu.
Tags performance kernel linux sles