Buy Percona ServicesBuy Now!

Percona build7 with latest patches

 | November 14, 2008 |  Posted In: Percona Software


We made new binaries for MySQL 5.0.67 build 7 which include patches we recently announced.

The -percona release includes:

and -percona-highperf release additionaly includes

You can download RPMs for RedHat / CentOS 4.x and 5.x for x86_64, binaries, sources and patches there

Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.


  • Hi Vadim,

    I’m noticing some issues with the microslow_innodb.patch. I am using a long_query_time of 1000000, yet it is not logging my queries that last longer than a second. I noticed this is version 1.1 and when I was using 1.0 it worked properly. I just wanted to make sure the time is still in microseconds? Also, I noticed when I set the time to 1, then it would log the queries over 1 second in length.


  • I’ve a problem to compile it under Solaris:

    cc -DHAVE_CONFIG_H -I. -I. -I.. -I./../include -I./../../include -I../../include -O -DDBUG_OFF -DDBUG_OFF -fast -DHAVE_RWLOCK_T -DDEBUG_OFF -DUNIV_SOLARIS -c os0file.c
    “os0file.c”, line 1953: undefined struct/union member: io_reads
    “os0file.c”, line 1954: undefined struct/union member: io_read
    “os0file.c”, line 1975: undefined struct/union member: io_reads_wait_timer
    “os0file.c”, line 3523: undefined struct/union member: io_reads
    “os0file.c”, line 3524: undefined struct/union member: io_read
    cc: acomp failed for os0file.c

    Is there any include files are missing? anything else?..
    Thanks in advance for your help!


  • Yes, I used tarballs (both) – and the same error for both tarballs..
    BTW, I saw the same error when earlier I’ve tried to compile the build4, so it did not come recently.


  • dim,

    Hmm… I don’t know why the same files cause error at Solaris and don’t at Linux…

    But, the struct is defined at “trx0trx.h”, so
    If you add

    #include “trx0trx.h”

    to innobase/os/os0file.c , this compiling will succeed.

    Though, the another next error may happen…

  • Well, seems it was more tested with gcc rather Sun compiler 🙂
    And I may confirm – there was no problem to compile on openSUSE 11.0.

    With Sun compiler (SS12) I’ve got another error next on the innodb part, but not with gcc (hard to believe gcc will include a missing file on its own, so I may suppose a different logic in makefiles while gcc is used (all the time then I see “if gcc …” ))

    However, even with using gcc I’m blocked next in pure C++ error on /sql:

    sql_class.h:49: error: expected constructor, destructor, or type conversion before “extern”
    sql_class.h:49: error: expected ,' or ;’ before “extern”
    sql_class.h:59: error: expected constructor, destructor, or type conversion before “extern”
    sql_class.h:59: error: expected ,' or ;’ before “extern”

    And seems something goes wrong with DECLS macros:

    #ifdef __cplusplus
    extern ulonglong frequency;
    #ifdef __cplusplus

    (same error with SS12 too)

    Any idea?..


  • Just in case: Is it possible the problem is coming from GCC version difference?..
    On Suse I’ve gcc-4.3 and on Solaris gcc-3.4.3. Did you compile already your code with gcc3 ?..


  • You know what?

    I’ve added explicitly into sql_class.hh:

    #undef __BEGIN_DECLS
    #undef __END_DECLS
    #ifdef __cplusplus
    # define __BEGIN_DECLS extern “C” {
    # define __END_DECLS }
    # define __BEGIN_DECLS /* empty */
    # define __END_DECLS /* empty */

    And it worked! :-))

    Then I got an error about missing “strsep” function in, so
    I’ve found and added a following code:

    *strsep(char **stringp, const char *delim)
    char *res;

    if (!stringp || !*stringp || !**stringp)
    return (char*)0;

    res = *stringp;
    while(**stringp && !strchr(delim, **stringp))

    if (**stringp) {
    **stringp = ”;

    return res;

    Hope it’s ok :-))

    Then at least compiling is finished without errors! :-))

    Now I’ll recompile it again to in 64-bit mode and will see if it’ll not give me a core dump on startup :-)) and then I hope to be able to test it finally :-))


  • Yasufumi,

    how the less or more optimal my.conf file should looks for persona MySQL to keep let’s say 256 aggressive users in read-only mode, and also in read/write (50/50) mode?

    my current conf: (for MySQL 32bit)


    table_cache = 8000
    sort_buffer_size = 2097152




    NOTE: innodb_flush_log_at_trx_commit=0 because I’m interesting first on the scalability limits (then will see which kind of storage will be needed to keep redo writing on the required speed)..

    Thanks a lot for your help!

  • NOTE: I’m asking about config file because currently “persona b7” is performing much worse vs “standard” MySQL 5.0.67 from …
    And I’m very interesting to understand why…


  • Dim,

    To provide optimal my.cnf we should know your workload and server characteristics.
    And what is much worse – can you show some numbers ?

  • I was looking at the 5.1.28 percona build, and I don’t see the INNODB_BUFFER_POOL_CONTENT table in information schema – did that come after? My “show patches” command only shows “show_patches.patch”

    I’m really looking forward to seeing a 5.1.30 percona build in the very near future, as certain people are promising this will be GA in the next couple of weeks.

  • Vadim,

    My DB server: 48 cores, SPARC64-VII 2500Mhz, 192GB RAM
    Injector is a similar server; Gbit connection between injector and DB;

    1. read-only: 2 simple selects per “transaction”
    2. read-write: 2 simple selects per “transaction” + delete/insert/update of a single row

    no logical contention between queries;
    load is progressively increased from: 1 2 4 8 16 32 64 128 and 256 concurrent sessions;

    Test is running currently (comparing 5.0.67, 5.1.29, 6.0.7, and 5.0.67-persona); I’ll give you a real numbers by Monday.


  • dim,

    Honestly, “I think (The other people may not so)”,
    -percona version (even -percona-highperf) may be always slower than normal MySQL.
    We should choose and discard patches of -percona to get more performance…
    Some of the patches must cause performance regression.


    I think you should check the build tree of -highperf if you use.

    innobase/ib_config.h contains

    If it is “0”, there may be almost no effect of -highperf.
    It means the GCC doesn’t support the builtin feature of atomic operations.

  • Yasufumi,

    Actually I think the only userstats can be problem, as Google confirmed mutex contention.

    But this is task for you to found regression, I hope you will solve it 🙂

  • Yasufumi,

    I have:

    so it should be ok for -highperf effect 🙂

    Few numbers so well comparing “standard” vs “persona” MySQL 5.0.67:
    – data load is at least x2 times faster with “persona”
    – index creation is at least x2 times faster with “persona”

    Workload tests – my initial “much worse” observation was due cold cache – now each test is replayed several times to compare “apples to apples”..

    But so well:
    – read-only test:
    – 3000 tps max for “persona”
    – 3500 tps max for “standard”

    – read+write test:
    – 2800 tps for “persona” (+ much more stable)
    – 2500 tps for “standard”

    But testing is still continuing- I’ve found MySQL is keeping workload much(!) more better with “nnodb_thread_concurrency=8” rather “0” – it creating so many mutex contentions during processing – seems it’s better to limit an active number of running threads from the InnoDB side rather to leave them in the savage battle 🙂


  • Dim,

    Ok Thank you for sharing results!
    We are looking to fix some regressions in -percona.

    I think comments there not good place to communicate back and forth – I have some questions to you – can you drop me email to vadim at percona

  • If I want to patch a pristine mysql src tree, in what order should I apply the patches? I am seeing failures on innodb_io_pattern.patch when applying them in the order listed above.

  • Aman,

    Order of patches is:


Comments are closed