- developers - lists.mariadb.org

[Maria-developers] mariadb 10.1.5 crash
by Roberto Spadim 19 Jun '15

19 Jun '15

hi guys, i was testing mariadb with test servers and i hit a crash could anyone check? server has 8GB of ram, i don't know what query is 2015-06-17 14:01:32 140497706510080 [Note] WSREP: Stop replication 2015-06-17 14:01:32 140497706510080 [Note] Event Scheduler: Purging the queue. 0 events 2015-06-17 14:01:32 140497706510080 [Note] /usr/mariadb/mariadb/bin//mysqld: Shutdown complete 150617 14:01:32 mysqld_safe mysqld from pid file /home/mysql/pid/local.pid ended 150617 14:02:38 mysqld_safe Starting mysqld daemon with databases from /home/mysql/data/local/ 2015-06-17 14:02:38 140260849645440 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release. 2015-06-17 14:02:38 140260849645440 [Note] /usr/mariadb/mariadb/bin//mysqld (mysqld 10.1.5-MariaDB-log) starting as process 2321 ... 2015-06-17 14:02:38 140260849645440 [Note] Plugin 'InnoDB' is disabled. 2015-06-17 14:02:38 140260849645440 [Note] Plugin 'FEEDBACK' is disabled. 2015-06-17 14:02:38 140260849645440 [Note] Server socket created on IP: '::'. 2015-06-17 14:02:38 140260849645440 [Note] Event Scheduler: Loaded 0 events 2015-06-17 14:02:38 140260849645440 [Note] WSREP: Read nil XID from storage engines, skipping position init 2015-06-17 14:02:38 140260849645440 [Note] WSREP: wsrep_load(): loading provider library 'none' 2015-06-17 14:02:38 140260849645440 [Note] /usr/mariadb/mariadb/bin//mysqld: ready for connections. Version: '10.1.5-MariaDB-log' socket: '/tmp/mysql.BH.sock' port: 3307 MariaDB Server 150617 17:02:14 [ERROR] 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. To report this bug, see http://kb.askmonty.org/en/reporting-bugs 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. Server version: 10.1.5-MariaDB-log key_buffer_size=629145600 read_buffer_size=4194304 max_used_connections=23 max_threads=102 thread_count=16 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1452041 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7f90d0353008 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... stack_bottom = 0x7f9103539e80 thread_stack 0x48000 mysys/stacktrace.c:247(my_print_stacktrace)[0x7f9106c50b0b] sql/signal_handler.cc:153(handle_fatal_signal)[0x7f91067eadb5] /lib64/libpthread.so.0(+0x10d00)[0x7f910537dd00] sql/sql_plist.h:181(I_P_List_iterator)[0x7f910679cf03] mysys/lf_hash.c:125(lfind)[0x7f9106c5a1a0] sql/table_cache.cc:1084(tdc_iterate(THD*, char (*)(void*, void*), void*, bool))[0x7f910679e4e3] sql/table_cache.cc:267(tc_add_table(THD*, TABLE*))[0x7f910679e808] sql/sql_base.cc:2572(open_table(THD*, TABLE_LIST*, Open_table_context*))[0x7f9106633272] sql/sql_base.cc:4016(open_and_process_table)[0x7f91066370c8] sql/sql_base.cc:5184(open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*))[0x7f9106637394] sql/sql_parse.cc:5718(execute_sqlcom_select)[0x7f910666f083] sql/sql_parse.cc:2938(mysql_execute_command(THD*))[0x7f910667a9ce] sql/sql_parse.cc:7173(mysql_parse)[0x7f910667dc3d] sql/sql_parse.cc:1470(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x7f91066802a8] sql/sql_parse.cc:1095(do_command(THD*))[0x7f910668083b] sql/sql_connect.cc:1347(do_handle_one_connection(THD*))[0x7f91067435ef] sql/sql_connect.cc:1260(handle_one_connection)[0x7f9106743747] /lib64/libpthread.so.0(+0x7654)[0x7f9105374654] /lib64/libc.so.6(clone+0x6d)[0x7f9104a987dd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f90c8424020): is an invalid pointer Connection ID (thread ID): 516 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 150617 17:02:14 mysqld_safe Number of processes running now: 0 150617 17:02:14 mysqld_safe mysqld restarted 2015-06-17 17:02:15 140086665152384 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release. 2015-06-17 17:02:15 140086665152384 [Note] /usr/mariadb/mariadb/bin//mysqld (mysqld 10.1.5-MariaDB-log) starting as process 9785 ... 2015-06-17 17:02:15 140086665152384 [Note] mysqld: Aria engine: starting recovery recovered pages: 0% 10% 21% 31% 41% 51% 78% 90% 100% (0.0 seconds); tables to flush: 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 (0.3 seconds); 2015-06-17 17:02:15 140086665152384 [Note] mysqld: Aria engine: recovery done 2015-06-17 17:02:15 140086665152384 [Note] Plugin 'InnoDB' is disabled. 2015-06-17 17:02:15 140086665152384 [Note] Plugin 'FEEDBACK' is disabled. 2015-06-17 17:02:15 140086665152384 [Note] Recovering after a crash using tc.log 2015-06-17 17:02:15 140086665152384 [Note] Starting crash recovery... 2015-06-17 17:02:15 140086665152384 [Note] Crash recovery finished. 2015-06-17 17:02:15 140086665152384 [Note] Server socket created on IP: '::'. 2015-06-17 17:02:15 140086665152384 [Note] Event Scheduler: Loaded 0 events 2015-06-17 17:02:15 140086665152384 [Note] WSREP: Read nil XID from storage engines, skipping position init 2015-06-17 17:02:15 140086665152384 [Note] WSREP: wsrep_load(): loading provider library 'none' 2015-06-17 17:02:15 140086665152384 [Note] /usr/mariadb/mariadb/bin//mysqld: ready for connections. Version: '10.1.5-MariaDB-log' socket: '/tmp/mysql.BH.sock' port: 3307 MariaDB Server 2015-06-17 17:02:19 140086617798400 [ERROR] mysqld: Table './conquista_comercial/est_atu' is marked as crashed and should be repaired 2015-06-17 17:02:19 140086617798400 [Warning] Checking table: './conquista_comercial/est_atu' 2015-06-17 17:02:19 140086617798400 [ERROR] mysqld: Table './conquista_comercial/est_spa' is marked as crashed and should be repaired 2015-06-17 17:02:19 140086617798400 [Warning] Checking table: './conquista_comercial/est_spa' 2015-06-17 17:02:51 140086617798400 [ERROR] mysqld: Table './conquista_comercial/est_dia' is marked as crashed and should be repaired 2015-06-17 17:02:51 140086617798400 [Warning] Checking table: './conquista_comercial/est_dia' 2015-06-17 17:02:52 140086617798400 [ERROR] mysqld: Table './conquista_comercial/rastreabilidade_impressao' is marked as crashed and should be repaired 2015-06-17 17:02:52 140086617798400 [Warning] Checking table: './conquista_comercial/rastreabilidade_impressao' 2015-06-17 17:29:58 140086663948032 [ERROR] mysqld: Table './conquista_comercial/est_atu_erros' is marked as crashed and should be repaired 2015-06-17 17:29:58 140086663948032 [Warning] Checking table: './conquista_comercial/est_atu_erros' 2015-06-17 19:24:04 140086538364672 [Note] /usr/mariadb/mariadb/bin//mysqld: Normal shutdown 2015-06-17 19:24:04 140086538364672 [Note] WSREP: Stop replication 2015-06-17 19:24:06 140086538364672 [Note] Event Scheduler: Purging the queue. 0 events 2015-06-17 19:24:07 140086538364672 [Note] /usr/mariadb/mariadb/bin//mysqld: Shutdown complete 150617 19:24:07 mysqld_safe mysqld from pid file /home/mysql/pid/local.pid ended -- Roberto Spadim SPAEmpresarial - Software ERP Eng. Automação e Controle

