MySQL 内存溢出

 select EVENT_NAME ,SUM_NUMBER_OF_BYTES_ALLOC from memory_summary_global_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10;

memory_summary_by_account_by_event_name |
| memory_summary_by_host_by_event_name |
| memory_summary_by_thread_by_event_name |
| memory_summary_by_user_by_event_name |
| memory_summary_global_by_event_name

首先是程序报错：

ERROR 1135: Can't create a new thread (errno 12). If you are not out of available memory, you can consult the manual for a possible OS-dependent bug

查看日志：key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =2340507 K

配置文件中 innodb_buffer_pool_size = 2G，在32位操作系统下 mysql 的内存超过了4GB，不崩溃才怪咧。。。

InnoDB: Fatal error: cannot allocate 196608 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 2307421120 bytes. Operating system errno: 12
InnoDB: Cannot continue operation!
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: We now intentionally generate a seg fault so that
InnoDB: on Linux we get a stack trace.
mysqld got signal 11;
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=402653184
read_buffer_size=2093056
max_used_connections=167
max_connections=600
threads_connected=167
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2340507 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
Cannot determine thread, fp=0x2d2aae98, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8101ff5
0x996420
(nil)
0x82a0986
0x82648ac
0x81a2249
0x67949b
0x5f942e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
120419 16:42:05  mysqld restarted
120419 16:42:05  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 2391 788299922
InnoDB: Doing recovery: scanned up to log sequence number 2391 793542656
InnoDB: Doing recovery: scanned up to log sequence number 2391 798785536
InnoDB: Doing recovery: scanned up to log sequence number 2391 804028416
InnoDB: Doing recovery: scanned up to log sequence number 2391 809271296
InnoDB: Doing recovery: scanned up to log sequence number 2391 814514176
InnoDB: Doing recovery: scanned up to log sequence number 2391 819757056
InnoDB: Doing recovery: scanned up to log sequence number 2391 824999936
InnoDB: Doing recovery: scanned up to log sequence number 2391 830242816
InnoDB: Doing recovery: scanned up to log sequence number 2391 835485696
InnoDB: Doing recovery: scanned up to log sequence number 2391 840728576
InnoDB: Doing recovery: scanned up to log sequence number 2391 845971456
InnoDB: Doing recovery: scanned up to log sequence number 2391 851214336
InnoDB: Doing recovery: scanned up to log sequence number 2391 856457216
InnoDB: Doing recovery: scanned up to log sequence number 2391 861700096
InnoDB: Doing recovery: scanned up to log sequence number 2391 866942976
InnoDB: Doing recovery: scanned up to log sequence number 2391 872185856
InnoDB: Doing recovery: scanned up to log sequence number 2391 877428736
InnoDB: Doing recovery: scanned up to log sequence number 2391 882671616
InnoDB: Doing recovery: scanned up to log sequence number 2391 887914496
InnoDB: Doing recovery: scanned up to log sequence number 2391 893157376
InnoDB: Doing recovery: scanned up to log sequence number 2391 898400256
InnoDB: Doing recovery: scanned up to log sequence number 2391 903643136
InnoDB: Doing recovery: scanned up to log sequence number 2391 908886016
InnoDB: Doing recovery: scanned up to log sequence number 2391 914128896
InnoDB: Doing recovery: scanned up to log sequence number 2391 919371776
InnoDB: Doing recovery: scanned up to log sequence number 2391 924614656
InnoDB: Doing recovery: scanned up to log sequence number 2391 929389979
120419 16:42:08  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 248513413, file name /data/mysqlbinlog/mysql-bin.1554
120419 16:43:23  InnoDB: Flushing modified pages from the buffer pool...
120419 16:43:59  InnoDB: Started
/usr/local/mysql/libexec/mysqld: ready for connections.
Version: '4.0.26-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution