Disco ocupado 101% o tempo todo

Question

Eu tenho um servidor Linux do OpenNMS que está com desempenho de disco ruim. A máquina é um EC2 dentro de um VPC. no topo mostra:

iotopmostra:

Como faço para reduzir os números de E / S e diminuir a utilização do disco?

Resposta

ionica :

ubuntu@ip-10-12-251-11:~$ sudo ionice -c3 -p $(pidof opennms)
ionice: option requires an argument -- 'p'

ionice - sets or gets process io scheduling class and priority.

Usage:
  ionice [OPTION] -p PID [PID...]
  ionice [OPTION] COMMAND

Options:
  -c, --class <class>   scheduling class name or number
                           0: none, 1: realtime, 2: best-effort, 3: idle
  -n, --classdata <num> scheduling class data
                           0-7 for realtime and best-effort classes
  -p, --pid=PID         view or modify already running process
  -t, --ignore          ignore failures
  -V, --version         output version information and exit
  -h, --help            display this help and exit

    

Answer 1

Teste rrenice do pacote Debian pslist . Exemplo, isso define a prioridade de opennms e seus descendentes para a configuração mais baixa possível:

sudo rrenice 19 opennms

Ou isso não está disponível, use renice :

sudo renice -n 19 -p $(pidof opennms)

Para programas que consomem disco, use ionice :

ionice -c3 -p $(pidof opennms)

BTW : esse processo opennms não deve ter esse recurso com fome. Alguma coisa está com buggy ou pendurada lá.

    

Answer 2

Essas figuras mostram um processo de gravação, portanto, o ajuste de cache sugerido pelo OpenNMS não ajudará.

No entanto, isso pode ajudar se você sacrificar durabilidade . Se o seu OpenNMS morre, não importa se o banco de dados mostra que ele está morrendo alguns segundos antes. (Isso é diferente, por exemplo, de um servidor de email, no qual os clientes confiam na semântica pelo menos uma vez). Você pode perder as alterações de configuração feitas imediatamente antes de uma falha; talvez apenas certifique-se de que você perceba falhas e verifique se o sistema ainda está on-line depois de fazer as alterações de configuração. Tente synchronous_commit = off . Por padrão, a janela de perda de durabilidade é de apenas 600ms.

Se synchronous_commit = off tiver o efeito desejado, há uma alternativa possível que não sacrifica a durabilidade. Veja commit_delay . Parece-me que o OpenNMS poderia funcionar muito bem com isso também. Você deseja definir um commit_delay na ordem da recíproca de sua IOPS observada. Então eu acho que você poderia aumentar <poller-configuration threads= se a utilização da CPU (e RAM) ainda estiver baixa.