3 4

Re: [Maria-developers] [Commits] 4563e13: MDEV-8156: Assertion failure in file log0crypt.cc line 220 on server restart
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Jan! On Jun 18, Jan Lindström wrote: > revision-id: 4563e1315df6333b280aa441e07d979d8c2ce9f4 > parent(s): eb2c170bb03fb7c98d3bd864bae46ddfb8c3acb5 > committer: Jan Lindström > branch nick: 10.1-encryption > timestamp: 2015-06-18 19:58:57 +0300 > message: > > MDEV-8156: Assertion failure in file log0crypt.cc line 220 on server restart > > Instead of asserting print informative error message to error log > and return failure from innodb_init causing the server to shutdown. A test case would've been nice Regards, Sergei

1 0

Re: [Maria-developers] [Commits] a5799f5: MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 18, svoj(a)mariadb.org wrote: > revision-id: a5799f5b087f79a8063cd10242527e9235f87597 > parent(s): 4c336c8ba4fbb4ac1a4fe9680c6899c6a49b6c46 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-18 18:01:56 +0400 > message: > > MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO > > Pass THD to Item_field (and all derivatives) constructors. > This reduces number of pthread_getspecific() calls from 322 to 292. ok to push Regards, Sergei

1 0

Re: [Maria-developers] changing some defaults related to replication
by Kristian Nielsen 18 Jun '15

