O problema pode não ser nem memória e nem processador, mas sim entrada/saída (I/O) do disco.

O comando top pode nos ajudar novamente:

# top
Cpu (s): 11,4%us, 29,6%sy, 0,0%ni, 58,3%id, 0,7%wa, 0,0%hi, 0,0% si, 0,0% st

Se o %wa for alto, provavelmente é problema de I/O, isso se você não estiver utilizando memória SWAP.

Agora, vamos encontrar em qual disco ou partição está ficando a maior parte do tráfego de I/O utilizando os aplicativos iostat e iotop:

# iostat
Linux 2.6.24-19-server (srv-matiello) 01/31/2009

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.73    0.07    2.03    0.53    0.00   91.64

Device:    tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda       9.82       417.96        27.53   30227262    1990625
sda1      6.55       219.10         7.12   15845129     515216
sda2      0.04         0.74         3.31      53506     239328
sda3      3.24       198.12        17.09   14328323    1236081

O comando iostat sem argumentos nos dá uma boa visão geral das estatísticas do I/O do seu disco.

Como com o top, iostat lhe dá a saída da percentagem do CPU. Abaixo disso ele fornece a composição de cada unidade e a partição em seu sistema e estatísticas para cada um:

• TPS - transações por segundo.
• Blk_read/s - blocos de leitura por segundo.
• Blk_wrtn/s - blocos de escrita por segundo.
• Blk_read - blocos totais de leitura.
• Blk_wrtn - blocos totais de escrita.

Na saída do comando podemos identificar qual partição, ou partições, estão com maior tráfego de I/O, e se a maior parte do tráfego é de leitura (Blk_read/s) ou escrita (Blk_wrtn/s).

Por exemplo, se você tem uma sobrecarga de I/O e você suspeita que o culpado é o backup remoto, compare as estatísticas de leitura e gravação. Porque você sabe que uma tarefa de backup remoto vai principalmente utilizar a leitura do seu disco, se você ver que a maioria do I/O é escrita, você pode presumir que o problema não está no backup.

Vamos para o comando iotop:

# iotop
Total DISK READ: 189.52 K/s | Total DISK WRITE: 0.00 B/s
  TID  PRIO  USER DISK READ DISK WRITE  SWAPIN     IO>    COMMAND
8169 be/4 root  189.52 K/s   0.00 B/s  0.00 %  0.00 % rsync --server --se
4243 be/4 thur    0.00 B/s   3.79 K/s  0.00 %  0.00 % cli /usr/lib/gnome-
4244 be/4 thur    0.00 B/s   3.79 K/s  0.00 %  0.00 % cli /usr/lib/gnome-
    1 be/4 root    0.00 B/s   0.00 B/s  0.00 %  0.00 % init

Você pode ver que o rsync nesta máquina é o responsável pelo maior I/O (DISK READ).

Depois de encontrar o causador da sobrecarga, agora você tem que analisar diversos fatores.

Em alguns casos o problema do I/O pode ser um script que está rodando que está usando mais I/O do disco do que o esperado, e você pode simplesmente matar o processo e resolver o problema.

Em outras ocasiões, o problema de I/O pode ser um processo de banco de dados, mas pode não ser seguro simplesmente matar o processo, pois pode acabar corrompendo o banco de dados e perdendo os dados.

Além disso, o problema pode ser a carga de um trabalho único que está em execução na máquina e não deve impactar na carga no futuro, então você pode simplesmente deixar o processo completar.

Talvez a real solução pode ser adicionar mais recursos ao servidor ou adicionar mais servidores para dividir a carga.

Podem ser tantas coisas diferentes que causam a sobrecarga no servidor, que é difícil enumerá-las aqui, mas espero que, sendo capaz de identificar as causas de sua sobrecarga, você vai estar no caminho certo na próxima vez que você receber um alerta de que uma máquina é/está lenta.