Mysql travando, oom-killer, falta de memória, problemas de ajuste?

Question

Acabei de migrar todos os meus sites para um novo servidor com 4 GB de RAM. Quase imediatamente, o mysql começou a travar, e em um ponto, não reiniciou o que causou uma grande falha (desde que eu não percebi até que alguém apontou para mim).

Aqui está o log com trabalhos CRON retirados: link (apache2 invocou oom-killer, erros de falta de memória, etc.)

Nada em df -h tem mais de 4% de uso.

Aqui está uma saída de free -m

             total       used       free     shared    buffers     cached
Mem:          4002       2090       1911          0        168       1015
-/+ buffers/cache:        906       3095
Swap:          255          8        247

Aqui está uma saída do mysqlreport

__ Key _________________________________________________________________
Buffer used   849.00k of  16.00M  %Used:   5.18
  Current       2.99M            %Usage:  18.71
Write hit      44.87%
Read hit       98.84%

__ Questions ___________________________________________________________
Total         198.55k    33.8/s
  QC Hits     147.94k    25.1/s  %Total:  74.51
  DMS          31.35k     5.3/s           15.79
  Com_         14.20k     2.4/s            7.15
  COM_QUIT      5.07k     0.9/s            2.55
  -Unknown          9     0.0/s            0.00
Slow 2 s            0       0/s            0.00  %DMS:   0.00  Log:  ON
DMS            31.35k     5.3/s           15.79
  SELECT       27.65k     4.7/s           13.93         88.19
  UPDATE        1.78k     0.3/s            0.89          5.66
  INSERT        1.73k     0.3/s            0.87          5.51
  DELETE          199     0.0/s            0.10          0.63
  REPLACE           0       0/s            0.00          0.00
Com_           14.20k     2.4/s            7.15
  set_option    9.29k     1.6/s            4.68
  change_db     4.63k     0.8/s            2.33
  show_tables     260     0.0/s            0.13

__ SELECT and Sort _____________________________________________________
Scan              850     0.1/s %SELECT:   3.07
Range             398     0.1/s            1.44
Full join           0       0/s            0.00
Range check         0       0/s            0.00
Full rng join       0       0/s            0.00
Sort scan       1.01k     0.2/s
Sort range        361     0.1/s
Sort mrg pass       0       0/s

__ Query Cache _________________________________________________________
Memory usage   15.09M of  16.00M  %Used:  94.30
Block Fragmnt   2.31%
Hits          147.94k    25.1/s
Inserts        21.70k     3.7/s
Insrt:Prune    2.86:1     2.4/s
Hit:Insert     6.82:1

__ Table Locks _________________________________________________________
Waited              0       0/s  %Total:   0.00
Immediate      35.51k     6.0/s

__ Tables ______________________________________________________________
Open              400 of  400    %Cache: 100.00
Opened          5.55k     0.9/s

__ Connections _________________________________________________________
Max used            9 of  151      %Max:   5.96
Total           5.07k     0.9/s

__ Created Temp ________________________________________________________
Disk table        554     0.1/s
Table           1.61k     0.3/s    Size:  16.0M
File                6     0.0/s

__ Threads _____________________________________________________________
Running             1 of    1
Cached              7 of    8      %Hit:  99.82
Created             9     0.0/s
Slow                0       0/s

__ Aborted _____________________________________________________________
Clients             0       0/s
Connects            5     0.0/s

__ Bytes _______________________________________________________________
Sent            3.57G  607.2k/s
Received       34.01M    5.8k/s

__ InnoDB Buffer Pool __________________________________________________
Usage          98.28M of 127.98M  %Used:  76.79
Read hit       99.98%
Pages
  Free          1.90k            %Total:  23.21
  Data          5.61k                     68.50 %Drty:   0.00
  Misc            679                      8.29
  Latched           0                      0.00
Reads          21.60M    3.7k/s
  From file     4.62k     0.8/s            0.02
  Ahead Rnd         0       0/s
  Ahead Sql                 0/s
Writes         10.83k     1.8/s
Flushes         5.27k     0.9/s
Wait Free           0       0/s

__ InnoDB Lock _________________________________________________________
Waits               0       0/s
Current             0
Time acquiring
  Total             0 ms
  Average           0 ms
  Max               0 ms

__ InnoDB Data, Pages, Rows ____________________________________________
Data
  Reads         5.57k     0.9/s
  Writes        7.95k     1.4/s
  fsync         3.10k     0.5/s
  Pending
    Reads           0
    Writes          0
    fsync           0

Pages
  Created          48     0.0/s
  Read          5.56k     0.9/s
  Written       5.27k     0.9/s

Rows
  Deleted         190     0.0/s
  Inserted        242     0.0/s
  Read          7.47M    1.3k/s
  Updated       1.36k     0.2/s

