mysql管理内存溢出_MySQL 内存溢出

MySQL 数据库在启动时遇到致命错误,无法通过 malloc 分配 196608 字节内存,导致操作无法继续。错误信息显示已分配内存达到 2307421120 字节,操作系统 errno 为 12。建议检查交换文件大小和操作系统 ulimit 设置,尤其是在 FreeBSD 上需要确保最大进程大小足够。数据库尝试进行恢复,扫描并应用日志记录,最终成功重启并完成恢复过程。
摘要由CSDN通过智能技术生成

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值