MySQL продолжает давать сбой на моем сервере. У меня несколько десятков сайтов, использующих VestaCP, и у меня уже несколько месяцев не было проблем с MySQL.
Я использую Linode VPS с 12 ГБ оперативной памяти, обычно 9 ГБ бесплатно.
Журнал ошибок MySQL выглядит так:
160711 22:32:36 [Note] Plugin 'FEDERATED' is disabled.
160711 22:32:36 InnoDB: The InnoDB memory heap is disabled
160711 22:32:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160711 22:32:36 InnoDB: Compressed tables use zlib 1.2.8
160711 22:32:36 InnoDB: Using Linux native AIO
160711 22:32:39 InnoDB: Initializing buffer pool, size = 1.0G
InnoDB: mmap(1098907648 bytes) failed; errno 12
160711 22:32:39 InnoDB: Completed initialization of buffer pool
160711 22:32:39 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160711 22:32:39 [ERROR] Plugin 'InnoDB' init function returned error.
160711 22:32:39 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160711 22:32:39 [ERROR] Unknown/unsupported storage engine: InnoDB
160711 22:32:39 [ERROR] Aborting
160711 22:32:39 [Note] /usr/sbin/mysqld: Shutdown complete
160711 22:33:43 [Note] Plugin 'FEDERATED' is disabled.
160711 22:33:43 InnoDB: The InnoDB memory heap is disabled
160711 22:33:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160711 22:33:43 InnoDB: Compressed tables use zlib 1.2.8
160711 22:33:43 InnoDB: Using Linux native AIO
160711 22:33:43 InnoDB: Initializing buffer pool, size = 1.0G
160711 22:33:43 InnoDB: Completed initialization of buffer pool
160711 22:33:43 InnoDB: highest supported file format is Barracuda.
Этот конкретный набор ошибок, кажется, происходит после выдачи service mysql restart команда.
Я потратил много времени на изучение этой конкретной ошибки: Fatal error: cannot allocate memory for the buffer pool. Все, что я обнаружил, указывает на то, что проблема заключается в отсутствии оперативной памяти, большинство людей, имевших это, были на системах с чрезвычайно низким объемом памяти (обычно 512 МБ или около того). Очевидно, что при 12 ГБ оперативной памяти и 9 ГБ свободной памяти не должно быть проблем с нехваткой оперативной памяти, поэтому я не уверен, что делать в этом случае.
Бег free -h дает следующие результаты:
Результаты командной строки free -h Кроме того, в файлах журнала есть ТОННА записей, которые выглядят следующим образом:
160711 22:31:58 [Warning] Aborted connection 5131 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:31:58 [Warning] Aborted connection 5127 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:00 [Warning] Aborted connection 5136 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5134 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5133 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5112 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:01 [Warning] Aborted connection 5135 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:04 [Warning] Aborted connection 5137 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
160711 22:32:05 [Warning] Aborted connection 5140 to db: 'xxxx' user: 'xxxx' host: 'localhost' (Got timeout reading communication packets)
Наконец, я попытался увеличить размер пула буферов InnoDB с 512 МБ до 1 ГБ, и это, похоже, не помогло. Я просто увеличиваю размер буферного пула, пока он не перестанет давать сбой?
Изменить: Спасибо за ответы! Вот мой текущий my.cnf:
[client]
port=3306
socket=/var/run/mysqld/mysqld.sock
[mysqld_safe]
socket=/var/run/mysqld/mysqld.sock
[mysqld]
user=mysql
pid-file=/var/run/mysqld/mysqld.pid
socket=/var/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
log-warning=2
tmpdir=/tmp
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log
#skip-networking
symbolic-links=0
skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 256M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
#innodb_use_native_aio = 0
innodb_file_per_table
max_connections=1500
max_user_connections=200
wait_timeout=10
interactive_timeout=50
long_query_time=5
innodb_log_buffer_size = 32M
innodb_buffer_pool_size = 1024M
innodb_log_file_size = 768M
!includedir /etc/mysql/conf.d/
InnoDB / MySQL по какой-то причине не может выделить 1 ГБ. В то же время free -h показывает немного свободной памяти. Это означает, что что-то внутри mysql или вне mysql выделяет память. Приведенный выше my.cnf не показывает никакого дополнительного выделения памяти, но у вас есть это include: "! Includedir /etc/mysql/conf.d/" Пожалуйста, проверьте содержимое этого каталога и посмотрите, есть ли другие файлы (кроме debian .cnf - это просто пароли), у которых есть некоторые параметры конфигурации. Вы также можете попробовать запустить MySQL и посмотреть "сверху" и проверить, как растет виртуальная память.
Другие возможности:
Ваш буферный пул innodb слишком мал. Вам нужно увеличить его и еще 4 параметра innodb. По сути, вы указываете движку innodb в конфигурации mysql, сколько оперативной памяти он получает. Предположительно, это сделано для того, чтобы с вашими данными не происходили ужасные вещи, если у машины закончится оперативная память.
Если у вас много таблиц innodb, сделайте пул буферов действительно очень большим, например, в идеале он может быть размером всех ваших обычно используемых данных innodb. Поскольку у меня нет конфигурации mysql, которую я сделал для моей последней работы, я забыл обо всех параметрах конфигурации innodb_.