Hello,

I have finished reading something similer on the web, why is there a 2GB limit ?

If I can compile the kernel to say eys there is 4GB of memory why can mysql not use 3GB of it ?

For know I have set the limit at 2GB.

Michael

Partha Dutta wrote:
If you are running on a 32 bit operating system, (e.g. Linux) you can not
allocate that much memory for InnoDB.  The max you could allocate would be
2GB, but that would be pushing it.  You also have to account for MyISAM
memory usage (key_buffer_size) and per thread memory allocations as well.

Partha

--
Partha Dutta, Senior Consultant
MySQL Inc, NY, USA, www.mysql.com
Are you MySQL certified? www.mysql.com/certification
-----Original Message-----
From: Michael Gale [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 14, 2005 10:04 PM
To: mysql@lists.mysql.com
Subject: InnnoDb - change innodb_buffer_pool_size ?

Hello,

        I am running mysql 4.0.20 with Innodb and we have upgrade grade the
RAM
in the system from 1GB to 4GB :).

Now If I change the:

innodb_buffer_pool_size

From 500M to 3G the service will not start. I remember reading
something about this before and I believe I need to delete the
ib_logfile* files or something .. and they will get recreated on start up
??

Any help is appreciated :)

Here is my mysql.log output:

050614 19:50:50  mysqld started
050614 19:50:50 Warning: Asked for 196608 thread stack, but got 126976
InnoDB: Fatal error: cannot allocate 3221241856 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 20288332 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=67108864
read_buffer_size=2093056
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections
= 3546735 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8424780
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...
Bogus stack limit or frame pointer, fp=0xbfffeb88,
stack_bottom=0x20386365, thread_stack=126976, aborting backtrace.
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x64207369  is invalid pointer
thd->thread_id=484
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.
050614 19:50:50  mysqld ended


Michael

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to