Database Performance: MySQL Percona Server 5.7.0

For database benchmarking we still base our testing on Percona server 5.7, an enhanced drop-in replacement for MySQL. But we have updated our SQL benchmarking once again. This time we use Sysbench 1.0.7, which is a lot more efficient than the previous 0.4 and 0.5 versions. As a result, the measured numbers are quite a bit higher, especially on the strongest systems. So you cannot compare this with any similar Sysbench-based benchmarking we have done before.

For our testing we used the read-only OLTP benchmark, which is slightly less realistic, but still much more interesting than most other Sysbench tests. This allows us to measure CPU performance without creating an I/O bottleneck.

Sysbench 1.0.7 on 8 tables

As expected, the EPYC 7601 can not deliver high database performance out of the box. A small database that can be mostly cached in the L3-cache is the worst case scenario for EPYC. That said, there are quite a few tuning opportunities on EPYC. According to AMD, if you enable Memory Interleaving, performance should rise a bit (+10-15%?). Unfortunately, a few days before our deadline our connection to the BMC failed, so we could not try it out. In a later article, we will go deeper into specific tuning for both platforms and test additional database systems.

Nevertheless, our point stands: out of the box is the EPYC CPU a rather mediocre transactional database CPU. With good tuning it is possible EPYC may pass the Xeon v4, but the 8176 is by far the champion here. It will be interesting to measure how EPYC compares in the non-transactional databases (Document stores, Key-value...) but transactional databases will remain Intel territory for now.

Sysbench 1.0.7 95th percentile response time

Typically when high response times were reported, this indicated low single threaded performance. However for EPYC this is not the case. We tested with a database that is quite a bit larger than the 8 MB L3-cache, and the high response time is probably a result of the L3-cache latency.

Multi-Threaded Integer Performance Java Performance
Comments Locked

219 Comments

View All Comments

  • PixyMisa - Tuesday, July 11, 2017 - link

    No, the pricing is correct. The 1P CPUs really are half the price of a single 2P CPU.
  • msroadkill612 - Wednesday, July 12, 2017 - link

    Seems to me, the simplest explanation of something complex, is to list what it will not do, which they will not do :(.

    Can i run a 1p Epyc in a 2p mobo e.g., please?
  • PixyMisa - Thursday, July 13, 2017 - link

    Short answer is no. It might boot, but only half the slots, memory, SATA and so on will be available. Two 1P CPUs won't talk to each other.

    A 2P Epyc will work in a 1P board though.
  • cekim - Tuesday, July 11, 2017 - link

    One glaring bug/feature of AMD's segmentation relative to Intel's is the utter and obvious crippling of clock speeds for all but the absolute top SKUs. Fewer cores should be able to make use of higher clocks within the same TDP envelope. As a result Intel is objectively offering more and better fits up and down the sweep of cores vs clocks vs price spectrum.

    So, the bottom line is AMD is saying that you will have to buy the top-end, 4S SKU to get the top GHz for those applications in your mix that won't benefit from 16,18,32,128 cores.

    I say all of this as someone who desperately wants EPYC to shake things up and force Intel to remove the sand-bags. I know I'm in a small, but non-zero market of users who can make use of dozens of cores, but still need 8 or fewer cores to perform on par with desktop parts for that purpose.
  • KAlmquist - Wednesday, July 12, 2017 - link

    One possibility is that they have only a small percentage of the chips currently being produced bin well enough to be used in the highest clocking SKU's, so they are saving those chips for the most expensive offerings. Admittedly, that depends on what they are seeing coming off the production line. If they have a fair number of chips where with two very good cores, and two not so good, then it would make sense to offer a high clocking 16 core EPYC using chips with two cores disabled. But if clock speed on most chips is limited due to minor registration errors (which would affect the entire chip), then a chip with only two really good cores would require two localized defects in two separate cores, in addition to very good registration to get the two good cores. The combination might be too rare to justify a separate SKU.

    I would expect Global Foundries to continue to tweak its process to get better yields. In that case, more processors would end up in the highest bin, and AMD might decide to launch a higher clock speed 16 and 8 core EPYC processors, mostly using chips which bin well enough that they could have been used for the 32 core EPYC 7601.
  • alpha754293 - Tuesday, July 11, 2017 - link

    Why does the Intel Xeon 6142 cost LESS than the 6142M? (e.g. per the table above, 6142 is shown with a price of $5946 while the 6142M costs $2949)
  • ca197 - Tuesday, July 11, 2017 - link

    I assume that is the wrong way round on the list. I have seen it reported the other way round on other sites.
  • Ian Cutress - Tuesday, July 11, 2017 - link

    You're correct. I've updated the piece, was a misread error from Intel's tables.
  • coder543 - Tuesday, July 11, 2017 - link

    On page 6, it says that Epyc only has 64 PCIe lanes (available), but that's not correct. There are 128 PCIe lanes per chip. In a 1P configuration, that's 128 PCIe lanes available. On a 2P configuration, 64 PCIe lanes from each chip are used to connect to the other chip, leaving 64 + 64 = 128 PCIe lanes still available.

    This is a significant advantage.
  • Ian Cutress - Tuesday, July 11, 2017 - link

    You misread that table. It's quoting per-CPU when in a 2P configuration.

Log in

Don't have an account? Sign up now