Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I currently have innodb_buffer_size set to 2GB - yet I have well over 5GB of innodb databases, and another 4 gigs of free ram on the server (Centos 5). I tried to increase the value to 3 gig, but MySQL refuses to launch after I make the change. I tried lowering it just for kicks, and mysql seems to load fine.

Any ideas as to why this is happening?

The MySQL error log shows the following:

110615 08:17:37  mysqld started
110615  8:17:37 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
110615  8:17:37 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
110615  8:17:37  InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
110615  8:17:42  InnoDB: We now intentionally generate a seg fault so that
InnoDB: on Linux we get a stack trace.
110615  8:17:42 - 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=0
read_buffer_size=131072
max_used_connections=0
max_connections=30
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 65279 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=0xbfc96c58, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x818d638
0x843f4e8
0x843f631
0x843c7de
0x83f4125
0x83f7efb
0x8351202
0x825e466
0x824d496
0x818c626
0x818fe9a
0xb7b29e9c
0x80fbd91
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://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
110615 08:17:42  mysqld ended

110615  8:17:43  InnoDB: Started; log sequence number 9 357374494
^G/usr/libexec/mysqld: Out of memory (Needed 475054080 bytes)
110615  8:17:43 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.77-log'  socket: '/var/lib/mysql/mysql.sock'  port: 0  Source distribution

My My.CNF file contains the following:

[mysqld]
bind-address = 127.0.0.1
skip-networking
log-slow-queries
log-slow-admin-statements
engine-condition-pushdown
open-files-limit=2048
max_allowed_packet = 50M

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql

innodb_buffer_pool_size=2048M
innodb_log_file_size=512M
innodb_log_buffer_size=4M
innodb_flush_log_at_trx_commit=2
innodb_thread_concurrency=8
innodb_flush_method=O_DIRECT
innodb_file_per_table

max_connections=30
table_cache=500
max_delayed_threads=20
max_tmp_tables=32
tmp_table_size=64M
max_heap_table_size=64M

query-cache-type = 1
query-cache-size = 20M
query_cache_limit=8388608
thread_cache_size=15
key_buffer_size=512M

long_query_time=1
join_buffer_size=2M
low_priority_updates=1
concurrent_insert=2

UPDATE: Just answered my own question. Turns out the machine is running 32bit kernel for some reason. MySQL therefore can’t use all available RAM, because it runs in a single process, which is limited to about 2.5GB of memory.

share|improve this question
1  
Are you running on a 32 bit system? –  Chris Jun 15 '11 at 12:43
    
Not sure if you are hitting a memory limit for your box but I used this blog post a while back to size some of our MySQL server configs: mysqlperformanceblog.com/2006/05/30/innodb-memory-usage –  Chris Jun 15 '11 at 13:02
    
There seems to be lots of ram available though when I check with free -m: total:7955 used:3571 free:4384 –  Professor Frink Jun 15 '11 at 13:09
    
In the stack backtrace are only 32-Bit numbers? Shouldn't they be 64 Bit? –  Turbo J Jun 15 '11 at 13:52
    
hmm... it looks like the kernel may be 32bit as uname -m returns 'i686' - I don't know why the server was setup with a 32bit kernel though, considering its function. Is the 2048 innodb memory limit a function of a 32bit kernel? –  Professor Frink Jun 15 '11 at 14:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.