Details
Major
Description
We have a report from Otto Kekäläinen that innodb.innodb_simulate_comp_failures_small fails reliably in his installation due to the timeout; also, it fails on some buildbot platforms: bld-dan-debug, bld-dan-release, bintar-rhel7-p8-debug, bintar-rhel7-p8.
I tried to run it on a non-virtual machine without --mem, and got the same issue.
The problem is that individual INSERTs are performed too slowly. We need to modify either the test itself, or its options not to flush after every commit.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
revno: 4365
committer: Jan Lindström <jplindst@mariadb.org>
branch nick: 10.0-innodb
timestamp: Tue 2014-09-02 17:50:09 +0300
message:
MDEV-6682 innodb.innodb_simulate_comp_failures_small is too slow
if it's run on a real disk
Made test smaller.
revno: 4276
committer: Jan Lindström <jplindst@mariadb.org>
branch nick: 5.5
timestamp: Wed 2014-09-03 07:37:13 +0300
message:
MDEV-6682 innodb.innodb_simulate_comp_failures_small is too slow
if it's run on a real disk
Made test smaller.
Generally, there seems to be little point in running tests with --innodb-flush-log-at-trx-commit=1 rather than =2, unless one is specifically testing the --innodb-flush-log-at-trx-commit option.
--innodb-flush-log-at-trx-commit=1 is extremely expensive, as it requires an fsync() for every transaction (even multiple if binlog is enabled). But the effect of an fsync() is completely invisible to an application, it only makes a difference if the OS kernel crashes. So it seems wasteful.
(This problem is not specific to innodb.innodb_simulate_comp_failures_small, but it's particularly relevant here since that test does 1000 individual small transactions, IIRC)
Hmm, I can decrease the number of inserts done, not really sure if durability level change would help always.