18 Jun '15

Oleksandr Byelkin <sanja(a)montyprogram.com> writes: > Hi, Kristian! > > could you say against some or default changes listed here if they will > be done in 10.1? > > http://dev.mysql.com/doc/refman/5.6/en/server-default-changes.html binlog_checksum NONE CRC32 5.6.6 I am not sure that is a good idea. Binlog checksums are incompatible with earlier slave versions I think (though I guess we supported it all the way back to 5.3?). The implementation is rather bad, and not well tested in MariaDB I think, and could easily have bugs. --binlog-row-event-max-size 1024 8192 5.6.6 Seems like a good idea, 1024 is quite small. Shouldn't it default to something even larger than 8192? Seems safe to change. sync_master_info 0 10000 5.6.6 sync_relay_log 0 10000 5.6.6 sync_relay_log_info 0 10000 5.6.6 Seems safe enough, though I am not sure what the point of this change would be. I think that was all of the replication-related changes. I am not planning myself to change anything about this in 10.1, but I have no strong opinion for or against if someone else wants to do it. - Kristian.

1 0

Re: [Maria-developers] [Commits] 2e08ec2: MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 2e08ec24623e0b3d3db02333e16658dcfaa0535c > parent(s): b776f8d3a8afff55d5f8208da7bdfce9aa33eb39 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 13:09:22 +0400 > message: > > MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO > > Do not call handler::rebind_psi() and handler::unbind_psi() when performance > schema is compiled out. I don't particularly like it, you're just avoding an empty virtual function call, and that in a configuration (no P_S) which no our binaries use. But you can push it if you want. Regards, Sergei

2 2

