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，不崩溃才怪咧。。。

1. InnoDB: Fatal error: cannot allocate 196608 bytes of
2. InnoDB: memory with malloc! Total allocated memory
3. InnoDB: by InnoDB 2307421120 bytes. Operating system errno: 12
4. InnoDB: Cannot continue operation!
5. InnoDB: Check if you should increase the swap file or
6. InnoDB: ulimits of your operating system.
7. InnoDB: On FreeBSD check you have compiled the OS with
8. InnoDB: a big enough maximum process size.
9. InnoDB: We now intentionally generate a seg fault so that
10. InnoDB: on Linux we get a stack trace.
11. mysqld got signal 11;
12. This could be because you hit a bug. It is also possible that this binary
13. or one of the libraries it was linked against is corrupt, improperly built,
14. or misconfigured. This error can also be caused by malfunctioning hardware.
15. We will try our best to scrape up some info that will hopefully help diagnose
16. the problem, but since we have already crashed, something is definitely wrong
17. and this may fail.
18. key_buffer_size=402653184
19. read_buffer_size=2093056
20. max_used_connections=167
21. max_connections=600
22. threads_connected=167
23. It is possible that mysqld could use up to
24. key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2340507 K
25. bytes of memory
26. Hope that's ok; if not, decrease some variables in the equation.
27. thd=(nil)
28. Attempting backtrace. You can use the following information to find out
29. where mysqld died. If you see no messages after this, something went
30. terribly wrong...
31. Cannot determine thread, fp=0x2d2aae98, backtrace may not be correct.
32. Stack range sanity check OK, backtrace follows:
33. 0x8101ff5
34. 0x996420
35. (nil)
36. 0x82a0986
37. 0x82648ac
38. 0x81a2249
39. 0x67949b
40. 0x5f942e
41. New value of fp=(nil) failed sanity check, terminating stack trace!
42. Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
43. stack trace is much more helpful in diagnosing the problem, so please do
44. resolve it
45. The manual page at http://www.mysql.com/doc/en/Crashing.html contains
46. information that should help you find out what is causing the crash.
47. Number of processes running now: 0
48. 120419 16:42:05  mysqld restarted
49. 120419 16:42:05  InnoDB: Database was not shut down normally.
50. InnoDB: Starting recovery from log files...
51. InnoDB: Starting log scan based on checkpoint at
52. InnoDB: log sequence number 2391 788299922
53. InnoDB: Doing recovery: scanned up to log sequence number 2391 793542656
54. InnoDB: Doing recovery: scanned up to log sequence number 2391 798785536
55. InnoDB: Doing recovery: scanned up to log sequence number 2391 804028416
56. InnoDB: Doing recovery: scanned up to log sequence number 2391 809271296
57. InnoDB: Doing recovery: scanned up to log sequence number 2391 814514176
58. InnoDB: Doing recovery: scanned up to log sequence number 2391 819757056
59. InnoDB: Doing recovery: scanned up to log sequence number 2391 824999936
60. InnoDB: Doing recovery: scanned up to log sequence number 2391 830242816
61. InnoDB: Doing recovery: scanned up to log sequence number 2391 835485696
62. InnoDB: Doing recovery: scanned up to log sequence number 2391 840728576
63. InnoDB: Doing recovery: scanned up to log sequence number 2391 845971456
64. InnoDB: Doing recovery: scanned up to log sequence number 2391 851214336
65. InnoDB: Doing recovery: scanned up to log sequence number 2391 856457216
66. InnoDB: Doing recovery: scanned up to log sequence number 2391 861700096
67. InnoDB: Doing recovery: scanned up to log sequence number 2391 866942976
68. InnoDB: Doing recovery: scanned up to log sequence number 2391 872185856
69. InnoDB: Doing recovery: scanned up to log sequence number 2391 877428736
70. InnoDB: Doing recovery: scanned up to log sequence number 2391 882671616
71. InnoDB: Doing recovery: scanned up to log sequence number 2391 887914496
72. InnoDB: Doing recovery: scanned up to log sequence number 2391 893157376
73. InnoDB: Doing recovery: scanned up to log sequence number 2391 898400256
74. InnoDB: Doing recovery: scanned up to log sequence number 2391 903643136
75. InnoDB: Doing recovery: scanned up to log sequence number 2391 908886016
76. InnoDB: Doing recovery: scanned up to log sequence number 2391 914128896
77. InnoDB: Doing recovery: scanned up to log sequence number 2391 919371776
78. InnoDB: Doing recovery: scanned up to log sequence number 2391 924614656
79. InnoDB: Doing recovery: scanned up to log sequence number 2391 929389979
80. 120419 16:42:08  InnoDB: Starting an apply batch of log records to the database...
81. 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
82. InnoDB: Apply batch completed
83. InnoDB: Last MySQL binlog file position 0 248513413, file name /data/mysqlbinlog/mysql-bin.1554
84. 120419 16:43:23  InnoDB: Flushing modified pages from the buffer pool...
85. 120419 16:43:59  InnoDB: Started
86. /usr/local/mysql/libexec/mysqld: ready for connections.
87. Version: '4.0.26-log'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution