Magento 使 MySQL 每天崩溃 1 或 2 次
Magento make MySQL crash 1 or 2 times every day
我目前运行在社区版 (CE) 1 上创建一个 Magento 商店。9.X.X。
商店完美 运行 过去几个月（我们已于 2014 年 11 月推出网站）。
最近 2-3 周，MySQL 每天都开始崩溃。我已经分析了 Magento 的 SQL 日志，我已经激活了 system.log 和 exceptions.log 以查看是否发生了一些特殊的事情，但是什么都没有...
目前，MySQL 在崩溃时说的是：
150127 14:29:50 mysqld_safe Number of processes running now: 0
150127 14:29:50 mysqld_safe mysqld restarted
2015-01-27 14:29:58 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2015-01-27 14:29:58 11145 [Note] Plugin 'FEDERATED' is disabled.
2015-01-27 14:29:59 7f4395db8720 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2015-01-27 14:29:59 11145 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-01-27 14:29:59 11145 [Note] InnoDB: The InnoDB memory heap is disabled
2015-01-27 14:29:59 11145 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-01-27 14:29:59 11145 [Note] InnoDB: Memory barrier is not used
2015-01-27 14:29:59 11145 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-01-27 14:29:59 11145 [Note] InnoDB: Using Linux native AIO
2015-01-27 14:29:59 11145 [Note] InnoDB: Using CPU crc32 instructions
2015-01-27 14:29:59 11145 [Note] InnoDB: Initializing buffer pool, size = 5.0G
2015-01-27 14:30:24 11145 [Note] InnoDB: Completed initialization of buffer pool
2015-01-27 14:30:24 11145 [ERROR] InnoDB: InnoDB: Unable to allocate memory of size 2147484264.
2015-01-27 14:30:24 7f4395db8720 InnoDB: Assertion failure in thread 139928253728544 in file ha_innodb.cc line 17106
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
19:30:24 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8cd6c5]
/usr/sbin/mysqld(handle_fatal_signal+0x494)[0x661af4]
/lib64/libpthread.so.0(+0xf710)[0x7f439599b710]
/lib64/libc.so.6(gsignal+0x35)[0x7f4394646625]
/lib64/libc.so.6(abort+0x175)[0x7f4394647e05]
/usr/sbin/mysqld[0x9658f3]
/usr/sbin/mysqld[0x9ad927]
/usr/sbin/mysqld[0x9a3083]
/usr/sbin/mysqld[0xa215aa]
/usr/sbin/mysqld[0x96c09d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x5a8458]
/usr/sbin/mysqld[0x6e7aa1]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xbf6)[0x6eb6f6]
/usr/sbin/mysqld[0x59b22d]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x3e5)[0x5a01d5]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f4394632d5d]
/usr/sbin/mysqld[0x5925b5]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
我运行使用 WHM/CPanel 在专用服务器上安装 Magento。
这是我的 my.cnf（自定义 my.cnf，WHM 上 MySQL 的其他默认值）：
[mysqld]
innodb_file_per_table=1
bind-address=127.0.0.1
innodb_buffer_pool_size=5G
open_files_limit=10000
innodb_open_files=300
query_cache_type=1
query_cache_size=1G
query_cache_limit=256M
max_allowed_packet=512M
innodb_additional_mem_pool_size=4096M
innodb_log_buffer_size=2048M
bulk_insert_buffer_size=512M
我真的不知道现在发生了什么。希望有人能帮我跟踪并找到问题所在。
当 MySQL 服务器崩溃时，我收到一封来自服务器的电子邮件：
Time: Wed Jan 28 09:28:45 2015 -0500
1 Min Load Avg: 7.91
5 Min Load Avg: 6.15
15 Min Load Avg: 3.27
Running/Total Processes: 9/398
并且多个脚本使用了 96% 的 CPU :
root 3351 0.0 0.0 76720 5956 ? Ss Jan22 0:31 /usr/local/apache/bin/httpd -k start -DSSL
root 8111 0.0 0.0 79560 10316 ? S 08:16 0:00 \_ /usr/local/cpanel/3rdparty/bin/perl /usr/local/cpanel/bin/leechprotect
nobody 18857 0.0 0.0 77440 6364 ? S 08:48 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32031 96.0 5.1 1812740 1702668 ? R 09:21 7:12 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 21687 0.0 0.0 77420 6216 ? S 08:55 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 27499 0.0 0.0 77568 6360 ? S 09:11 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32707 95.6 3.8 1373164 1259928 ? R 09:23 5:30 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 27937 0.0 0.0 77420 6220 ? S 09:12 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 28499 0.0 0.0 77432 6248 ? S 09:13 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 31897 96.1 5.4 1902860 1793256 ? R 09:20 7:29 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29172 0.0 0.0 77436 6220 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 2873 0.0 0.0 127356 22328 ? R 09:28 0:00 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29201 0.0 0.0 77104 5264 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32215 96.1 4.7 1679356 1568032 ? R 09:21 6:44 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29223 0.0 0.0 77120 5756 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32035 96.2 5.1 1800248 1690280 ? R 09:21 7:12 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29241 0.0 0.0 77432 6224 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 29245 0.0 0.0 77432 6228 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 29247 0.0 0.0 77432 6212 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 31646 96.1 6.1 2126108 2018664 ? R 09:20 8:10 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29257 0.0 0.0 77436 6252 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 29261 0.0 0.0 77112 5748 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 31460 96.1 6.5 2249252 2142760 ? R 09:19 8:30 | \_ /usr/bin/php /home/user/public_html/magento/index.php
谢谢，
santerref.
我的问题是日志记录。一个 table 太大，加载时间太长。
为了解决我的问题，我每天清空 table log_visitor_online 并在 系统 » 配置 » 高级中启用 日志清理 » 系统 » 日志.
必须启用CRON，否则日志清理将不起作用，table仍会继续增加。
我目前运行在社区版 (CE) 1 上创建一个 Magento 商店。9.X.X。
商店完美 运行 过去几个月（我们已于 2014 年 11 月推出网站）。
最近 2-3 周，MySQL 每天都开始崩溃。我已经分析了 Magento 的 SQL 日志，我已经激活了 system.log 和 exceptions.log 以查看是否发生了一些特殊的事情，但是什么都没有...
目前，MySQL 在崩溃时说的是：
150127 14:29:50 mysqld_safe Number of processes running now: 0
150127 14:29:50 mysqld_safe mysqld restarted
2015-01-27 14:29:58 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2015-01-27 14:29:58 11145 [Note] Plugin 'FEDERATED' is disabled.
2015-01-27 14:29:59 7f4395db8720 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2015-01-27 14:29:59 11145 [Note] InnoDB: Using atomics to ref count buffer pool pages
2015-01-27 14:29:59 11145 [Note] InnoDB: The InnoDB memory heap is disabled
2015-01-27 14:29:59 11145 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2015-01-27 14:29:59 11145 [Note] InnoDB: Memory barrier is not used
2015-01-27 14:29:59 11145 [Note] InnoDB: Compressed tables use zlib 1.2.3
2015-01-27 14:29:59 11145 [Note] InnoDB: Using Linux native AIO
2015-01-27 14:29:59 11145 [Note] InnoDB: Using CPU crc32 instructions
2015-01-27 14:29:59 11145 [Note] InnoDB: Initializing buffer pool, size = 5.0G
2015-01-27 14:30:24 11145 [Note] InnoDB: Completed initialization of buffer pool
2015-01-27 14:30:24 11145 [ERROR] InnoDB: InnoDB: Unable to allocate memory of size 2147484264.
2015-01-27 14:30:24 7f4395db8720 InnoDB: Assertion failure in thread 139928253728544 in file ha_innodb.cc line 17106
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
19:30:24 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8cd6c5]
/usr/sbin/mysqld(handle_fatal_signal+0x494)[0x661af4]
/lib64/libpthread.so.0(+0xf710)[0x7f439599b710]
/lib64/libc.so.6(gsignal+0x35)[0x7f4394646625]
/lib64/libc.so.6(abort+0x175)[0x7f4394647e05]
/usr/sbin/mysqld[0x9658f3]
/usr/sbin/mysqld[0x9ad927]
/usr/sbin/mysqld[0x9a3083]
/usr/sbin/mysqld[0xa215aa]
/usr/sbin/mysqld[0x96c09d]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x5a8458]
/usr/sbin/mysqld[0x6e7aa1]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xbf6)[0x6eb6f6]
/usr/sbin/mysqld[0x59b22d]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x3e5)[0x5a01d5]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f4394632d5d]
/usr/sbin/mysqld[0x5925b5]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
我运行使用 WHM/CPanel 在专用服务器上安装 Magento。
这是我的 my.cnf（自定义 my.cnf，WHM 上 MySQL 的其他默认值）：
[mysqld]
innodb_file_per_table=1
bind-address=127.0.0.1
innodb_buffer_pool_size=5G
open_files_limit=10000
innodb_open_files=300
query_cache_type=1
query_cache_size=1G
query_cache_limit=256M
max_allowed_packet=512M
innodb_additional_mem_pool_size=4096M
innodb_log_buffer_size=2048M
bulk_insert_buffer_size=512M
我真的不知道现在发生了什么。希望有人能帮我跟踪并找到问题所在。
当 MySQL 服务器崩溃时，我收到一封来自服务器的电子邮件：
Time: Wed Jan 28 09:28:45 2015 -0500
1 Min Load Avg: 7.91
5 Min Load Avg: 6.15
15 Min Load Avg: 3.27
Running/Total Processes: 9/398
并且多个脚本使用了 96% 的 CPU :
root 3351 0.0 0.0 76720 5956 ? Ss Jan22 0:31 /usr/local/apache/bin/httpd -k start -DSSL
root 8111 0.0 0.0 79560 10316 ? S 08:16 0:00 \_ /usr/local/cpanel/3rdparty/bin/perl /usr/local/cpanel/bin/leechprotect
nobody 18857 0.0 0.0 77440 6364 ? S 08:48 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32031 96.0 5.1 1812740 1702668 ? R 09:21 7:12 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 21687 0.0 0.0 77420 6216 ? S 08:55 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 27499 0.0 0.0 77568 6360 ? S 09:11 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32707 95.6 3.8 1373164 1259928 ? R 09:23 5:30 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 27937 0.0 0.0 77420 6220 ? S 09:12 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 28499 0.0 0.0 77432 6248 ? S 09:13 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 31897 96.1 5.4 1902860 1793256 ? R 09:20 7:29 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29172 0.0 0.0 77436 6220 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 2873 0.0 0.0 127356 22328 ? R 09:28 0:00 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29201 0.0 0.0 77104 5264 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32215 96.1 4.7 1679356 1568032 ? R 09:21 6:44 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29223 0.0 0.0 77120 5756 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 32035 96.2 5.1 1800248 1690280 ? R 09:21 7:12 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29241 0.0 0.0 77432 6224 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 29245 0.0 0.0 77432 6228 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 29247 0.0 0.0 77432 6212 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 31646 96.1 6.1 2126108 2018664 ? R 09:20 8:10 | \_ /usr/bin/php /home/user/public_html/magento/index.php
nobody 29257 0.0 0.0 77436 6252 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody 29261 0.0 0.0 77112 5748 ? S 09:14 0:00 \_ /usr/local/apache/bin/httpd -k start -DSSL
user 31460 96.1 6.5 2249252 2142760 ? R 09:19 8:30 | \_ /usr/bin/php /home/user/public_html/magento/index.php
谢谢， santerref.
我的问题是日志记录。一个 table 太大，加载时间太长。
为了解决我的问题，我每天清空 table log_visitor_online 并在 系统 » 配置 » 高级中启用 日志清理 » 系统 » 日志.
必须启用CRON，否则日志清理将不起作用，table仍会继续增加。