[Maria-developers] microslow-innodb ported to 5.1
Hi, We already ported patch http://www.percona.com/mysql/5.0.77-b13/patches/microslow_innodb.patch (from list http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL#What_kind_of_patches... ) to 5.1, so it will be easy to include it into MariaDB. I will propose merge soon, so let's do not duplicate work if you are going to look into this patch also. -- Vadim Tkachenko, CTO Percona Inc. ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403 MySQL Performance Blog - http://www.mysqlperformanceblog.com MySQL Consulting http://www.percona.com/
Hi Vadim On 28/05/2009, at 1:22 AM, Vadim Tkachenko wrote:
We already ported patch http://www.percona.com/mysql/5.0.77-b13/patches/microslow_innodb.patch (from list http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL#What_kind_of_patches... )
to 5.1, so it will be easy to include it into MariaDB.
I will propose merge soon, so let's do not duplicate work if you are going to look into this patch also.
Ah, excellent! Cheers, Arjen. -- Arjen Lentz, Director @ Open Query (http://openquery.com) Affordable Training and ProActive Support for MySQL & related technologies Follow our blog at http://openquery.com/blog/ OurDelta: free enhanced builds for MySQL @ http://ourdelta.org
Hi!
"Arjen" == Arjen Lentz <arjen@openquery.com> writes:
Arjen> Hi Vadim Arjen> On 28/05/2009, at 1:22 AM, Vadim Tkachenko wrote:
We already ported patch http://www.percona.com/mysql/5.0.77-b13/patches/microslow_innodb.patch (from list http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL#What_kind_of_patches... )
to 5.1, so it will be easy to include it into MariaDB.
I will propose merge soon, so let's do not duplicate work if you are going to look into this patch also.
Arjen> Ah, excellent! Yes, great! I could look at include this patch the incomming Friday. Where can I find it ? Regards, Monty
Monty, I made merge proposal: https://code.launchpad.net/~maria-captains/maria/slow-extended-patch/+merge/... You can find patch there. Best, Vadim Michael Widenius wrote:
Hi!
"Arjen" == Arjen Lentz <arjen@openquery.com> writes:
Arjen> Hi Vadim Arjen> On 28/05/2009, at 1:22 AM, Vadim Tkachenko wrote:
We already ported patch http://www.percona.com/mysql/5.0.77-b13/patches/microslow_innodb.patch (from list http://askmonty.org/wiki/index.php/MariaDB_versus_MySQL#What_kind_of_patches... )
to 5.1, so it will be easy to include it into MariaDB.
I will propose merge soon, so let's do not duplicate work if you are going to look into this patch also.
Arjen> Ah, excellent!
Yes, great!
I could look at include this patch the incomming Friday. Where can I find it ?
Regards, Monty
-- Vadim Tkachenko, CTO Percona Inc. ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403 MySQL Performance Blog - http://www.mysqlperformanceblog.com MySQL Consulting http://www.percona.com/
Hi, Vadim! On May 27, Vadim Tkachenko wrote:
Monty,
I made merge proposal:
https://code.launchpad.net/~maria-captains/maria/slow-extended-patch/+merge/...
You can find patch there.
Eh, I certainly hope it won't be merged in its current form. I didn't look too far, but even the very first lines:
=== modified file 'include/mysql/plugin.h' --- include/mysql/plugin.h 2008-04-28 16:24:05 +0000 +++ include/mysql/plugin.h 2009-05-28 05:00:21 +0000 @@ -687,6 +687,16 @@ const char *set_thd_proc_info(MYSQL_THD, const char * info, const char *func, const char *file, const unsigned int line);
+void increment_thd_innodb_stats(MYSQL_THD thd, + long io_reads, + long long io_read, + long io_reads_wait_timer, + long lock_que_wait_timer, + long que_wait_timer, + long page_access); +unsigned long thd_log_slow_verbosity(const MYSQL_THD thd); +int thd_opt_slow_log();
Like, hello ? increment_thd_innodb_stats in plugin.h ? Really ? Any arbitrary plugin (as plugin.h is a generic, common to all plugins, header) may have an urgent need of incrementing InnoDB statistics ? May I call it from my ftparser plugin, please ? Regards, Sergei P.S.: And below I've seen thd->innodb_* something, why not thd->seqengine, for example (http://seqengine.org/) ? We have to hard-code in THD statistics fields for any possible storage engine out there ?
Sergei, Yes, I understand this is not best implementation, however is there any other way to have per-thread statistics for plugin and then have access to it to write to slow-log ? Correct implementation may require changes in plugin interface, but I am open for recommendations. Thanks! Vadim Sergei Golubchik wrote:
Hi, Vadim!
On May 27, Vadim Tkachenko wrote:
Monty,
I made merge proposal:
https://code.launchpad.net/~maria-captains/maria/slow-extended-patch/+merge/...
You can find patch there.
Eh, I certainly hope it won't be merged in its current form. I didn't look too far, but even the very first lines:
=== modified file 'include/mysql/plugin.h' --- include/mysql/plugin.h 2008-04-28 16:24:05 +0000 +++ include/mysql/plugin.h 2009-05-28 05:00:21 +0000 @@ -687,6 +687,16 @@ const char *set_thd_proc_info(MYSQL_THD, const char * info, const char *func, const char *file, const unsigned int line);
+void increment_thd_innodb_stats(MYSQL_THD thd, + long io_reads, + long long io_read, + long io_reads_wait_timer, + long lock_que_wait_timer, + long que_wait_timer, + long page_access); +unsigned long thd_log_slow_verbosity(const MYSQL_THD thd); +int thd_opt_slow_log();
Like, hello ? increment_thd_innodb_stats in plugin.h ? Really ? Any arbitrary plugin (as plugin.h is a generic, common to all plugins, header) may have an urgent need of incrementing InnoDB statistics ? May I call it from my ftparser plugin, please ?
Regards, Sergei
P.S.: And below I've seen thd->innodb_* something, why not thd->seqengine, for example (http://seqengine.org/) ? We have to hard-code in THD statistics fields for any possible storage engine out there ?
-- Vadim Tkachenko, CTO Percona Inc. ICQ: 369-510-335, Skype: vadimtk153, Phone +1-888-401-3403 MySQL Performance Blog - http://www.mysqlperformanceblog.com MySQL Consulting http://www.percona.com/
Hi, Vadim! On May 28, Vadim Tkachenko wrote:
Yes, I understand this is not best implementation, however is there any other way to have per-thread statistics for plugin and then have access to it to write to slow-log ?
per-thread statistics - yes. writing to the slow log, no, plugins cannot affect what's written into the slow log.
Correct implementation may require changes in plugin interface, but I am open for recommendations.
What about an option to write SHOW STATUS to the slow log ? Only the differences since the last query, to reduce the amount of noise in the log. (this is similar to the WL#4906, that I've recently created) Regards / Mit vielen Grüßen, Sergei -- __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@sun.com> / /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect /_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028 <___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring
Hi, What is about adding these items as per thread variables and making it possible to specify which per thread variables increments for the query are to be logged in the slow query log ? I should highlight this information availability in the logs is very important for our performance optimization processes. Sergei Golubchik wrote:
Hi, Vadim!
On May 28, Vadim Tkachenko wrote:
Yes, I understand this is not best implementation, however is there any other way to have per-thread statistics for plugin and then have access to it to write to slow-log ?
per-thread statistics - yes.
writing to the slow log, no, plugins cannot affect what's written into the slow log.
Correct implementation may require changes in plugin interface, but I am open for recommendations.
What about an option to write SHOW STATUS to the slow log ? Only the differences since the last query, to reduce the amount of noise in the log. (this is similar to the WL#4906, that I've recently created)
Regards / Mit vielen Grüßen, Sergei
Hi!
"Peter" == Peter Zaitsev <pz@percona.com> writes:
Peter> Hi, Peter> What is about adding these items as per thread variables and making it Peter> possible to specify which per thread variables increments for the query Peter> are to be logged in the slow query log ? Good idea. Need to think a bit of how one could most easily specify in .my.cnf which variables should be logged. Will suggest how one could do this in a worklog item next week. Peter> I should highlight this information availability in the logs is very Peter> important for our performance optimization processes. Regards, Monty
Hi, Peter! On Jun 03, Peter Zaitsev wrote:
What is about adding these items as per thread variables and making it possible to specify which per thread variables increments for the query are to be logged in the slow query log ?
Should be possible, yes. Although I think it would be easier to log all changes session status variables, without an option to specify what variables to log. As I presume that most of this information will be relevant in most of the cases, and covering the rest with the extra configuration option isn't worth the added complexity (actual and percieved). Regards / Mit vielen Grüßen, Sergei -- __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@sun.com> / /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect /_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028 <___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring
Hei!
"Sergei" == Sergei Golubchik <sergii@pisem.net> writes:
Sergei> Hi, Peter! Sergei> On Jun 03, Peter Zaitsev wrote:
What is about adding these items as per thread variables and making it possible to specify which per thread variables increments for the query are to be logged in the slow query log ?
Sergei> Should be possible, yes. Sergei> Although I think it would be easier to log all changes session status Sergei> variables, without an option to specify what variables to log. Sergei> As I presume that most of this information will be relevant in most of Sergei> the cases, and covering the rest with the extra configuration option Sergei> isn't worth the added complexity (actual and percieved). Over time we will have more and more variables and I don't think it makes sense to log all changes to the slow log. I don't think it's hard to maintain a list of what to log. Regards, Monty
OK. This is reasonable. So why do not we convert our current Innodb and execution plan items to status variables and do not get this functionality to write them to the log
Over time we will have more and more variables and I don't think it makes sense to log all changes to the slow log.
I don't think it's hard to maintain a list of what to log.
-- Peter Zaitsev, CEO, Percona Inc. Tel: +1 888 401 3401 ext 501 Skype: peter_zaitsev 24/7 Emergency Line +1 888 401 3401 ext 911
participants (5)
-
Arjen Lentz -
Michael Widenius -
Peter Zaitsev -
Sergei Golubchik -
Vadim Tkachenko