I cannot find the core file.. where is it?
BTW, system seems somtimes run out of file handles / max processes.
There is some more information to provide:
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping 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, ebp=0xbffff3d8, backtrace may not be correct
stack range sanity check, ok, backtrace follows
0x40078dd4 _end + 937886004
0x40077f05 _end + 937882213
0x80afda1 create_new_thread__FP3THD + 937
0x80b03a5 handle_connections_sockets__FPv + 1185
0x80af6a7 main + 2539
0x4010b2db _end + 938485307
0x8089971 _start + 33
New value of ebp failed sanity check terminating backtrace
Number of processes running now: 0
010613 22:29:24 mysqld restarted
/usr/local/mysql/libexec/mysqld: ready for connections
010613 22:29:25 Warning: Checking table: './Counter/common_one_IP'
010613 22:29:25 Warning: Checking table: './Counter/common_one'
010613 22:29:29 Warning: Checking table: './user/log'
010613 22:29:29 Warning: Checking table: './Counter/taikoo_taikoo_IP'
010613 22:29:29 Warning: Checking table: './Counter/taikoo_taikoo'
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping 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, ebp=0xbffff3d8, backtrace may not be correct
stack range sanity check, ok, backtrace follows
0x40078dd4 _end + 937886004
0x40077f05 _end + 937882213
0x80afda1 create_new_thread__FP3THD + 937
0x80b03a5 handle_connections_sockets__FPv + 1185
0x80af6a7 main + 2539
0x4010b2db _end + 938485307
0x8089971 _start + 33
New value of ebp failed sanity check terminating backtrace
Number of processes running now: 0
010613 22:29:56 mysqld restarted
/usr/local/mysql/libexec/mysqld: ready for connections
----- Original Message -----
> Hi all, I am a new subscriber of this list.
> I have a question that have confuse me for a long time.
>
> I am currently running MySQL-3.23.32 on Debian(woody)
> with kernel 2.4.x on a i386 box /w 1G Ram..
>
> We are currently runing two different kind of database on the
> same server. One of them is a few table in a Database, each of
> them have over 10,000 rows, a Merge table in it.
> Another one is over 30,000 tables in a single Database, with no
> more then row in each of them.. ( Don't ask me why that
> happended.. I am not the one design this.) All of them are
> MyISAM tables.
>
> The server is now facing about 200 queries/second on average,
> and a peak of about 430 queries. All of them are simple LOCK,
> UNLOCK, SELECT, INSERT.. no join table, no union, no sort..
> only simple queries.. most of them have no more then 10 rows
> of answer.
>
> Recently, we done a system upgrade, from kernel 2.4.2 to kernel
> 2.4.4 for a RealTex LAN Card SMP fix. At about the same time,
> we have changed some of our program... introducing some rename
> table and drop tables too.. a few days later,
> the sql server start core dumping on usual loading.. We have try
> using --debug option, but it can't help as it's handling too few
> queries per second, and the sql server just don't dump...
>
> I am quite sure that's was not damaged table problem, as we have run
> myisamchk many times, with differenet options.. -a -f -o -S -e -m -q
> for over ten times..
>
> After hesitating for an moment, we desided to upgrade to 3.23.35
> (ar.. in fact, we have try 3.23.31, .32, .35, .37 and .38 ... the
following
> situation hanppens on .35, .37, and .38 )
> After starting the mysql server seems work fine... but.... huh?
> why that's so slow? it's running with a maximum of 65 queries/seconds..
> the load average climb up quickly... "top" tell me that mysqld is forking
> childs, each of them dieing quickly, keeping on average of 80 childs at
> the same moment..(child? or thread? fix me if i am wrong..)
> And nothing abnormal are printed to (hostname).err.. this make me more
> confusing..
> i have heard that recent kernel will give childs created with fork() a
> higher priority.. it that related?
>
> Does anyone have the same problem before? should i file this as a bug?
> ( ar.. i know i am not providing enough infomation.. but.. whenever I
> start mysql with --debug, it don't dump, as i have said.... )
>
> anyway.. i will try a downgrade to kernel 2.4.2 this night..
>
> FYI, we compile mysql with "--without-bench --without-docs --with-debug".
> we have tried different version of gcc, all of them are debian's cvs
> relaease.
>
> Here goes my my.cnf, the flush is something i added i discover this..
> to protect my tables:
> [client]
> port = 3306
> socket = /tmp/mysql.sock
>
> [mysqld]
> port = 3306
> socket = /tmp/mysql.sock
> datadir = /usr/local/mysql/var
>
> skip-locking
> #enable-locking
> flush
> #temp-pool
> core-file
> user = root
> set-variable = flush_time=10
> set-variable = back_log=256
> set-variable = key_buffer=8M
> set-variable = max_allowed_packet=4M
> set-variable = table_cache=2048
> set-variable = sort_buffer=4M
> set-variable = record_buffer=4M
> set-variable = thread_concurrency=4
> set-variable = myisam_sort_buffer_size=16M
> set-variable = max_connect_errors=65536
> set-variable = max_connections=512
> myisam-recover = BACKUP,FORCE
>
> log = /usr/local/mysql/var/dump.log
> log-update
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
