зачем менять статус Mysql на Failed каждые несколько часов

#mysql #linux #server #buffer

#mysql #linux #сервер #буфер

Вопрос:

Статус Mysql выходит из строя каждые несколько часов, я также проверил размер буфера, никаких проблем с ними нет, и с помощью приведенной ниже команды отображается следующее сообщение:

systemctl статус mysqld

 ● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Wed 2020-12-02 17:05:42 EST; 8h ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 25565 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE)
  Process: 25543 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 17582 (code=killed, signal=KILL)

Dec 02 17:05:42 test.local systemd[1]: Failed to start MySQL Server.
Dec 02 17:05:42 test.local systemd[1]: Unit mysqld.service entered failed state.
Dec 02 17:05:42 test.local systemd[1]: mysqld.service failed.
Dec 02 17:05:42 test.local systemd[1]: mysqld.service holdoff time over, scheduling restart.
Dec 02 17:05:42 test.local systemd[1]: Stopped MySQL Server.
Dec 02 17:05:42 test.local systemd[1]: start request repeated too quickly for mysqld.service
Dec 02 17:05:42 test.local systemd[1]: Failed to start MySQL Server.
Dec 02 17:05:42 test.local systemd[1]: Unit mysqld.service entered failed state.
Dec 02 17:05:42 test.local systemd[1]: mysqld.service failed.
 

Я также проверил файл журнала, и произошло следующее событие:

 2020-12-02T22:05:42.179677Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation $2020-12-02T22:05:42.184072Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.31) starting as process 25570 ...
2020-12-02T22:05:42.204497Z 0 [Note] InnoDB: PUNCH HOLE support available
2020-12-02T22:05:42.204557Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-12-02T22:05:42.204565Z 0 [Note] InnoDB: Uses event mutexes
2020-12-02T22:05:42.204574Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2020-12-02T22:05:42.204579Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-12-02T22:05:42.204584Z 0 [Note] InnoDB: Using Linux native AIO
2020-12-02T22:05:42.204998Z 0 [Note] InnoDB: Number of pools: 1
2020-12-02T22:05:42.205184Z 0 [Note] InnoDB: Using CPU crc32 instructions
2020-12-02T22:05:42.208098Z 0 [Note] InnoDB: Initializing buffer pool, total size = 6G, instances = 8, chunk size = 128M
2020-12-02T22:05:42.443914Z 0 [ERROR] InnoDB: mmap(137428992 bytes) failed; errno 12
2020-12-02T22:05:42.510301Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2020-12-02T22:05:42.510359Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2020-12-02T22:05:42.510376Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2020-12-02T22:05:42.510384Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2020-12-02T22:05:42.510391Z 0 [ERROR] Failed to initialize builtin plugins.
2020-12-02T22:05:42.510399Z 0 [ERROR] Aborting

2020-12-02T22:05:42.510438Z 0 [Note] Binlog end
2020-12-02T22:05:42.510525Z 0 [Note] Shutting down plugin 'CSV'
2020-12-02T22:05:42.511922Z 0 [Note] /usr/sbin/mysqld: Shutdown complete
 

также My.cf файл:

 [mysqld]
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock



symbolic-links=0
innodb_file_per_table = 1
myisam_sort_buffer_size = 64M
read_rnd_buffer_size = 1024K
net_buffer_length = 8K
read_buffer_size = 1024K
sort_buffer_size = 1024K
table_open_cache = 64
max_allowed_packet = 2M
key_buffer_size = 64M
innodb_buffer_pool_size = 6024M



log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
 

Я протестировал этот проект на сервере с 2 ГБ оперативной памяти, но он потерпел неудачу на сервере с 8 ГБ оперативной памяти.

Комментарии:

1. perror 12 -> OS error code 12: Cannot allocate memory . У вас закончилась память. Уменьшите выделение или установите больше памяти.

2. Я тестировал этот проект на сервере с 2 ГБ ОЗУ, но он не удался на сервере с 8 ГБ ОЗУ.

3. Это не обязательно несовместимо без нехватки памяти. Вероятно, потому, что на вашем тестовом сервере вы не использовали весь выделенный пул буферов. Как правило, в Linux вы можете выделить больше памяти, чем у вас есть на самом деле. Однако несколько часов производственного использования используют его, и в этот момент оом убивает ваш процесс (проверьте dmesg ).

Ответ №1:

Рассмотрите эти изменения в своем разделе my.cnf [mysqld]

 innodb_buffer_pool_size=4G
 

и УДАЛИТЕ, чтобы разрешить работу по умолчанию для повышения производительности

 read_rnd_buffer_size
read_buffer_size
sort_buffer_size
 

чтобы уменьшить объем оперативной памяти.

Дополнительные предложения см. в разделе «Мой профиль», «Профиль сети» для получения контактной информации и бесплатных загружаемых скриптов утилит для помощи в настройке производительности.

Комментарии:

1. @samad Когда у вас будет достаточно очков репутации, если какие-либо комментарии или ответы были для вас ценными, пожалуйста, поддержите или примите для обратной связи людей, пытающихся вам помочь.

2. Сократите свой innodb_buffer_pool_size до 2G, пока вы не сможете работать стабильно и получать больше оперативной памяти.

3. @samad Вы удалили 3 строки из своей конфигурации, перечисленные в моем ответе от 4 декабря 20 в 11:50? Вы все еще терпите неудачу каждые несколько часов?

4. @wilson-hauk, спасибо за ваш ответ, но проблема не решена

5. Запрос дополнительной информации. Какие-либо устройства SSD или NVME на хост-сервере MySQL? Сообщение на pastebin.com и делитесь ссылками. Из вашего корня для входа в систему SSH, текстовые результаты: B) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС; после минимум 24 часов безотказной работы C) ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ; D) ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ; E) СТАТУС; G) ПОКАЗАТЬ СТАТУС INNODB ДВИЖКА; И дополнительная очень полезная информация, если она доступна, включает — htop ИЛИ top для наиболее активных приложения, ulimit -a для списка ограничений Linux / Unix, iostat -xm 5 3 для операций ввода-вывода по устройствам и количеству ядер / процессоров, для анализа настройки рабочей нагрузки сервера для предоставления предложений.