Slow open () chamada de sistema no linux

2

Nós temos tido problemas com o nosso servidor de arquivos Samba rodando no Debian Etch com o kernel Linux 2.6.16. É um antigo servidor Dell PowerEdge 2650, mas nunca teve um problema como este antes, e o problema começou esta manhã, sem nenhuma configuração ou outras alterações.

Enquanto o problema se manifesta de várias maneiras, todos eles poderiam ser explicados pela chamada do sistema open () sendo muito lenta para ser concluída. Aqui está um strace de "cat logon.bat", onde o arquivo está em um sistema de arquivos local ext3:

$ sudo strace -p 3548 -tt 
Process 3548 attached - interrupt to quit
11:20:40.563088 open("logon.bat", O_RDONLY|O_LARGEFILE) = 3
11:21:00.070660 fstat64(3, {st_mode=S_IFREG|0664, st_size=44, ...}) = 0
11:21:00.070923 read(3, "cscript \\staff\netlogon\logon.v"..., 4096) = 44
11:21:00.085676 write(1, "cscript \\staff\netlogon\logon.v"..., 44) = 44
11:21:00.085906 read(3, "", 4096)       = 0
11:21:00.086053 close(3)                = 0
11:21:00.086222 close(1)                = 0
11:21:00.086382 exit_group(0)           = ?
Process 3548 detached

Os timestamps mostram que a chamada open () levou 20 segundos. (Na verdade, foi muito mais tempo, já que o strace foi iniciado algum tempo após o comando ter sido executado.) Mas execuções imediatamente subsequentes do mesmo comando não têm a chamada slow open (). Mas algum tempo depois, está lento novamente.

O servidor foi reiniciado e o problema continua. Não há nada sendo reportado no kern.log, e o hardware não está reportando nenhuma falha.

O servidor ainda está parcialmente funcionando, por isso não o estamos removendo imediatamente. Fora do horário de trabalho, poderemos executar mais testes, incluindo um fsck forçado no sistema de arquivos em questão.

Mas nós realmente não temos uma boa idéia do problema, então estamos procurando por teorias sobre o que pode estar errado, bem como idéias de quais testes devem ser executados para diagnosticar melhor o problema. Alguma sugestão?

Atualizar

Eu deveria ter apontado que esse sistema de arquivos específico está em um dispositivo Apple Xserve RAID (conectado via FibreChannel). A ferramenta RAID Admin está fornecendo uma luz de status verde para todas as unidades, bem como para a matriz como um todo, e não há nenhum evento no log que indique qualquer tipo de problema.

    
por TimB 28.01.2011 / 02:27

2 respostas

0

Isso está sendo executado em um dos controladores RAID da Dell (parece que provavelmente seria um PERC / 4something). Em caso afirmativo, o driver do kernel megaraid não parece reagir ou relatar problemas na unidade, você precisa instalar o Coisas do OpenManage da Dell para ver o que está acontecendo no nível do hardware. Este tópico sugere que, depois de instalá-lo, você usaria comandos como

omreport storage controller 
omreport storage adisk controller=0 
omreport storage vdisk controller=0 

Aqui está a documentação da Dell sobre omreport.

Os novos controladores SAS Megaraid (PERC / 5) podem usar a MegaCLI sozinha para gerenciá-los.

    
por 28.01.2011 / 03:47
0

Holy hard-disks, batman! Isso é LENTO!

Isso realmente se parece com problemas de hardware de baixo nível nos discos rígidos. Espero que, se você conectar uma unidade diferente (usb, cdrom, SATA IDE local) que não veja esses problemas? Se você ainda não tentou isso, recomendo que faça isso.

Se você ainda encontrar problemas com discos diferentes, talvez seja melhor tentar reinstalar o sistema operacional (ou apenas inicializá-lo a partir de uma imagem knoppix / similar ao teste). Também pode ser útil ver as opções de montagem e a saída de 'free'.

    
por 28.01.2011 / 10:30