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