Aqui está uma saída do mysqltuner

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.35-0+wheezy1-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 1005M (Tables: 335)
[--] Data in InnoDB tables: 143M (Tables: 68)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 76

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 28m 55s (154K q [28.899 qps], 4K conn, TX: 3B, RX: 25M)
[--] Reads / Writes: 83% / 17%
[--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 597.8M (14% of installed RAM)
[OK] Slow queries: 0% (0/154K)
[OK] Highest usage of available connections: 5% (9/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/264.4M
[OK] Key buffer hit rate: 98.8% (77K cached / 912 reads)
[OK] Query cache efficiency: 87.2% (116K cached / 133K selects)
[!!] Query cache prunes per day: 5182
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[OK] Temporary tables created on disk: 24% (427 on disk / 1K total)
[OK] Thread cache hit rate: 99% (9 created / 4K connections)
[!!] Table cache hit rate: 9% (400 open / 4K opened)
[OK] Open file limit used: 61% (631/1K)
[OK] Table locks acquired immediately: 100% (18K immediate / 18K locks)
[!!] InnoDB data size / buffer pool: 143.3M/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (> 16M)
    table_cache (> 400)
    innodb_buffer_pool_size (>= 143M)

Dadas as "Variáveis para ajustar" acima, fiz as seguintes alterações em /etc/mysqld/my.cnf:

• Linha adicionada: key_buffer_size = 280M
• Linha adicionada: innodb_buffer_pool_size = 150M
• table_cache não-comentado e alterado para 100 (que aumentarei continuamente até ultrapassar 400)
• Alterou o valor de query_cache_size de 16M para 32M

Há algum problema gritante aqui que eu esteja negligenciando ou algo que eu deveria estar fazendo?

    

Answer 1

Você dificilmente tem qualquer swap (256M), como uma medida temporária, eu adicionaria mais swap e tornaria o swappiness (vm.swappiness) inativo, de modo a evitar espera de E / S inútil. O SWAP é lento, mas pode impedir que o seu PIDS colida. Além disso, ganhe o seu OOM e verifique os timestamps para ver se há alguma regularidade com as falhas ao longo do tempo. Eu tive que investigar através de alguns cron jobs mal trabalhados no meu tempo. Eu teria certeza de ter pelo menos 2GB de swap se você tiver < 8 GB de RAM. Como eu disse, a troca irá atrasar as coisas, mas é melhor do que travar o banco de dados e perder transações e ter que verificar / reparar as tabelas na inicialização.

    

Answer 2

Parece ser a conclusão lógica para adicionar mais memória.

BTW, você nunca mencionou se consolava seus sites de várias máquinas diferentes para um ou que todos os sites eram executados em um servidor antigo (de quanta memória). Esta informação seria muito útil, no entanto, eu ainda acho que você só precisa de mais memória.

    

Answer 3

Eu acho que seu problema é na verdade muitos clientes Apache para a memória do seu servidor. Quando você recebe um grande surto de tráfego, os processos do Apache se acumulam eventualmente usando toda a RAM. Isso força o sistema operacional a começar a forçar a entrada e a saída de processos, o que tende a piorar as coisas. Eventualmente, sua memória swap se esgota e o SO mata qualquer coisa que ache melhor ... neste caso, o MySQL, já que ele usa muita memória. Note que aumentar a memória swap apenas atrasará a queda inevitável.

Eu começaria reduzindo o MAXCLIENTS do Apache para um valor mais razoável com base na capacidade do seu servidor. Você pode fazer uma estimativa aproximada executando top e observando as colunas RES/SHR dos processos httpd . A diferença entre eles é aproximadamente o quanto cada processo filho usa. Por exemplo, em meus servidores, o uso médio de memória por filho é de 40 MB e eu quero que o Apache use apenas 3 GB, então meu MAXCLIENTS está definido para 75 (3000/40). Você pode jogar com este valor e algumas das outras configurações de conexão do Apache um pouco, conforme necessário, para evitar que o Apache use toda a RAM e comece a bater na troca.

Você também pode ver isso do ponto de vista do que está causando o grande número de clientes Apache. Se for um surto / pico real de tráfego, é provável que você precise de um servidor maior ou de mais servidores ou adicione uma camada de cache para diminuir a carga no Apache. Se o seu servidor for muito lento para lidar com o número normal de solicitações de entrada, você vai querer diminuir o MAXCLIENTS do Apache para um nível que ele consiga manipular sem fazer o backup das solicitações. Ou talvez haja um problema no servidor, no aplicativo ou no banco de dados que esteja causando o bloqueio ou o congelamento de itens que precisam ser localizados e corrigidos.