我目前正在社区版（CE）1.9.X.X上运行Magento商店。
该商店在过去几个月完美运行（我们已于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默认的任何其他内容）：
[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。
答案 0 :(得分：0)
我的问题在于日志记录。一张桌子太大，需要太多时间才能加载。
为了解决我的问题，我在系统»配置»高级»系统»日志中每天清空表log_visitor_online并启用日志清理。
必须启用CRON，否则日志清理将无效，表格仍会继续增加。