I would have provided a resolved stack trace if there was one referred to in the mysqld.err.
I believe it's what Alex said: innodb_buffer_pool_size + key_buffer_size + max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size) + max_connections*2MB uses more memory than I have. To the MySQL folks, can the crash error be changed? I appreciate that it's in the docs, and I should know them back and forth of course, but when the crash error says that the total possible memory is key_buffer_size + max_connections*(sort_buffer_size+read_buffer_size) that's actually wrong. Thanx for everyone's help! -Sheeri On 1/10/06, Gleb Paharenko <[EMAIL PROTECTED]> wrote: > Hello. > > > > Please, could you provide a resolved stack trace. I know sometimes, > > it is difficult in a heavy loaded production environment, but check > > if the problem still exists on the official binaries of the latest > > release. Have a look here as well: > > http://bugs.mysql.com/bug.php?id=15868 > > > > > > sheeri kritzer wrote: > > > We're running MySQL version 4.1.12 on Fedora Core 3 64-bit. we've > > > been crashing; here is a mysqld.err file from one crash: > > > > > > 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 diagno= > > > se > > > the problem, but since we have already crashed, something is definitely wro= > > > ng > > > and this may fail. > > > > > > key_buffer_size=3D335544320 > > > read_buffer_size=3D131072 > > > max_used_connections=3D2049 > > > max_connections=3D2048 > > > threads_connected=3D371 > > > It is possible that mysqld could use up to > > > key_buffer_size + (read_buffer_size + > > > sort_buffer_size)*max_connections =3D 4784112 K > > > bytes of memory > > > Hope that's ok; if not, decrease some variables in the equation. > > > > > > 060108 14:43:07 InnoDB: Database was not shut down normally! > > > InnoDB: Starting crash recovery. > > > [InnoDB crash recovery elided] > > > ----------------------------------------- > > > We have 6G of memory on the server, and we checked -- we're not > > > running out of memory. > > > > > > I'm guessing that mysqld crashed because of that 2049th connection -- > > > shouldn't it just refuse the connection, not crash? > > > > > > The variables in the mysqld.err match the /etc/my.cnf: > > > > > > [mysqld] > > > old-passwords > > > tmpdir =3D /tmp/ > > > datadir =3D /var/lib/mysql > > > socket =3D /var/lib/mysql/mysql.sock > > > port =3D 3306 > > > key_buffer =3D 320M > > > max_allowed_packet =3D 16M > > > table_cache =3D 1024 > > > thread_cache =3D 80 > > > ft_min_word_len =3D 3 > > > > > > # Use this to prevent access via TCP/IP > > > # skip_networking > > > > > > # Query Cache Settings - OFF due to overload of Session table > > > query_cache_size =3D 32M > > > query_cache_type =3D 2 > > > > > > # Log queries taking longer than "long_query_time" seconds > > > long_query_time =3D 4 > > > log-slow-queries =3D /var/lib/mysql/slow-queries.log > > > log-error =3D /var/lib/mysql/mysqld.err > > > > > > # Try number of CPU's*2 for thread_concurrency > > > thread_concurrency =3D 12 > > > > > > interactive_timeout =3D 28800 > > > wait_timeout =3D 30 > > > > > > # when you change this recalculate total possible mysqld memory usage!! > > > # key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > > > > > > max_connections =3D 2048 > > > max_connect_errors =3D 128 > > > # Replication Master Server (default) > > > # binary logging is required for replication > > > log-bin > > > server-id =3D 15 > > > max_binlog_size =3D 2G > > > > > > # InnoDB tables > > > innodb_data_home_dir =3D /var/lib/mysql/ > > > innodb_data_file_path =3D ibdata1:3G;ibdata2:3G; > > > innodb_log_group_home_dir =3D /var/lib/mysql/ > > > innodb_log_arch_dir =3D /var/lib/mysql/ > > > innodb_buffer_pool_size =3D 4G > > > innodb_additional_mem_pool_size =3D 40M > > > innodb_log_file_size =3D 160M > > > innodb_log_buffer_size =3D 80M > > > innodb_flush_log_at_trx_commit =3D 0 > > > innodb_lock_wait_timeout =3D 50 > > > innodb_thread_concurrency =3D 8 > > > innodb_file_io_threads =3D 4 > > > ---------------------------------------------------------------------------= > > > ----- > > > > > > Any help is appreciated. We've been crashing around the same time > > > every day, our busiest time of day. > > > > > > -Sheeri > > > > > > > -- > For technical support contracts, goto https://order.mysql.com/?ref=ensita > This email is sponsored by Ensita.NET http://www.ensita.net/ > __ ___ ___ ____ __ > / |/ /_ __/ __/ __ \/ / Gleb Paharenko > / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] > /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET > <___/ www.mysql.com > > > > > -- > 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]
