January 2012 - developers - lists.mariadb.org

Re: [Maria-developers] Fwd: [Commits] Rev 3335: Fix bug lp:825075 in file:///home/tsk/mprog/src/5.3/
by Sergei Petrunia 17 Feb '12

17 Feb '12

Hi Timour, Feedback follows skype discussion: First, here's a general comment Consider a query: SELECT b, min(a) FROM t1 GROUP BY b; Suppose there is an index (b,a). Loose scan would execute it as follows: S00 h->index_first(); S01 produce an output record of (b, a) // first value of 'a' is the minimum S02 S03 h->read_next_different_b(); // Jump to the next GROUP-BY group. S04 ... S05 If we modify the query by adding a WHERE: SELECT b, min(a) FROM t1 WHERE arbitrary_cond(a,b) GROUP BY b; then LooseScan (in its current form) will be unable to execute it. The problem is here: S00 h->index_first(); S01 produce an output record of (b, a) // first value of 'a' is the minimum ^^^ what if this record doesn't match the WHERE? We'll have to scan further within the record having b=first_record.b until we find a match. LooseScan executor doesn't support such "walk forward" action currently. If the WHERE clause has been converted into a range, such that there are no records that would be contained in the range but not match the WHERE clause (***) then LooseScan is able to handle it. Example: SELECT b, min(a) FROM t1 WHERE a>10 GROUP BY b; Execution would proceed as follows: S00 h->index_first(); S00 h->index_read(HA_READ_AFTER_KEY, {current_row.b, 'a>10'}) S01 produce an output record of (b, a) // first value of 'a>10' is the minimum Step S01 will produce correct results as long as the following holds: "The first record we've got in a range will satisfy the WHERE condition" This is not always the case. Here's a counterexample: SELECT b, min(a) FROM t1 WHERE a>10 GROUP BY b; SELECT b, min(a) FROM t1 WHERE a>10 and ((a MOD 2) = 0) GROUP BY b; -- (C1) Consider the second query and this dataset: b , a 1, 5 1, 7 1, 11 1, 13 1, 14 range optimizer would give a range of "a > 10", and the first matching record is (1,11). It doesn't satisfy the "(a MOD 2)=0" condition, neither does the next record of (1,13), and only the record (1,14) will satisfy the MOD part of the condition. The problem: current code doesn't seem to have the logic to detect such cases. The submitted patch disables LooseScan for apparently invalid cases where the WHERE condition covers a column while range condition does not, which means that condition (***) is certainly unmet. However, cases like (C1) are still not handled. Further comments are inline. On Wed, Dec 07, 2011 at 02:18:02PM +0200, Timour Katchaounov wrote: > Could you please review the below patch. > > Timour > > ----------------------------------------------------------- > revno: 3335 > revision-id: timour(a)askmonty.org-20111207115332-3oa536gbt20r22po > parent: igor(a)askmonty.org-20111206214218-lev0vyidyt8h3431 > fixes bug(s): https://launchpad.net/bugs/825075 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Wed 2011-12-07 13:53:32 +0200 > message: > Fix bug lp:825075 > > Analys: > The cause for the wrong result was that the optimizer > incorrectly chose min/max loose scan when it is not > applicable. The applicability test missed the case when > a condition on the MIN/MAX argument was OR-ed with a > condition on some other field. In this case, the MIN/MAX > condition cannot be used for loose scan. > > Solution: > The function check_group_min_max_predicates() duplicated > functionality performed by the range optimizer, but this > duplication was incomplete. The solution is to reuse instead > the analys and the ranges produced by the range optimizer. > If a suitable range could not be extracted for the MIN/MAX > argument, then loose scan is not applicable. > === modified file 'mysql-test/r/group_min_max.result' > --- a/mysql-test/r/group_min_max.result 2011-12-04 21:31:42 +0000 > +++ b/mysql-test/r/group_min_max.result 2011-12-07 11:53:32 +0000 > @@ -2103,7 +2103,7 @@ id select_type table type possible_keys > explain select a1,a2,b,min(c),max(c) from t2 > where (c > 'a000') and (c <= 'd999') and (c like '_8__') group by a1,a2,b; > id select_type table type possible_keys key key_len ref rows Extra > -1 SIMPLE t2 index NULL idx_t2_1 163 NULL 164 Using where; Using index > +1 SIMPLE t2 range NULL idx_t2_1 163 NULL 33 Using where; Using index for group-by > explain select a1, a2, b, c, min(d), max(d) from t1 group by a1,a2,b,c; > id select_type table type possible_keys key key_len ref rows Extra > 1 SIMPLE t1 ALL NULL NULL NULL NULL 128 Using temporary; Using filesort Why there is no testcase from the bug report? I think it's better to have a testcase that - will explicitly mention BUG# - will show the wrong query result. A changed EXPLAIN in some irrelevant test is a too poor coverage. > === modified file 'sql/opt_range.cc' > --- a/sql/opt_range.cc 2011-11-18 17:35:51 +0000 > +++ b/sql/opt_range.cc 2011-12-07 11:53:32 +0000 > @@ -11984,164 +11996,41 @@ get_best_group_min_max(PARAM *param, SEL > } > > > -/* > - Check that the MIN/MAX attribute participates only in range predicates > - with constants. > - > - SYNOPSIS > - check_group_min_max_predicates() > - cond tree (or subtree) describing all or part of the WHERE > - clause being analyzed > - min_max_arg_item the field referenced by the MIN/MAX function(s) > - min_max_arg_part the keypart of the MIN/MAX argument if any > - > - DESCRIPTION > - The function walks recursively over the cond tree representing a WHERE > - clause, and checks condition (SA3) - if a field is referenced by a MIN/MAX > - aggregate function, it is referenced only by one of the following > - predicates: {=, !=, <, <=, >, >=, between, is null, is not null}. > +/** > + Find the range tree for the field that is an argument of MIN/MAX. > > - RETURN > - TRUE if cond passes the test > - FALSE o/w > + @param cond The WHERE clause of the query > + @param min_max_arg_item The field referenced by the MIN/MAX function(s) > + @param index_tree Range tree for the chosen index > + > + @note > + The function iterates over the range trees for each keypart of the > + chosen index until it finds the range for the MIN/MAX keypart. > + > + @retval > + If there is a range for the MIN/MAX argument > + @retval > + NULL if there is no range > */ > > -static bool > -check_group_min_max_predicates(Item *cond, Item_field *min_max_arg_item, > - Field::imagetype image_type) > +static SEL_ARG * > +get_min_max_range(Item *cond, Item_field *min_max_arg_item, SEL_ARG *index_tree) > { > - DBUG_ENTER("check_group_min_max_predicates"); > - DBUG_ASSERT(cond && min_max_arg_item); > - > + if (!cond || !min_max_arg_item) > + return NULL; > cond= cond->real_item(); So we've got: get_min_max_range(Item *cond, Item_field *min_max_arg_item, SEL_ARG *index_tree) { if (!cond || !min_max_arg_item) return NULL; cond= cond->real_item(); 'cond' is passed as parameter, checked, modified, and .. then never used in the function. Please fix this. > - Item::Type cond_type= cond->real_type(); > - if (cond_type == Item::COND_ITEM) /* 'AND' or 'OR' */ > - { > - DBUG_PRINT("info", ("Analyzing: %s", ((Item_func*) cond)->func_name())); > - List_iterator_fast<Item> li(*((Item_cond*) cond)->argument_list()); > - Item *and_or_arg; > - while ((and_or_arg= li++)) > - { > - if (!check_group_min_max_predicates(and_or_arg, min_max_arg_item, > - image_type)) > - DBUG_RETURN(FALSE); > - } > - DBUG_RETURN(TRUE); > - } > - > - /* > - Disallow loose index scan if the MIN/MAX argument field is referenced by > - a subquery in the WHERE clause. > - */ > - > - if (cond_type == Item::SUBSELECT_ITEM) > - { > - Item_subselect *subs_cond= (Item_subselect*) cond; > - if (subs_cond->is_correlated) > - { > - DBUG_ASSERT(subs_cond->upper_refs.elements > 0); > - List_iterator_fast<Item_subselect::Ref_to_outside> > - li(subs_cond->upper_refs); > - Item_subselect::Ref_to_outside *dep; > - while ((dep= li++)) > - { > - if (dep->item->eq(min_max_arg_item, FALSE)) > - DBUG_RETURN(FALSE); > - } > - } > - DBUG_RETURN(TRUE); > - } > - > /* > - Condition of the form 'field' is equivalent to 'field <> 0' and thus > - satisfies the SA3 condition. > + Extract the SEL_ARG subtree that contains only ranges for the MIN/MAX > + attribute. > */ > - if (cond_type == Item::FIELD_ITEM) > + SEL_ARG *min_max_range= index_tree; > + while (min_max_range) /* Find the tree for the MIN/MAX key part. */ > { > - DBUG_PRINT("info", ("Analyzing: %s", cond->full_name())); > - DBUG_RETURN(TRUE); > - } > - > - /* We presume that at this point there are no other Items than functions. */ > - DBUG_ASSERT(cond_type == Item::FUNC_ITEM); > - > - /* Test if cond references only group-by or non-group fields. */ > - Item_func *pred= (Item_func*) cond; > - Item **arguments= pred->arguments(); > - Item *cur_arg; > - DBUG_PRINT("info", ("Analyzing: %s", pred->func_name())); > - for (uint arg_idx= 0; arg_idx < pred->argument_count (); arg_idx++) > - { > - cur_arg= arguments[arg_idx]->real_item(); > - DBUG_PRINT("info", ("cur_arg: %s", cur_arg->full_name())); > - if (cur_arg->type() == Item::FIELD_ITEM) > - { > - if (min_max_arg_item->eq(cur_arg, 1)) > - { > - /* > - If pred references the MIN/MAX argument, check whether pred is a range > - condition that compares the MIN/MAX argument with a constant. > - */ > - Item_func::Functype pred_type= pred->functype(); > - if (pred_type != Item_func::EQUAL_FUNC && > - pred_type != Item_func::LT_FUNC && > - pred_type != Item_func::LE_FUNC && > - pred_type != Item_func::GT_FUNC && > - pred_type != Item_func::GE_FUNC && > - pred_type != Item_func::BETWEEN && > - pred_type != Item_func::ISNULL_FUNC && > - pred_type != Item_func::ISNOTNULL_FUNC && > - pred_type != Item_func::EQ_FUNC && > - pred_type != Item_func::NE_FUNC) > - DBUG_RETURN(FALSE); > - > - /* Check that pred compares min_max_arg_item with a constant. */ > - Item *args[3]; > - bzero(args, 3 * sizeof(Item*)); > - bool inv; > - /* Test if this is a comparison of a field and a constant. */ > - if (!simple_pred(pred, args, &inv)) > - DBUG_RETURN(FALSE); > - > - /* Check for compatible string comparisons - similar to get_mm_leaf. */ > - if (args[0] && args[1] && !args[2] && // this is a binary function > - min_max_arg_item->result_type() == STRING_RESULT && > - /* > - Don't use an index when comparing strings of different collations. > - */ > - ((args[1]->result_type() == STRING_RESULT && > - image_type == Field::itRAW && > - ((Field_str*) min_max_arg_item->field)->charset() != > - pred->compare_collation()) > - || > - /* > - We can't always use indexes when comparing a string index to a > - number. > - */ > - (args[1]->result_type() != STRING_RESULT && > - min_max_arg_item->field->cmp_type() != args[1]->result_type()))) > - DBUG_RETURN(FALSE); > - } > - } > - else if (cur_arg->type() == Item::FUNC_ITEM) > - { > - if (!check_group_min_max_predicates(cur_arg, min_max_arg_item, > - image_type)) > - DBUG_RETURN(FALSE); > - } > - else if (cur_arg->const_item()) > - { > - /* > - For predicates of the form "const OP expr" we also have to check 'expr' > - to make a decision. > - */ > - continue; > - } > - else > - DBUG_RETURN(FALSE); > + if (min_max_range->field->eq(min_max_arg_item->field)) > + break; > + min_max_range= min_max_range->next_key_part; > } > - > - DBUG_RETURN(TRUE); > + return min_max_range; > } > > BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 2

