7GB unused/free RAM and innodb cannot allocate even 2GB

B

brimstone

New member
Joined
Mar 14, 2011
Messages
3
Hi there,

My server has 8 GBs of total RAM.

Here's the response for 'free -m -g' (showing free memory in gigs):
total used free shared buffers cached
Mem: 7 0 7 0 0 0
-/+ buffers/cache: 0 7
Swap: 16 0 16

I've also attached a screenshot of munin's memory plugin showing I have 7.4GB 'unused' memory. You'll see the unused blue going up after a certain point - I restarted to make sure all cache/etc was dumped. I'm still getting the error.

In my my.cnf I have:

innodb_data_home_dir = /usr/local/mysql/data
innodb_buffer_pool_size = 2GB
innodb_log_buffer_size = 4M
innodb_log_file_size = 256M
innodb_thread_concurrency = 8


...and this is the error I'm getting:

InnoDB: Error: cannot allocate 2147500032 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 25166072 bytes. Operating system errno: 12
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: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
InnoDB: Fatal error: cannot allocate the memory for the buffer pool

Can anyone guide me into what I should be looking at?

I run 2x the settings on my local computer with 8GB of RAM - and it works perfectly fine. The server has much more unused RAM and storage and yet I'm still getting this error.

Any guidance is much appreciated.
 

Attachments

  • Screen shot 2011-03-14 at 5.06.28 PM.png
    Screen shot 2011-03-14 at 5.06.28 PM.png
    40.6 KB · Views: 238
OS is 32-bit. I'm not trying to allocate more than 4GB, why is it effected?

On that note, here's the output of ulimit -a:

ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 73728
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 73728
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited


----

and there are no custom/user-specific settings in /etc/security/limits.conf
so these ulimit values are good for all users.
 
i know is not refered to your request but, how did u get munin produce that mem output so detailed? there is a specific config?

Thanks and sorry for the off-topic request.

Regarding inno-db, maybe is 32bit limitation, but not sure, what about use a spf kernel?

** found with google **
Code: 
On a system with 64-bit address space (such as AMD64, Intel EM64T, and the 64-bit systems
by Sun, HP and SGI), InnoDB can use more than 4 gigabytes.

On many 32-bit GNU/Linux systems, a process cannot allocate more than 2 gigabytes of
memory, because parts of the address space are reserved for other purposes, such as
program text. On some 32-bit GNU/Linux systems (most notably Red Hat Linux), the limit
has been raised to 3 gigabytes, if I remember correctly.

Regards
 
brimstone said:
OS is 32-bit. I'm not trying to allocate more than 4GB, why is it effected?
Click to expand...

32 bit Linux can malloc (allocate) a max of 3G (1G is reserved for the Kernel), and that is if and only if it can allocate 3 contiguous (no interruptions) Gig of memory. If you server has been running for a while it is quite possible that the memory is fragmented and therefore 2G of contiguous memory isn't available.

If you are running a 32-bit OS, then the max amount of memory the OS can address is only 4G, the rest is ignored, and depending on the chipset, it is possible only 3.5G can be used. A 64-bit OS would be able to address the full 8G (and more) of RAM and increase the odds that you would have more free contiguous memory. It would even allow a 32 bit process to malloc a full 4G of memory if available.
 
Well, I ended up allocating 1GB just to get it to work for now.

I found an equation that says the total amount of memory needed for mysql would be a combination of sort cache, read cache, max connections allowed, key buffer size, etc... when I took into consideration all the numbers, it added up to ~3.96GB.

BTW, I did restart the whole server before I got those values.

The smartest thing to do would be to move to a 64-bit version of Debian to avoid this issue.

Thinking back on it, why am I using the 32-bit anyway? I guess I need to make sure there's a 64bit version for the software I'm using but I don't use too many non-mainstream packages, should be fine.

OT: It's the default munin memory plugin btw, nothing special done.
 
Never done myself, but I've met some information, that it's still possible to live migrate from 32bit to 64bit, without need to format disks.
 
i had read something about this too but wasnt encouraged as operation.

And smp kernel allow to see multiprocessor and 4+gb of ram , so, thats why i suggest this.

When i was using debian for directadmin i always had use debian32 with smp kernel cause i wasnt sure about total compatibility between directadmin and debian64.

And now im on centos 64 cause i still dont like so much the debian 64
 
The best solution reload the OS into 64 bit . That will solve the issue . 32 bit won't allocate more than 2 GB for mysql . You may better to google the same issue .
 
You must log in or register to reply here.
Back
Top