Dobromir, As I said in my first message (see the message quoted below), MySQL could use up to 4.991913 G of memory. So you could use more than 4GB. Check out the calculation below. Also read the rest of my message, regarding thread size, the manual page for crashing, max_connections, slow query logs, and disk partitions. You haven't indicated that you've done any of what I mentioned, and you might be using more than 4G anyway.
-Sheeri On 5/8/06, Dobromir Velev <[EMAIL PROTECTED]> wrote:
Hi, I'm aware of the fact that this is a 32 bit system - and I've tried to make sure that mysqld will not use more than 4 GB. As you can see the innodb_buffer_pool_size is 2 Gb and the total amount of memory used by the MyISAM key buffer size and the per thread variables is less then 2 GB. There are no other services on this machine so the memory should not be a problem. This server was working fine for almost a year until recently it started crashing. Could it be some memory problem I've ran into and can you suggest anything I can do to avoid similar problems in the future. Thanks Dobromir Velev On Saturday 06 May 2006 01:23, Heikki Tuuri wrote: > Dobromir, > > you are running a 32-bit operating system. Then the size of the mysqld > process is limited to 2 GB, or at most to 4 GB. The amount of total RAM 8 > GB does not help here, since 2^32 = 4 G. > > You should reduce the key_buffer_size or innodb_buffer_pool_size in my.cnf. > > Best regards, > > Heikki > > Oracle Corp./Innobase Oy > InnoDB - transactions, row level locking, and foreign keys for MySQL > > InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM > tables > http://www.innodb.com/order.php > > ----- Original Message ----- > From: ""sheeri kritzer"" <[EMAIL PROTECTED]> > Newsgroups: mailing.database.myodbc > Sent: Friday, May 05, 2006 10:50 PM > Subject: Re: InnoDB Memory Problem causing mysql to crash > > > Well, according to my calculations: > > innodb_buffer_pool_size + key_buffer_size > > + max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size) > > + max_connections*2MB > > > > (I used the default binlog_cache_size value of 32K plus your settings) > > > > MySQL could use up to 4.991913 G of memory. Shouldn't be a problem, > > unless of course your 8G of machine is running something other than > > MySQL. Is it? Because the fact that it could not allocate memory > > means that something was trying to use memory that didn't exist > > > > Did MySQL dump a core file? > > > > Did you follow this advice? > > > >> You seem to be running 32-bit Linux and have 473 concurrent connections. > >> If you have not changed STACK_SIZE in LinuxThreads and built the binary > >> yourself, LinuxThreads is quite likely to steal a part of the global > >> heap= > > > > for > > > >> the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html > > > > Did you read the man page? > > > >> 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. > > > > Also, did you try to look at your slow query logs to see if there was > > some kind of query hogging memory? What about backups running at the > > same time? > > > > I'll note that you maxxed out your connections, which shouldn't cause > > a crash, but might indicate that your server tuning is not up-to-date > > with your actual usage. > > > > Are your data and logfiles are on a diffferent partitions? We had > > problems with one machine where the data and logfiles were on the same > > partition, and it would crash -- we moved to a machine that was the > > same except for the different OS partitions, and it didn't crash! We > > figure the disk seeking just killed the OS so it segfaulted the mysql > > process. > > > > -Sheeri > > > > On 5/4/06, Dobromir Velev <[EMAIL PROTECTED]> wrote: > >> Hi, > >> I'm trying to resolve why InnoDB is crashing. It happened twice for the > >> l= > > > > ast > > > >> month without obvoius reason > >> > >> Any help will be appreciated. > >> > >> Dobromir Velev > >> > >> My Server is > >> Red Hat Enterprise Linux ES release 3 (Taroon Update 7) > >> 2.4.21-32.0.1.ELs= > > > > mp > > > >> Dual 3.2 GHz Intel Xeon > >> 8 GB RAM > >> with 3 x 146GB SCA Ultra 320 10K RPM SCSI Drives > >> > >> > >> my.cnf settings > >> > >> innodb_buffer_pool_size=3D2000M > >> innodb_additional_mem_pool_size=3D20M > >> innodb_log_file_size=3D150M > >> innodb_log_buffer_size=3D8M > >> innodb_flush_log_at_trx_commit=3D0 > >> innodb_lock_wait_timeout=3D50 > >> key_buffer_size=3D1000M > >> read_buffer_size=3D500K > >> read_rnd_buffer_size=3D1200K > >> sort_buffer_size=3D1M > >> thread_cache=3D256 > >> thread_concurrency=3D8 > >> thread_stack=3D126976 > >> myisam_sort_buffer_size=3D64M > >> max_connections=3D600 > >> > >> > >> The error log shows the following message: > >> > >> InnoDB: Fatal error: cannot allocate 1048576 bytes of > >> InnoDB: memory with malloc! Total allocated memory > >> InnoDB: by InnoDB 2263507272 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 buil= > > > > t, > > > >> or misconfigured. This error can also be caused by malfunctioning > >> hardwar= > > > > e. > > > >> We will try our best to scrape up some info that will hopefully help > >> diag= > > > > nose > > > >> the problem, but since we have already crashed, something is definitely > >> w= > > > > rong > > > >> and this may fail. > >> > >> key_buffer_size=3D1048576000 > >> read_buffer_size=3D507904 > >> max_used_connections=3D600 > >> max_connections=3D600 > >> threads_connected=3D473 > >> It is possible that mysqld could use up to > >> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > >> = > > > > =3D > > > >> 1935995 K > >> bytes of memory > >> Hope that's ok; if not, decrease some variables in the equation. > >> > >> You seem to be running 32-bit Linux and have 473 concurrent connections. > >> If you have not changed STACK_SIZE in LinuxThreads and built the binary > >> yourself, LinuxThreads is quite likely to steal a part of the global > >> heap= > > > > for > > > >> the thread stack. Please read http://www.mysql.com/doc/L/i/Linux.html > >> > >> thd=3D(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=3D0xbff1f558, backtrace may not be correct. > >> Stack range sanity check OK, backtrace follows: > >> 0x8072d74 > >> 0x826d678 > >> 0x8213c74 > >> 0x8213d04 > >> 0x8218b84 > >> 0x81d5ba6 > >> 0x80fd659 > >> 0x826ae2c > >> 0x82a0cda > >> New value of fp=3D(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 > >> 060503 16:37:21 mysqld restarted > >> 060503 16:37:21 Can't start server: Bind on TCP/IP port: Address already > >> = > > > > in > > > >> use > >> 060503 16:37:21 Do you already have another mysqld server running on > >> port= > >> > >> 3306 ? > >> 060503 16:37:21 Aborting > >> > >> and the resolved stack trace is > >> > >> 0x8072d74 handle_segfault + 420 > >> 0x826d678 pthread_sighandler + 184 > >> 0x8213c74 ut_malloc_low + 132 > >> 0x8213d04 ut_malloc + 20 > >> 0x8218b84 os_aio_simulated_handle + 916 > >> 0x81d5ba6 fil_aio_wait + 214 > >> 0x80fd659 io_handler_thread + 25 > >> 0x826ae2c pthread_start_thread + 220 > >> 0x82a0cda thread_start + 4 > >> > >> > >> > >> > >> -- > >> 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] -- 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]
