Como diagnosticar o comportamento ext3 muito ruim e lento?

Question

Estou gerenciando um antigo servidor admin executando a atualização 3 do Redhat WS4, e temos um volume ext3 no qual eu tinha um grande banco de dados sqlite (30GB) montado em / opt.

Toda vez que eu faço grandes consultas / inserções neste banco de dados, o IO aguarda tanto que não podemos mais entrar no servidor, nem o sudo para outro usuário, nem editar um arquivo crontab (o vi nunca termina).

Estou substituindo o sqlite pelo mysql e, ao fazer o backup do diretório 19GB ou mysql, encontro o mesmo problema.

Observe que essas operações são feitas com um usuário comum. O servidor é um DL385 G1 PROLIANT com kernel 2.6.9-34.ELsmp em 64bits.

Agora estou pensando em remontar o volume como ext2 para ver se o registro no diário é a fonte do meu problema, mas honestamente não sei o que verificar em seguida.

Toda cópia de arquivo séria termina bloqueando o servidor para outros usuários que tentam efetuar logon, e o servidor volta ao normal quando a cópia termina.

Eu preciso apontar para onde procurar em seguida para explicar tal comportamento (disco antigo ficando mais lento? kernel ruim com bug conhecido? registro de registro corrompido que dispara milhares de leituras / gravações supérfluas? etc ...)

Obrigado antecipadamente.

    

Answer 1

Respondendo a minha própria pergunta, quando finalmente encontrei a verdadeira fonte do problema.

1_ syslog.conf foi configurado para logar arquivos e liberar imediatamente 2_ nossos proxies foram configurados recentemente para usar este syslog do servidor para registrar tentativas de autenticação LDAP. Estes acontecem a uma taxa de vários por segundo por causa de programas de atualização estúpidos (ou mal configurados), no Adobe Updater.

Em suma, o servidor estava constantemente liberando buffers em disco e isso mostrava toda vez que tentávamos gravar em arquivos grandes.