Hello Heikki, Sorry, last version of the MySQL-Max rpm was missing the symbols file. This version has it, so I did as you asked. Here is the output of the most recent 4.
Regarding mem usage, the machine has 1gb, mysql is using 374MB which is fine as far as I am concerned. I can decrease the numbers tho, but the last time I did decrease the numbers you mentioned performance dropped and our batch jobs (not the web queries) now take about 20% longer to run. Do you think decreasing sort and record buffer figures might effect performance? Thanks, Richard [EMAIL PROTECTED] log]# resolve_stack_dump -s /usr/lib/mysql/mysqld-max.sym -n stack1 0x806fcc4 handle_segfault__Fi + 428 0x82dad98 pthread_sighandler + 184 0x8289c48 mem_area_free + 248 0x8288852 mem_heap_block_free + 366 0x81a149d row_sel_store_mysql_rec + 69 0x81a4fcb row_search_for_mysql + 8011 0x80c2f73 general_fetch__11ha_innobasePcUiUi + 319 0x80c5a33 rnd_next__11ha_innobasePc + 83 0x80b48b6 rr_sequential__FP14st_read_record + 150 0x8095979 sub_select__FP4JOINP13st_join_tableb + 337 0x8095633 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 411 0x808e337 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP13select_result + 4183 0x8076b90 mysql_execute_command__Fv + 812 0x807acac mysql_parse__FP3THDPcUi + 216 0x8075d45 do_command__FP3THD + 1453 0x80750e7 handle_one_connection__FPv + 655 [EMAIL PROTECTED] log]# [EMAIL PROTECTED] log]# resolve_stack_dump -s /usr/lib/mysql/mysqld-max.sym -n stack2 0x806fcc4 handle_segfault__Fi + 428 0x82dad98 pthread_sighandler + 184 0x8289c48 mem_area_free + 248 0x8288852 mem_heap_block_free + 366 0x81a149d row_sel_store_mysql_rec + 69 0x81a4fcb row_search_for_mysql + 8011 0x80c2f73 general_fetch__11ha_innobasePcUiUi + 319 0x80c5a33 rnd_next__11ha_innobasePc + 83 0x80b48b6 rr_sequential__FP14st_read_record + 150 0x8095979 sub_select__FP4JOINP13st_join_tableb + 337 0x8095633 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 411 0x808e337 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP13select_result + 4183 0x8076b90 mysql_execute_command__Fv + 812 0x807acac mysql_parse__FP3THDPcUi + 216 0x8075d45 do_command__FP3THD + 1453 0x80750e7 handle_one_connection__FPv + 655 [EMAIL PROTECTED] log]# [EMAIL PROTECTED] log]# resolve_stack_dump -s /usr/lib/mysql/mysqld-max.sym -n stack3 0x806fcc4 handle_segfault__Fi + 428 0x82dad98 pthread_sighandler + 184 0x8289821 mem_area_alloc + 741 0x8288463 mem_heap_create_block + 99 0x81a18c0 row_sel_store_mysql_rec + 1128 0x81a4fcb row_search_for_mysql + 8011 0x80c2f73 general_fetch__11ha_innobasePcUiUi + 319 0x80c5a33 rnd_next__11ha_innobasePc + 83 0x80b48b6 rr_sequential__FP14st_read_record + 150 0x8095979 sub_select__FP4JOINP13st_join_tableb + 337 0x8095633 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 411 0x808e337 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP13select_result + 4183 0x8076b90 mysql_execute_command__Fv + 812 0x807acac mysql_parse__FP3THDPcUi + 216 0x8075d45 do_command__FP3THD + 1453 0x80750e7 handle_one_connection__FPv + 655 [EMAIL PROTECTED] log]# [EMAIL PROTECTED] log]# resolve_stack_dump -s /usr/lib/mysql/mysqld-max.sym -n stack4 0x806fcc4 handle_segfault__Fi + 428 0x82dad98 pthread_sighandler + 184 0x8289d65 mem_area_free + 533 0x8288852 mem_heap_block_free + 366 0x81a149d row_sel_store_mysql_rec + 69 0x81a4fcb row_search_for_mysql + 8011 0x80c2f73 general_fetch__11ha_innobasePcUiUi + 319 0x80c5a33 rnd_next__11ha_innobasePc + 83 0x80b48b6 rr_sequential__FP14st_read_record + 150 0x8095979 sub_select__FP4JOINP13st_join_tableb + 337 0x8095633 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 411 0x808e337 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP13select_result + 4183 0x8076b90 mysql_execute_command__Fv + 812 0x807acac mysql_parse__FP3THDPcUi + 216 0x8075d45 do_command__FP3THD + 1453 0x80750e7 handle_one_connection__FPv + 655 [EMAIL PROTECTED] log]# On Wed, 2003-06-04 at 11:58, Heikki Tuuri wrote: > Richard, > > please read http://www.mysql.com/doc/U/s/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. > > Also note that you should make sort buffer and record buffer smaller, say > 512k. mysqld may be hogging too much memory. > > record_buffer=2093056 > sort_buffer=2097144 > max_used_connections=385 > max_connections=2000 > threads_connected=382 > It is possible that mysqld could use up to > key_buffer_size + (record_buffer + sort_buffer)*max_connections = > 3997872 K > > Best regards, > > Heikki Tuuri > Innobase Oy > http://www.innodb.com > Transactions, foreign keys, and a hot backup tool for MySQL > Order MySQL technical support from https://order.mysql.com/ > > > .................. > > Subject: RH 8.0 InnoDB: Assertion failure in thread 122911 in file > mem0pool.c line 477 > From: Richard F. Rebel > Date: 04 Jun 2003 11:43:49 -0400 > > > > I have reported this before, but MySQL-Max-3.23.56-1 (official rpm's) is > repeatedly crashing. > > Often when executing queries on an InnoDB table with about 1300 rows > that are similar to this: > > select MEET, count(*) > from RATINGS_WHENU > where MEET in ('N','Y') > and SITE = '63' > group by MEET > > I can run the query again and again, and cannot get it to crash myself, > but our applications run this query on regular occasion. > > Below is output of some recent crashes this am. > > Any help is appreciated. I reported this or atleast a very similar > problem before and I followed the advice to use the most recent MySQL > and to alter a few variables which did seem to help for a couple of > weeks atleast. Our db traffic really hasn't changed much since then so > I am flummoxed as to why now this would resurface. > > Thanks, > > Richard F. Rebel. -- Richard F. Rebel [EMAIL PROTECTED] t. 212.239.0000 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
