Web site mata E / S do disco rígido, como evitar?

4

A situação: Eu tenho um servidor, no qual temos 2-3 projetos. Começando não muito tempo atrás, o servidor começou desligando (Nós não conseguimos nos conectar a ele pelo ssh, e os clientes conectados tiveram que esperar 20 minutos para o topo dar resultados)

Hoje comecei a executar o gstat enquanto estava neste estado e vi que ele permanece em 100% no da0, da0s1 e da0s1f. Eu não sei bem o que esses ids meen, mas eu entendo que alguns processos apenas matam o HD bombardeando-o com pedidos.

Eu peço algumas proposições. Eu não sei como encontrar o culpado e não posso evitar isso.

Eu tenho freebsd no servidor.

    
por Taras Voinarovskyi 09.12.2011 / 19:36

2 respostas

15

Se sua versão do FreeBSD for relativamente moderna, top tem uma opção -m que mostra os principais locutores de E / S se você fornecer o parâmetro " io ":

top -m io

Nesse caso, eu também usaria a opção -S (para mostrar processos do sistema, no caso de um deles ser o culpado). Para se comportar melhor sob carga, eu usaria -q (para renegá-lo para ser executado em uma prioridade mais alta) e -u (para ignorar a leitura de /etc/passwd , o que ajudaria a carregar mais rápido).

Como está demorando muito para executar top , eu diria a ele para exibir apenas duas passagens de sua saída ( -d 2 ) e, em seguida, executar no modo em lote ( -b ), para que ele seja automaticamente .

No primeiro momento em que você executa top desta forma, sua primeira seção de saída mostrará as contagens cumulativas de I / O para um número de processos por um longo tempo (talvez desde o tempo de inicialização? Eu não tenho certeza sobre isso). Na primeira tela, você pode ver quem são os principais palestrantes ao longo do tempo. Na segunda tela, você pode ver seus principais participantes nos últimos dois segundos.

Então, juntando tudo, e executando um find para que alguma E / S real esteja acontecendo:

# top -S -m io -qu -b -d 2 10
last pid: 39560;  load averages:  0.28,  0.19,  0.08  up 6+04:02:29    11:28:28
125 processes: 2 running, 104 sleeping, 19 waiting

Mem: 96M Active, 668M Inact, 122M Wired, 25M Cache, 104M Buf, 17M Free
Swap: 2048M Total, 96K Used, 2048M Free


  PID    UID     VCSW  IVCSW   READ  WRITE  FAULT  TOTAL PERCENT COMMAND
   11      0        0 81032823      0      0      0      0   0.00% idle: cpu0
39554    105   129857 556534  74894      0      0  74894  13.62% find
39533    105   443603 614796      0      0      0      0   0.00% sshd
   36      0   1793393      0      0      0      0      0   0.00% irq23: vr0
   24      0   2377710   2680      0      0      0      0   0.00% irq20: atapci0
   50      0   533513 3415672     66 345350      0 345416  62.81% syncer
   13      0   78651569   7230      0      0      0      0   0.00% swi4: clock sio
    5      0   1911601  20905      0      0      0      0   0.00% g_down
    4      0   2368511  12100      0      0      0      0   0.00% g_up
   37      0    53308    313      0      0      0      0   0.00% acpi_thermal

last pid: 39560;  load averages:  0.28,  0.19,  0.08  up 6+04:02:31    11:28:30
125 processes: 2 running, 104 sleeping, 19 waiting
CPU:  1.9% user,  0.0% nice,  6.0% system,  2.2% interrupt, 89.9% idle
Mem: 96M Active, 671M Inact, 123M Wired, 25M Cache, 104M Buf, 14M Free
Swap: 2048M Total, 96K Used, 2048M Free

  PID    UID     VCSW  IVCSW   READ  WRITE  FAULT  TOTAL PERCENT COMMAND
   11      0        0   1115      0      0      0      0   0.00% idle: cpu0
39554    105      606    651    501      0      0    501 100.00% find
39533    105      616    695      0      0      0      0   0.00% sshd
   36      0     1251      0      0      0      0      0   0.00% irq23: vr0
   24      0      501     20      0      0      0      0   0.00% irq20: atapci0
   50      0        2      2      0      0      0      0   0.00% syncer
   13      0      313      3      0      0      0      0   0.00% swi4: clock sio
    5      0      501     26      0      0      0      0   0.00% g_down
    4      0      501      8      0      0      0      0   0.00% g_up
   37      0        0      0      0      0      0      0   0.00% acpi_thermal

Depois de restringir o processo que está realizando todas as E / S, você pode usar truss ou devel/strace ou sysutils/lsof ports para ver o que os processos com fome de disco estão fazendo. (se o seu sistema estiver muito ocupado, é claro, você não conseguirá instalar as portas facilmente):