[Maria-developers] Preparing to release MariaDB 5.3.4-rc
by Daniel Bartholomew 31 Jan '12

31 Jan '12

All, Monty has informed me that we are ready to release MariaDB 5.3.4-rc. I'm uploading the packages to the primary mirror now and if all goes well the general release announcement will go out tomorrow morning (my time). The source tree has not been tagged yet but the release is from revision 3402: http://bazaar.launchpad.net/~maria-captains/maria/5.3/changes To all the devs: If there is anything notable which I should make sure to include in the release notes, please let me know ASAP. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] Is our annotate_rows_log_event same as mysql-5.6's?
by Kristian Nielsen 31 Jan '12

31 Jan '12

Sergei Petrunia <psergey(a)askmonty.org> writes: > Also, it seems that right now binary logs are not compatible between mysql-5.6 > and mariadb-5.3. When I try read one file with mysqlbinlog of the other I get > this: > > > mariadb-5.3 reading binlog from mysql-5.6 > #120131 2:43:14 server id 1 end_log_pos 295 Query thread_id=2 exec_time=0 error_code=0 > SET TIMESTAMP=1327963394/*!*/; > BEGIN > /*!*/; > ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 62, event_type: 29 > ERROR: Could not read entry at offset 295: Error in log format or read error. Yes, 29 is ROWS_QUERY_LOG_EVENT, their version of annotate_rows_log_event. I think you will find the same problem if you try to read with MySQL 5.1 or 5.5. I believe this only happens if you enable row annotation events on the master; it seems a general thing that if one enables a new feature on a MySQL master, it breaks old slaves. However, when we merge 5.6, we get the new IGNORABLE_LOG_EVENT flag, which allows a newer master (eg. 5.7) to inform an old slave that it is ok to ignore a specific event. When we merge 5.6, I suppose we will just make sure MariaDB 5.6 writes the MySQL event code on the master, and understands the MariaDB event code on the slave, so this will be solved. > Mysql 5.6 reading mariadb-5.3 > ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 48, event_type: -96 > ERROR: Could not read entry at offset 503: Error in log format or read error. > # at 434 > #120131 2:01:47 server id 1 end_log_pos 503 Query thread_id=1 exec_time=0 error_code=0 > SET TIMESTAMP=1327960907/*!*/; > BEGIN And this is the reverse situation, -96 is our ANNOTATE_ROWS_EVENT, which is not understood by MySQL. Again, this only happens when row annotation is explicitly enabled on the master, so one should not do this when having old slaves connected (whether MySQL or MariaDB). There is a deeper issue here. It is not possible on the master to simply filter out the events that an old slave does not understand, as would seem natural. Because the current slave code gets confused when there are "holes" in the binlog positions it receives from the master. In MariaDB 5.5 this will be fixed (if I'm allowed to push MWL#234 ...), allowing a MariaDB slave to adjust binlog positions correctly if the master filters out events. But this does not help MySQL slaves of course. Also, global transaction IDs, which MySQL@Oracle says they are working on, should fix this, but this is not in 5.6 currently. Thanks for taking up these subjects, it's good to get them more clearly understood! - Kristian.

