Open Source Databases on Big Machines: Does READ COMMITTED Scale on 144 Cores?Sveta Smirnova
In the second post in my series on open source databases on big machines, we’ll look at whether READ COMMITTED scales with multiple cores.
The default transaction level for InnoDB is REPEATABLE READ. A more permissive level is READ COMMITTED, and is known to work well. While the REPEATABLE READ level maintains the transaction history up to the start of the transaction, READ COMMITTED maintains the transaction history up to the start of the current statement. Peter Zaitsev described the differences between how these modes are handled in this blog post. Both can theoretically cause performance slowdowns, but READ COMMITTED is usually seen as fast-working – at least on a typical MySQL machine (owned by Percona):
The default transaction isolation mode for PostgreSQL is also READ COMMITTED. Originally I wanted to use this mode for MySQL tests as well. But when I tested on a machine with 144 cores, I found that after 36 threads REPEATABLE READ continued to scale while READ COMMITTED slowed down. It then got stuck at about 3x slower results for standard OLTP RW tests.
I tested this originally with Percona Server 5.7.15 and recently re-tested with Oracle’s MySQL versions 5.6.35 and 5.7.17. I confirmed that the bug exists in these versions as well, and reported it. I the Oracle MySQL Team fixes it. The good news is that while 5.6 stopped scaling after 16 threads, 5.7 improves this to 36 threads.
Results for 5.6.35:
Results for 5.7.17:
Processors: physical = 4, cores = 72, virtual = 144, hyperthreading = yes
Disk speed: about 3K IOPS
OS: CentOS 7.1.1503
File system: XFS
Percona machine (test for Percona 5.7.15 server):
Processors: physical = 2, cores = 12, virtual = 24, hyperthreading = yes
Disk speed: about 33K IOPS
OS: Ubuntu 14.04.5 LTS
File system: EXT4
Test: SysBench OLTP RW test, converted to use prepared statements, as described in this post.
MySQL Options: described in this post.