Percona build7 with latest patches

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.

Davy

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!

Rgds,
-dim

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 ?..

Rgds,
-Dim

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 }
#else
# define __BEGIN_DECLS /* empty */
# define __END_DECLS /* empty */
#endif

And it worked! :-))

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

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

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

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

if (**stringp) {
**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 :-))

Rgds,
-Dim

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

Rgds,
-Dim

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;

Workload:
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.

Rgds,
-Dim

Aman,

Order of patches is:

show_patches.patch
microslow_innodb.patch
userstatv2.patch
microsec_process.patch
innodb_io_patches.patch
mirror_binlog.patch
mysqld_safe_syslog.patch
innodb_locks_held.patch
innodb_show_bp.patch
innodb_check_fragmentation.patch
innodb_io_pattern.patch
innodb_fsync_source.patch
innodb_show_hashed_memory.patch
split_buf_pool_mutex_fixed_optimistic_safe.patch
innodb_rw_lock.patch