1 0

Re: [Maria-developers] Is our annotate_rows_log_event same as mysql-5.6's?
by Kristian Nielsen 31 Jan '12

31 Jan '12

Sergei Petrunia <psergey(a)askmonty.org> writes: > I see MySQL have added an analog ours > http://kb.askmonty.org/en/annotate_rows_log_event > > http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#… > > The names of the options are different: binlog_annotate_row_events vs. binlog_rows_query_log_events > Questions (I assume you can answer them off the top of the head, if not, let's > first discuss it) > > - Is it true that they have re-implemented the feature after we did? Yes. > - Do I understand correctly that the features are not compatible? (different > event code) Yes. However, I checked the MySQL version some time ago. It is extremely similar to our version. I believe it will be quite feasible when merging to make them compatible, eg. just translate the event code from one to the other. Maybe we will just merge the MySQL version for compatibility (MySQL developers do not seem to care about compatibility themselves), and then just add backwards and forwards compatibility translation so we work with old versions of MariaDB. > - Do these features do the same thing or one is better than the other in some > respect? As I remember, they are essentially identical. - Kristian.

1 0

[Maria-developers] alternative for Field_timestamp::get_timestamp etc. ?
by Kazuhiko 30 Jan '12

30 Jan '12

Hello, I tried to build mroonga-1.3.0 ( http://mroonga.github.com/ ) with MariaDB 5.3.3 and got the following error: > g++ -DHAVE_CONFIG_H -I. -I/opt/mariadb__compile__/mariadb-5.3.3-rc/sql -I/opt/mariadb__compile__/mariadb-5.3.3-rc/include -I/opt/mariadb__compile__/mariadb-5.3.3-rc/regex -I/opt/mariadb__compile__/mariadb-5.3.3-rc -I/opt/mariadb/include/mysql -I/opt/groonga/include/groonga -I/opt/groonga/include/groonga -I/opt/mariadb/include/mysql -g -DUNIV_LINUX -g -O2 -Wall -Wextra -Wno-unused-parameter -Wno-strict-aliasing -Werror -fno-implicit-templates -fno-exceptions -fno-rtti -felide-constructors -MT libmroonga_a-ha_mroonga.o -MD -MP -MF .deps/libmroonga_a-ha_mroonga.Tpo -c -o libmroonga_a-ha_mroonga.o `test -f 'ha_mroonga.cc' || echo './'`ha_mroonga.cc > ha_mroonga.cc: In member function ‘int ha_mroonga::generic_store_bulk_timestamp(Field*, grn_obj*)’: > ha_mroonga.cc:6935:63: error: no matching function for call to ‘Field_timestamp::get_timestamp(my_bool*)’ > ha_mroonga.cc:6935:63: note: candidate is: > /opt/mariadb__compile__/mariadb-5.3.3-rc/sql/field.h:1221:21: note: virtual my_time_t Field_timestamp::get_timestamp(ulong*) const > /opt/mariadb__compile__/mariadb-5.3.3-rc/sql/field.h:1221:21: note: no known conversion for argument 1 from ‘my_bool* {aka char*}’ to ‘ulong* {aka long unsigned int*}’ > ha_mroonga.cc: In member function ‘void ha_mroonga::storage_store_field_timestamp(Field*, const char*, uint)’: > ha_mroonga.cc:7234:20: error: ‘class Field_timestamp’ has no member named ‘store_timestamp’ > ha_mroonga.cc: In member function ‘void ha_mroonga::storage_store_field_datetime(Field*, const char*, uint)’: > ha_mroonga.cc:7286:67: error: no matching function for call to ‘Field_datetime::store_time(MYSQL_TIME*, enum_mysql_timestamp_type)’ > ha_mroonga.cc:7286:67: note: candidate is: > /opt/mariadb__compile__/mariadb-5.3.3-rc/sql/field.h:209:7: note: int Field::store_time(MYSQL_TIME*) > /opt/mariadb__compile__/mariadb-5.3.3-rc/sql/field.h:209:7: note: candidate expects 1 argument, 2 provided > ha_mroonga.cc: In member function ‘void ha_mroonga::storage_store_field_new_date(Field*, const char*, uint)’: > ha_mroonga.cc:7306:62: error: no matching function for call to ‘Field_newdate::store_time(MYSQL_TIME*, enum_mysql_timestamp_type)’ > ha_mroonga.cc:7306:62: note: candidate is: > /opt/mariadb__compile__/mariadb-5.3.3-rc/sql/field.h:209:7: note: int Field::store_time(MYSQL_TIME*) > /opt/mariadb__compile__/mariadb-5.3.3-rc/sql/field.h:209:7: note: candidate expects 1 argument, 2 provided > make[2]: *** [libmroonga_a-ha_mroonga.o] Error 1 (you can see the code at https://github.com/mroonga/mroonga/blob/master/ha_mroonga.cc ) At a glance, sql/field.h seems much different from MySQL-5.1's one. What can be the alternative for the followings ? * Field_timestamp::get_timestamp(my_bool*) * Field_datetime::store_time(MYSQL_TIME*, enum_mysql_timestamp_type) * Field_newdate::store_time(MYSQL_TIME*, enum_mysql_timestamp_type) Thanks in advance. Kazuhiko

2 2

Re: [Maria-developers] [Commits] Rev 3398: Make testcase stable by adding --sorted_result for SHOW STATUS commands. in file:///home/psergey/dev2/5.3-look48/
by Sergei Golubchik 28 Jan '12

28 Jan '12

Hi, Sergey! What do you mean? SHOW STATUS returns a sorted list of variables. On Jan 27, Sergey Petrunya wrote: > At file:///home/psergey/dev2/5.3-look48/ > > revno: 3398 > revision-id: psergey(a)askmonty.org-20120127135140-4ues2tk6juf4iynx > parent: psergey(a)askmonty.org-20120126102034-tp33uzyuqnyk30mn > committer: Sergey Petrunya <psergey(a)askmonty.org> > branch nick: 5.3-look48 > timestamp: Fri 2012-01-27 17:51:40 +0400 > message: > Make testcase stable by adding --sorted_result for SHOW STATUS commands. Regards, Sergei

2 2

Re: [Maria-developers] [Commits] Rev 3241: Xtradb recently started to access thd members directly , e.g thd->stmt_da (ha_innodb.cc) in file:///H:/bzr/5.5/
by Kristian Nielsen 27 Jan '12

27 Jan '12

Vladislav Vaintroub <wlad(a)montyprogram.com> writes: > Xtradb recently started to access thd members directly ,e.g thd->stmt_da (ha_innodb.cc) > It needs recompilation for embedded server, as layout of THD is different in embedded. Did you consider instead fixing XtraDB to not access thd members directly? Eg. using proper accessors, maybe adding new accessors if needed? Or is this not possible for some reason? It would be much preferable if XtraDB didn't mess with server internals like this ... - Kristian.

3 2

[Maria-developers] mysql_client_test
by Kristian Nielsen 25 Jan '12

25 Jan '12

Just to finish our discussions on IRC... I found that mysql_client_test.test runs fine without any --plugin-dir=xxx option at all for mysql_client_test. The reason is that the correct option is in the my.cnf that we generate. So I decided to just remove the --plugin-dir option from the command line in mysql_client_test.test; this seems to work both when tested from source dir and when testing installed server. - Kristian.

1 0

[Maria-developers] Need help re. which files to include in 5.5 .debs
by Kristian Nielsen 25 Jan '12

25 Jan '12

Hi Serg, As you suggested, I compared .deb file contents with what `make install` produces in 5.5. I discovered that the following files are missing from .debs. I need help understanding which of these should be added to the .debs. (I think anything added should be to package libmariadbclient-dev): /usr/lib/libmysqlservices.a /usr/include/mysql.h /usr/include/mysql_com.h /usr/include/mysqld_ername.h /usr/include/mysqld_error.h /usr/include/mysql_embed.h /usr/include/mysql/psi /usr/include/mysql/psi/mysql_file.h /usr/include/mysql/psi/mysql_thread.h /usr/include/mysql/psi/psi_abi_v1.h /usr/include/mysql/psi/psi_abi_v2.h /usr/include/mysql/psi/psi.h /usr/include/client_plugin.h /usr/include/decimal.h /usr/include/errmsg.h /usr/include/keycache.h /usr/include/m_ctype.h /usr/include/m_string.h /usr/include/my_alloc.h /usr/include/my_attribute.h /usr/include/my_compiler.h /usr/include/my_dbug.h /usr/include/my_getopt.h /usr/include/my_global.h /usr/include/my_list.h /usr/include/my_net.h /usr/include/my_pthread.h /usr/include/mysql_time.h /usr/include/mysql_version.h /usr/include/my_sys.h /usr/include/my_valgrind.h /usr/include/my_xml.h /usr/include/plugin_audit.h /usr/include/plugin_auth.h /usr/include/plugin_ftparser.h /usr/include/plugin.h /usr/include/sql_common.h /usr/include/sql_state.h /usr/include/sslopt-case.h /usr/include/sslopt-longopts.h /usr/include/sslopt-vars.h /usr/include/typelib.h It seems pretty obvious that "mysql.h" is needed. But should I add _all_ the .h files? And what about libmysqlservices.a? - Kristian.

2 5

Re: [Maria-developers] something better than PMP
by Kristian Nielsen 25 Jan '12

25 Jan '12

Arun Sharma <asharma(a)fb.com> writes: > On 1/21/12 7:24 AM, Mark Callaghan wrote: >> 1 millisecond per thread would be much better than what we experience >> today. >> > > Is there a reason why latency per-thread is more interesting than the > absolute number? You are right of course - the interesting number is the time we spent with the target mysqld process suspended (stalled) under ptrace(). The reason I think in terms of latency-per-thread is this: Different mysqld instances can have widely different number of threads - from a few handful to perhaps thousands. Since we loop over threads while the process is ptrace()-suspended, it seems a nice measure to estimate the cost independent of number of threads in the process. >>> Arun: What I've done so far is mostly to cache reads of the same word, and >>> delay name resolve to after the target process is resumed. I think it can >>> be >>> made even faster by reading target process memory through /proc/PID/mem >>> instead of ptrace and if we can reduce repeated reads of /proc/PID/maps >>> and >>> such. > > Sounds like a good optimization to have. There is already a cache > internal to libunwind that maps a given IP address to it's unwind > info. If the repeated reads come from that code path, tweaking the > cache size might be a simpler fix. Ok, that sounds cool! - Kristian.

1 0