MySQL no Linux sem memória

Question

SO: Servidor Redhat Enterprise Linux Versão 5.3 (Tikanga)

Arquitetura: Intel Xeon 64Bit

Edição avançada do MySQL Server 5.5.20 Enterprise Server.

Aplicação: Liferay.

O tamanho do meu banco de dados é de 200MB. RAM é de 64 GB. O consumo de memória aumenta gradualmente e nós ficamos sem memória . Em seguida, apenas a reinicialização libera toda a memória, mas, em seguida, o processo de consumo de memória é iniciado novamente e atinge 63-64 GB em menos de um dia.

Detalhes dos parâmetros :

key_buffer_size = 16 milhões

innodb_buffer_pool_size = 3 GB

inndb_bufuf_pool_instances = 3

max_connections = 1000

innodb_flush_method = O_DIRECT

innodb_change_buffering = insere

read_buffer_size = 2M

read_rnd_buffer_size = 256K

É um sério problema de servidor de produção que estou enfrentando. Qual poderia ser a razão por trás disso e como resolver.

Este é o relatório das 14h de hoje, depois que o Linux foi reinicializado ontem às 22h.

Saída do livre -m

             total       used       free     shared    buffers     cached
Mem:         64455      22053      42402          0       1544       1164
-/+ buffers/cache:      19343      45112
Swap:        74998          0      74998

Saída do vmstat 2 5

   procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------    
   r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
   0  0      0 43423976 1583700 1086616    0    0     1   173   22   27  1  1 98  0  0
   2  0      0 43280200 1583712 1228636    0    0     0   146 1265  491  2  2 96  1  0
   0  0      0 43421940 1583724 1087160    0    0     0   138 1469  738  2  1 97  0  0
   1  0      0 43422604 1583728 1086736    0    0     0  5816 1615  934  1  1 97  0  0
   0  0      0 43422372 1583732 1086752    0    0     0  2784 1323  545  2  1 97  0  0

Saída do top -n 3 -b

top - 14:16:22 up 16:32,  5 users,  load average: 0.79, 0.77, 0.93
Tasks: 345 total,   1 running, 344 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0%us,  0.9%sy,  0.0%ni, 98.1%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  66002772k total, 22656292k used, 43346480k free,  1582152k buffers
Swap: 76798724k total,        0k used, 76798724k free,  1163616k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                     
 6434 mysql     15   0 4095m 841m 5500 S 113.5  1.3 426:53.69 mysqld                     
    1 root      15   0 10344  680  572 S  0.0  0.0   0:03.09 init                        
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.01 migration/0                 
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0                 
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0                  
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:00.01 migration/1                                               

    

Answer 1

Eu tive um problema parecido, e basicamente mudei o script mysqltuner.pl e o tornei mais detalhado e sei o que aconteceu.

Basicamente, o uso da memória, se você estiver usando qualquer variação do arquivo de configuração my-innodb-heavy-4G.cnf , a maior parte da memória usada será quase assim:

memory usage = min(tmp_table_size, max_heap_table_size) 
    + key_buffer_size + query_cache_size 
    + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size
    + (max_connections * 
        (read_buffer_size + read_rnd_buffer_size 
           + sort_buffer_size + thread_stack + join_buffer_size
        )
    )

Esta soma não tem todos os fatores, por favor, consulte o código de script mysqltuner.pl (e execute-o) para ver todos eles.

Portanto, parece que você precisa diminuir muito read_buffer_size , read_rnd_buffer_size , sort_buffer_size , thread_stack e join_buffer_size , pois sua soma é multiplicada por 1000 de max_connections .

Outra solução é reduzir um pouco o número max_connections . Com essa enorme memória para buffers de thread, innodb_buffer_pool_size e todas as variáveis relacionadas ao InnoDB se tornam um problema menor.

Você também pode tentar descobrir se seus aplicativos realmente são uma grande quantidade de sort_buffer_size e join_buffer_size . Se não, coloque esses valores para baixo.

Espero que tenha ajudado.