Our test kit is
https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql

OK, I will try dbSTRESS if I will have chance.

Thank you!

20000 in history length is really small.. Is your test kit available somewhere I can download and test it?..

purge_thread is not for improving performance but rather for performance stability (but it’s nice to see the improvement too)

Any chances you may try dbSTRESS workload too? – I’ll be very curious about your observations

Thank you!

Rgds,
-Dimitri

I have checked the history list length and your purge_thread.
The history list length never exceed 20000 during any TPC-C test at the server.
And purge_thread affect 3~4% improve of throughput and it seems to purge aggressively (not exceed 1000).

And about 32 threads, the server has 16 cores and the each thread of the benchmark is full-powered.
So, almost no difference with 16 threads of the equilibrium throughput.

Thank you.

Sorry, what is the point of the post?
The effect of the storage’s write buffer? (twice IO Write/s: Writes to double write buffer are buffered)

Todd,

I uses innodb_file_per_table=true and ext3.
And I think it is local RAID, but I don’t know exact about the server.
Because I can login from remote only…

Thank you.

on my point of view both topics are coming together but well..

another interesting point on flushing: I’ve observed when I have a more wide data set randomizing (and data are reading all the time from disks (mainly random read I/O-bound)) – the more optimal flushing strategy in such situation become to flush by setting a dirty pages limit rather “adaptive” (specially when doublewrite buffer is used (http://dimitrik.free.fr/blog/archives/09-01-2009_09-30-2009.html#93))
Did you observe the same thing?..

Rgds,
-Dimitri

OK. I understand.
But this topics is about the flushing. I think the purging is next problem (though both of them are done by master thread currently…). I will test it soon (also your purge_thread effect). Please wait to discuss about it.

Regards,
Yasufumi

by “critical” I mean a higher load it’s rather more user sessions or higher transaction rates – to see at which moment you’ll start to loop in purge loop (all issues I’ve observed before with dbSTRESS recently were also reproduced with DBT-2, so I’m curious about your case )..

And what about History Length?..

O_DIRECT – I’ve missed this point (as I kept in mind MySQL is still calling fsync() – and you don’t need if when you’re in true Direct I/O)..

BTW, it may be not bad to split it in 2 options: one for redo and another for data files – the I/O nature is different on them, so it make sense..

(And I’m not here to discuss about PG ) but I respect it, it’s just different.. And for a long time before out-performed MySQL, so if we have some things to learn – we should not miss it )

Thank you!

Rgds,
-Dimitri

I know 16GB buffer pool has enough margin to test 10WH TPC-C at least 30 min in this cases…
“critical”? You means also at smaller buffer pool like 5GB or 1GB?
I also will do that.

And you are wrong about O_DIRECT of InnoDB….

http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_flush_method

What you say is feature for PostgreSQL only….
Do you prefer PostgreSQL to MySQL???

(PostgreSQL is one of the RDBMS which has the most strange characteristic of performance for me. I think you should not tune MySQL/InnoDB based on the PostgreSQL tuning knowledge…)

Thank you