Por exemplo, para ver quais arquivos e outros recursos meu ntpd process está usando:

# lsof -p 890
ntpd        890   root  cwd     VDIR       0,93       1024        2 /
ntpd        890   root  rtd     VDIR       0,93       1024        2 /
ntpd        890   root  txt     VREG       0,98     340940   894988 /usr/sbin/ntpd
ntpd        890   root  txt     VREG       0,93     189184    37058 /libexec/ld-elf.so.1
ntpd        890   root  txt     VREG       0,93      92788    25126 /lib/libm.so.5
ntpd        890   root  txt     VREG       0,93      60060    25130 /lib/libmd.so.4
ntpd        890   root  txt     VREG       0,98      16604   730227 /usr/lib/librt.so.1
ntpd        890   root  txt     VREG       0,93    1423460    25098 /lib/libcrypto.so.5
ntpd        890   root  txt     VREG       0,93    1068216    24811 /lib/libc.so.7
ntpd        890   root    0u    VCHR       0,29        0t0       29 /dev/null
ntpd        890   root    1u    VCHR       0,29        0t0       29 /dev/null
ntpd        890   root    2u    VCHR       0,29        0t0       29 /dev/null
ntpd        890   root    3u    unix 0xc46da680        0t0          ->0xc4595820
ntpd        890   root    5u    PIPE 0xc4465244          0          ->0xc446518c
ntpd        890   root   20u    IPv4 0xc4599190        0t0      UDP *:ntp
ntpd        890   root   21u    IPv6 0xc4599180        0t0      UDP *:ntp
ntpd        890   root   22u    IPv4 0xc4599400        0t0      UDP heffalump.prv.tycho.org:ntp
ntpd        890   root   23u    IPv4 0xc4599220        0t0      UDP ns0.prv.tycho.org:ntp
ntpd        890   root   24u    IPv4 0xc45995c0        0t0      UDP imap.prv.tycho.org:ntp
ntpd        890   root   25u    IPv6 0xc4599530        0t0      UDP [fe80:4::1]:ntp
ntpd        890   root   26u    IPv6 0xc45993b0        0t0      UDP localhost:ntp
ntpd        890   root   27u    IPv4 0xc4599160        0t0      UDP localhost:ntp
ntpd        890   root   28u     rte 0xc42939b0        0t0

... e o que o sistema está chamando (note que isso pode exigir muitos recursos):

# truss -p 890
SIGNAL 17 (SIGSTOP)
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call'
SIGNAL 14 (SIGALRM)
sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call'
^C

sysutils/strace é semelhante a truss , mas você precisará ter o sistema de arquivos /proc montado:

# strace -p 890
strace: open("/proc/...", ...): No such file or directory
trouble opening proc file

# grep ^proc /etc/fstab
proc            /proc                           procfs          rw,noauto       0       0

# mount /proc

# mount | grep /proc
procfs on /proc (procfs, local)

... e depois funcionará:

# strace -p 890
Process 890 attached - interrupt to quit
--- SIGALRM (Alarm clock: 14) ---
--- SIGALRM (Alarm clock: 14) ---
syscall_417(0xbfbfea10)                 = -1 (errno 4)
select(29, [?], NULL, NULL, NULL)       = -1 EINTR (Interrupted system call)
--- SIGALRM (Alarm clock: 14) ---
--- SIGALRM (Alarm clock: 14) ---
syscall_417(0xbfbfea10)                 = -1 (errno 4)
select(29, [?], NULL, NULL, NULL^C <unfinished ...>
Process 890 detached

Boa sorte - conte-nos o que você descobriu! Depois de identificar o processo, poderei ajudar mais.

EDITAR: observe que a execução de lsof , truss e strace pode ser intensiva. Fiz algumas pequenas atualizações para tentar reduzir seu impacto. Além disso, se um processo estiver gerando muitos filhos rapidamente, talvez seja necessário informar truss ou strace para seguir processos filhos com o argumento -f .

    
por 10.12.2011 / 20:50
1

Após algum tempo, encontrei o problema real . Como eu pensei no último comentário, foi um problema de falta de memória.

O culpado foi servidor ZEO para ZODB . Estava confiando muito no cache de IO do disco do sistema, e ele saiu pela culatra, quando a memória livre era menor que 500 MB ele começou a desacelerar e em 300 MB ele acabou de usar o disco tanto, que o sistema parou de responder, e até mesmo alguns serviços começaram a funcionar (como sshd ).

Depois de alterar a estrutura do cache e liberar até 2 GB de memória livre, o problema foi resolvido.

    
por 27.03.2012 / 19:07