Não é possível sincronizar o sistema de arquivos sem reinicializar

1

Estou tendo um problema com um servidor linux. Uma vez por semana, a instância mysql em execução trava e não há como interrompê-la completamente. Se eu matá-lo, ele permanecerá no status de zumbi e o init não colherá seu pid.

O servidor é usado para preparar implantações e algumas ferramentas internas, portanto, não está sob carga pesada. O único processo usado constantemente é o id mysql e por isso acho que é o único processo que sofre com esse problema.

Pesquisei logs do sistema em busca de erros e a única coisa que encontrei foi esse erro (repetido algumas vezes) na saída do dmesg:

[706560.640085] INFO: task mysqld:31965 blocked for more than 120 seconds.
[706560.640198] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[706560.640312] mysqld          D ffff88032fd93f40     0 31965      1 0x00000000
[706560.640317]  ffff880242a27d18 0000000000000086 ffff88031a50dd00 ffff880242a27fd8
[706560.640321]  ffff880242a27fd8 ffff880242a27fd8 ffff88031e549740 ffff88031a50dd00
[706560.640325]  ffff88031a50dd00 ffff88032fd947f8 0000000000000002 ffffffff8112f250
[706560.640328] Call Trace:
[706560.640338]  [<ffffffff8112f250>] ? __lock_page+0x70/0x70
[706560.640344]  [<ffffffff816cb1b9>] schedule+0x29/0x70
[706560.640347]  [<ffffffff816cb28f>] io_schedule+0x8f/0xd0
[706560.640350]  [<ffffffff8112f25e>] sleep_on_page+0xe/0x20
[706560.640353]  [<ffffffff816c9900>] __wait_on_bit+0x60/0x90
[706560.640356]  [<ffffffff8112f390>] wait_on_page_bit+0x80/0x90
[706560.640360]  [<ffffffff8107dce0>] ? autoremove_wake_function+0x40/0x40
[706560.640363]  [<ffffffff8112f891>] filemap_fdatawait_range+0x101/0x190
[706560.640366]  [<ffffffff81130975>] filemap_write_and_wait_range+0x65/0x70
[706560.640371]  [<ffffffff8122e441>] ext4_sync_file+0x71/0x320
[706560.640376]  [<ffffffff811c3e6d>] do_fsync+0x5d/0x90
[706560.640379]  [<ffffffff811c40d0>] sys_fsync+0x10/0x20
[706560.640383]  [<ffffffff816d495d>] system_call_fastpath+0x1a/0x1f

Quando isso acontece, a única maneira de fazer tudo funcionar novamente é uma reinicialização completa, mas, para isso, sou forçado a usar esse comando depois de ter interrompido manualmente todos os processos em execução

echo b > /proc/sysrq-trigger

caso contrário, o processo de reinicialização normal trava para sempre. Eu rastreei o script reboots e descobri que também o processo de reinicialização é interrompido em uma chamada de sincronização, essa em /etc/init.d/sendsigs (estou no ubuntu)

# Flush the kernel I/O buffer before we start to kill
# processes, to make sure the IO of already stopped services to
# not slow down the remaining processes to a point where they
# are accidentily killed with SIGKILL because they did not
# manage to shut down in time.
sync

Tenho quase certeza de que a causa disso é um problema de hardware (o controlador RAID ???) também porque tenho outras duas máquinas com a mesma configuração de hardware e software e elas não sofrem com isso, mas Não consigo encontrar nenhuma dica no syslog ou no dmesg. Eu também instalei os pacotes smartmontools e mcelog, mas nenhum deles relatou nenhum problema.

O que posso fazer para rastrear a causa desse problema?

Hoje aconteceu novamente, aqui está o status do sistema depois de acionar uma reinicialização

init─┬─console-kit-dae───64*[{console-kit-dae}]
     ├─dbus-daemon
     ├─mcelog
     ├─mysqld───{mysqld}
     ├─newrelic-daemon───newrelic-daemon───11*[{newrelic-daemon}]
     ├─ntpd
     ├─polkitd───{polkitd}
     ├─python3
     ├─rpc.idmapd
     ├─rpc.statd
     ├─rpcbind
     ├─sh───rc───S20sendsigs───sync
     ├─smartd
     ├─snmpd
     ├─sshd───sshd───zsh───sudo───zsh───pstree
     └─sshd───sshd───zsh───sudo───zsh

E aqui está o status do processo de sincronização

# ps aux | grep sync
root      3637  0.1  0.0   4352   372 ?        D    05:53   0:00 sync

i.e. Sono ininterrupto ...

Especificações de hardware conforme relatado por lshw

Eu acho que o controle RAID é um ataque falso. Eu normalmente não ligo com hardware (e para o registro eu não tenho acesso físico a ele)

description: Computer
product: X7DBP ()
vendor: Supermicro
version: 0123456789
serial: 0123456789
width: 64 bits
capabilities: smbios-2.4 dmi-2.4 vsyscall32
configuration: administrator_password=disabled boot=normal frontpanel_password=unknown keyboard_password=unknown power-on_password=disabled uuid=53D19F64-D663-A017-8922-0030487C1FEE
*-core
   description: Motherboard
   product: X7DBP
   vendor: Supermicro
   physical id: 0
   version: PCB Version
   serial: 0123456789
 *-firmware
      description: BIOS
      vendor: Phoenix Technologies LTD
      physical id: 0
      version: 6.00
      date: 05/29/2007
      size: 106KiB
      capacity: 960KiB
      capabilities: pci pnp upgrade shadowing escd cdboot bootselect edd int13floppy2880 acpi usb ls120boot zipboot biosbootspecification

  *-storage
         description: RAID bus controller
         product: 631xESB/632xESB SATA RAID Controller
         vendor: Intel Corporation
         physical id: 1f.2
         bus info: pci@0000:00:1f.2
         version: 09
         width: 32 bits
         clock: 66MHz
         capabilities: storage pm bus_master cap_list
         configuration: driver=ahci latency=0
         resources: irq:19 ioport:18a0(size=8) ioport:1874(size=4) ioport:1878(size=8) ioport:1870(size=4) ioport:1880(size=32) memory:d8500400-d85007ff
    
por Fabio 29.07.2013 / 18:38

1 resposta

3

O estado do seu processo é D , o que tecnicamente significa suspensão ininterrupta. Embora, como sempre digo, D significa disco. Processos nesse estado estão aguardando a conclusão de uma operação de E / S de disco.

Podemos ver no seu rastreamento de chamada que mysqld estava tentando sync e ficou preso por mais de 120 segundos aguardando a sincronização ser concluída.

Isso indica que algo está errado com seu subsistema de armazenamento. Você deve examinar seus discos rígidos e o controlador de disco (se houver discos locais) ou rede e SAN (se armazenamento remoto).

    
por 02.08.2013 / 15:06