Estou enfrentando uma alta carga de CPU devido ao processo do MySQL. Eu pesquisei para me livrar desse erro, mas não tive sorte.
Eu encontrei soluções no Google como acontecem devido ao pouco espaço em disco, mas na minha máquina o df -f mostrado abaixo. Está apenas 77% cheio.
[root@mydomain log]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
87G 63G 19G 77% /
/dev/sda1 99M 24M 71M 26% /boot
tmpfs 1014M 0 1014M 0% /dev/shm
Peço desculpas pelo inconveniente. Na verdade, movi o grande /var/log/mysqld.log para /var/log/mysqld.log.bak . Agora não há esse erro em /var/log/mysqld.log , conforme publicado abaixo.
[ERROR] /usr/libexec/mysqld: Error writing file '/var/run/mysqld/mysqld.pid' (Errcode: 28)
[ERROR] Can't start server: can't create PID file: No space left on device
[ERROR] /usr/libexec/mysqld: Table './db_name/table_name' is marked as crashed and should be repaired
Agora, /var/log/mysqld.log listas:
[root@mydomain log]# tail -5 /var/log/mysqld.log
130724 08:33:53 mysqld started
130724 8:33:54 InnoDB: Started; log sequence number 0 94462
130724 8:33:54 [Note] /usr/libexec/mysqld: ready for connections.
TOP da saída do comando.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7831 mysql 18 0 179m 64m 4492 S 95.6 3.2 1168:01 mysqld
12231 root 16 0 2592 1328 900 R 1.8 0.1 0:00.13 top
136 root 10 -5 0 0 0 S 1.5 0.0 94:19.68 kswapd0
df -i output do comando:
[root@mydomain log]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/VolGroup00-LogVol00
23298048 1235574 22062474 6% /
/dev/sda1 26104 43 26061 1% /boot
tmpfs 224005 1 224004 1% /dev/shm
Alguém por favor pode me ajudar nisso ??
Para exibir consultas realmente processadas, efetue login no MySQL e digite o seguinte comando:
show processlist
Se nenhuma consulta estiver sendo executada, você poderá usar os seguintes comandos para rastrear o que o servidor está fazendo:
ltrace -p PID # trace library calls
strace -p PID # trace system calls
Seu sistema (como a maioria) provavelmente está usando um tmpfs (sistema de arquivos temporário) para / var / run (veja o caminho no erro).
Experimente o comando df sem nenhum alias:
\df -h
(incluindo a barra invertida). Eu aliasse meu próprio df para não mostrar coisas do tmpfs, mantendo a saída relativamente limpa, mas você precisa ver a saída completa. Você também pode ver quais montagens estão ativas, dando uma olhada em / proc / mounts , mas isso não mostrará o uso e o espaço livres.
Do meu sistema:
xenon-lornix:~> \df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 451G 23G 406G 6% /
udev 10M 0 10M 0% /dev
tmpfs 372M 748K 371M 1% /run
/dev/disk/by-label/xenon 451G 23G 406G 6% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.3G 712K 2.3G 1% /run/shm
Mas espere! você diz ... não há / var / run lá ... Você está correto, vamos ver onde / var / run está na estrutura do arquivo:
xenon-lornix:~> ls -l /var/
total 40,960
# extra stuff deleted for clarity
drwxrwxrwt 5 root root 4,096 Jul 24 16:02 tmp/
lrwxrwxrwx 1 root root 9 Jul 18 18:44 lock -> /run/lock/
lrwxrwxrwx 1 root root 4 Jul 18 18:44 run -> /run/
E tem a resposta: / var / run é um link simbólico para / run , que está em um sistema de arquivos tmpfs 372Meg.
tmpfs 372M 748K 371M 1% /run
Dê uma olhada em / run , eu imagino que tem algum lixo que está comendo o espaço. Não, eu não recomendo mudar o tamanho, isso não resolve o problema, apenas coloca um band-aid nele. Descobrir o que está preenchendo / run ... este tamanho padrão funciona para zilhões de outras máquinas, então o que está acontecendo com o seu?
SE você não consegue descobrir o que está comendo o espaço, você pode fazer com que / run seja maior, mas lembre-se de que os compartilhamentos tmpfs ram com processos. É rápido, temporário, mas pode afetar os processos em execução se for muito grande. É atualmente (padrão) definido para 10% do núcleo-RAM (ram físico), este é um tamanho máximo. Mais detalhes podem ser encontrados em / etc / default / tmpfs e no tmpfs (5) manpage. (Sistema Debian, outros tipos podem variar, cheque o tmpfs (5) manpage primeiro para dicas.)
Devido ao tmpfs sendo usado, o conteúdo não é preservado durante a reinicialização, o que significa que a reinicialização deste servidor corrigirá o problema imediatamente. Mas a menos que você descubra por que isso aconteceu, isso pode acontecer novamente. Descubra o que está sendo preenchido / executado (/ var / run).
/ var / lock (/ run / lock) & / var / shm (/ run / shm) são montagens separadas e não relacionadas ao tamanho de / run (/ var / run).
Tags mysql cpu linux disk-space