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]
