Назад | Перейти на главную страницу

Сбой MySQL, oom-killer, нехватка памяти, проблемы с настройкой?

Я просто переместил все свои веб-сайты на новый сервер с 4 ГБ ОЗУ. Почти сразу mysql начал давать сбой и в какой-то момент не перезагрузился, что вызвало серьезный сбой (поскольку я не заметил, пока кто-то не указал мне на это).

Вот журнал с удаленными заданиями CRON: http://pastebin.com/9SAUBcFp (apache2 вызвал oom-killer, ошибки нехватки памяти и т. д.)

Ничего в df -h составляет более 4% использования.

Вот вывод команды free -m

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

Вот результат 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

Вот результат 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)

Учитывая приведенные выше «переменные для настройки», я внес следующие изменения в /etc/mysqld/my.cnf:

Добавлена строка: key_buffer_size = 280M
Добавлена строка: innodb_buffer_pool_size = 150M
Без комментариев table_cache и изменил его на 100 (который я буду постоянно увеличивать, пока он не превысит 400)
Изменено значение query_cache_size с 16 млн до 32 млн

Есть ли здесь какие-то вопиющие проблемы, которые я не замечаю, или что-то, что мне следует делать?

Я предполагаю, что ваша проблема на самом деле слишком много клиентов Apache для памяти вашего сервера. Когда вы получаете большой всплеск трафика, процессы Apache в конечном итоге используют всю оперативную память. Это вынуждает ОС начать принудительную подкачку процессов между ними, что, как правило, значительно ухудшает ситуацию. В конце концов ваша память подкачки заканчивается, и ОС убивает все, что считает лучшим ... в данном случае MySQL, поскольку он использует много памяти. Обратите внимание, что увеличение памяти подкачки только отсрочит неизбежный сбой.

Я бы начал с сокращения Apache MAXCLIENTS до более разумного значения, основанного на возможностях вашего сервера. Вы можете сделать приблизительную оценку, запустив top и глядя на RES/SHR столбцы для httpd процессы. Разница между ними примерно в том, сколько использует каждый дочерний процесс. Например, на моих серверах среднее использование памяти на ребенка составляет 40 МБ, и я хочу, чтобы Apache использовал только 3 ГБ, поэтому мои MAXCLIENTS установлено 75 (3000/40). Вы можете немного поиграть с этим значением и некоторыми другими настройками подключения Apache по мере необходимости, чтобы Apache не использовал всю оперативную память и не начал использовать своп.

Вы также можете взглянуть на это с точки зрения того, что вызывает большое количество клиентов Apache. Если это реальный всплеск / всплеск трафика, вам, вероятно, понадобится более крупный сервер или больше серверов, или добавить уровень кеширования, чтобы снизить нагрузку на Apache. Если ваш сервер просто слишком медленный, чтобы обрабатывать нормальное количество входящих запросов, вам нужно уменьшить количество запросов Apache. MAXCLIENTS до уровня, с которым он действительно может справиться без резервного копирования запросов. Или, возможно, есть проблема с сервером, приложением или базой данных, которая приводит к зависанию или зависанию вещей, которые необходимо найти и исправить.

У вас почти нет свопа (256M), в качестве временной меры я бы добавил больше подкачки и отключил подкачку (vm.swappiness), чтобы избежать бесполезного ожидания ввода-вывода. SWAP работает медленно, но может предотвратить сбой ваших PIDS. Кроме того, найдите свои OOM и проверьте временные метки, чтобы увидеть, есть ли регулярные сбои с течением времени. В свое время мне приходилось разбираться с некоторыми плохо созданными задачами cron. Я бы удостоверился, что у вас есть как минимум 2 ГБ подкачки, если у вас <8 ГБ ОЗУ. Как я уже сказал, свопинг замедлит работу, но это лучше, чем сбой БД, потеря транзакций и необходимость проверять / восстанавливать таблицы при запуске.

Казалось бы, логичный вывод - добавить больше памяти.

Кстати, вы никогда не упоминали, что ваши веб-сайты обслуживались с нескольких разных машин на одном или что все веб-сайты работали на старом сервере (сколько памяти). Эта информация была бы ОЧЕНЬ полезной, но я все же думаю, что вам просто нужно больше памяти.