Assumindo que existe de fato um culpado (um único usuário) responsável pela maioria dos 2.5k IOPS:
Eu começaria com top
- a essa taxa, você deve ver um ou alguns usuários e processos destacando-se nos processos ativos na caixa, principalmente dormindo, mas muitas vezes no estado pronto também - eu pressionaria i
(para ocultar processos inativos), em seguida, pressione e segure a barra de espaço para atualizações muito rápidas.
Gostaria de destacar os usuários que aparecem com mais frequência e exibir apenas seus processos em top
para uma visualização mais estável.
Se você vir muitos processos do mesmo usuário (por exemplo, uma compilação complexa executada no NFS) - verifique a árvore de processos para esse usuário para confirmar pstree -ps <user>
. Pode ser difícil provar que tal coleta de processo é a causa diferente de iniciar / parar e observar as correlações nas mudanças de atividade no lado do netapp.
Se o culpado for um processo único, esperaria que fosse uma presença estável na saída top
. Além de find
, eu também procuraria:
- rsync, dd, cp, rcp, scp, tar, soluções de backup, etc.
- os típicos interpretadores de programação de alto nível: python, java, etc (executando scripts personalizados)
- aplicativos da web / banco de dados
- sistemas CI / QA (se o servidor estiver envolvido no desenvolvimento sw)
Mas também pode ser algo completamente personalizado, você não o encontrará "pelo nome".
Também é possível que a taxa seja o efeito coletivo de muitos usuários (o servidor NFS está mantendo suas homedirs e / ou partições de projeto compartilhadas?) - não há muito o que você possa fazer sobre isso - talvez seja hora de escalar o NFS armazenamento?