Re: [Maria-developers] [Commits] 3f0b023: MDEV-7952 - clock_gettime() takes 0.24% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 3f0b02351a53e0fcaee8554c2c852fb3da8fe7da > parent(s): 5d03dd20a4abbfd9777b619dfd51a6927323955a > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 18:55:38 +0400 > message: > > MDEV-7952 - clock_gettime() takes 0.24% in OLTP RO > > Initialize abs_timeout when it is about to be used. This saves one my_hrtime() > call on hot path (when we acquire MDL lock without waiting). ok > When filling I_S.PROCESSLIST use THD::start_utime/THD::utime_after_query instead > of THD::start_time. This allows us to save 2 clock_gettime() calls. see below > diff --git a/sql/sql_show.cc b/sql/sql_show.cc > index 1e4723d..fa3161a 100644 > --- a/sql/sql_show.cc > +++ b/sql/sql_show.cc > @@ -2730,7 +2730,7 @@ int fill_schema_processlist(THD* thd, TABLE_LIST* tables, COND* cond) > TABLE *table= tables->table; > CHARSET_INFO *cs= system_charset_info; > char *user; > - my_hrtime_t unow= my_hrtime(); > + ulonglong unow= microsecond_interval_timer(); > DBUG_ENTER("fill_schema_processlist"); > > DEBUG_SYNC(thd,"fill_schema_processlist_after_unow"); > @@ -2793,9 +2793,12 @@ int fill_schema_processlist(THD* thd, TABLE_LIST* tables, COND* cond) > table->field[4]->store(command_name[tmp->get_command()].str, > command_name[tmp->get_command()].length, cs); > /* MYSQL_TIME */ > - ulonglong start_utime= tmp->start_time * HRTIME_RESOLUTION + tmp->start_time_sec_part; > - ulonglong utime= start_utime && start_utime < unow.val > - ? unow.val - start_utime : 0; > + ulonglong utime= tmp->start_utime; > + ulonglong utime_after_query_snapshot= tmp->utime_after_query; > + if (utime < utime_after_query_snapshot) > + utime= utime_after_query_snapshot; // COM_SLEEP > + utime= utime && utime < unow ? unow - utime : 0; 1. Please add an assert here that utime<=unow. It uses microsecond_interval_timer(), which is supposed to be strictly increasing (unlike my_hrtime()). 2. You might need to update mysqld_list_processes() too. > table->field[5]->store(utime / HRTIME_RESOLUTION, TRUE); > /* STATE */ Regards, Sergei

2 1

Re: [Maria-developers] [Commits] 3d1b65b: MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Apr 28, svoj(a)mariadb.org wrote: > revision-id: 3d1b65b4923a49f9303501dd546af02982608b2b > parent(s): 8a0f3310275f7b4fa445f907140f677910e18999 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-28 15:20:48 +0400 > message: > > MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO > > Pass THD to find_all_keys() and Item_equal::Item_equal(). > In MRR use table->in_use instead of current_thd. > > This reduces number of pthread_getspecific() calls from 354 to 320. ok to push. although for find_all_keys() it doesn't make any sense, it's a big, complex, and expensive function. One current_thd doesn't change anything. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 2e08ec2: MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 2e08ec24623e0b3d3db02333e16658dcfaa0535c > parent(s): b776f8d3a8afff55d5f8208da7bdfce9aa33eb39 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 13:09:22 +0400 > message: > > MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO > > Do not call handler::rebind_psi() and handler::unbind_psi() when performance > schema is compiled out. > > Overhead change: > handler::rebind_psi 0.04% -> out of radar > handler::unbind_psi 0.03% -> out of radar > open_table 0.21% -> 0.18% > close_thread_table 0.05% -> 0.05% Really? I don't believe it. handler::rebind_psi() and handler::unbind_psi() are empty methods, not doing anything. There's only a cost a virtual function call. And you're saying that it took 15% of the open_table() execution time? Regards, Sergei

2 1

[Maria-developers] [GSoC] MXS-2: Week 2 and 3
by sriram patil 17 Jun '15

17 Jun '15

Hi All, Please find link to my first blog post of second and third week below. <http://srirampatil.tumblr.com/post/121594591925/mxs-2-week-2-and-3> MXS-2: Week 2 and 3 <http://srirampatil.tumblr.com/post/121594591925/mxs-2-week-2-and-3> Feel free to point out mistakes, if any. Also, suggestions ans/or reviews are welcome! Thanks, Sriram

2 2

[Maria-developers] GSoC Progress Report [MDEV-5199]
by Blessing Atie 16 Jun '15

16 Jun '15

Hi Sergei, colin! This past week I have studied the sequence engine to understand how it generates tables on the fly. I also looked at how table functions work in other databases. I am currently working on how to implement the simplest table function from our new plugin API(Still to be completed) and which will do exacly what the sequence engine does but this time in a function call like in <select * from udf_seq(1,10)>. Exams are fast approaching in my University. I will acceletrate work as soon as I finish my Exams which will run from 22nd May to 6th June and after which I will be available to the fullest capacity to put enough time on my Work. In the mean while for this week I plan on completing our plugin declaration structure and also look for other candidate functions that can be implemented. Regards, Blessing Atie.

2 1