Question regarding AMD EPYC servers and MariaDB
Hello, In the past when 2nd gen EPYC's were launching and beating Intel servers on most benchmarks, I visited a MariaDB conference and when I asked a senior MariaDB engineer, and asked whether he recommended AMD servers. At that time, he recommended Intel for MariaDB, because MariaDB had much more Intel testing equipment and was optimized for Intel. I am curious whether that is still the case, and whether MariaDB should be more optimized for Intel? For example, would AMD EPYC 7763 vs Intel Platinum 8380, would one be recommended over the other for MariaDB? (of course cores, and workload differ, but on a general perspective) Thank you.
Hi, this is just my opinion running several small MariaDB instances for over a decade on AMD. I don't think it really matters. What is far more important is your configuration (suitable storage engine(s), general parameters like buffers and tx logic) and application design (data model, queries, indices). That being said we have had no trouble with our AMD CPUs and I can easily recommend them. Good luck Jonas Am Sa., 30. Dez. 2023 um 19:08 Uhr schrieb highclass99 via discuss < discuss@lists.mariadb.org>:
Hello,
In the past when 2nd gen EPYC's were launching and beating Intel servers on most benchmarks, I visited a MariaDB conference and when I asked a senior MariaDB engineer, and asked whether he recommended AMD servers.
At that time, he recommended Intel for MariaDB, because MariaDB had much more Intel testing equipment and was optimized for Intel.
I am curious whether that is still the case, and whether MariaDB should be more optimized for Intel?
For example, would AMD EPYC 7763 vs Intel Platinum 8380, would one be recommended over the other for MariaDB? (of course cores, and workload differ, but on a general perspective)
Thank you. _______________________________________________ discuss mailing list -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-leave@lists.mariadb.org
On Sat, Dec 30, 2023 at 8:08 PM highclass99 via discuss
In the past when 2nd gen EPYC's were launching and beating Intel servers on most benchmarks, I visited a MariaDB conference and when I asked a senior MariaDB engineer, and asked whether he recommended AMD servers.
At that time, he recommended Intel for MariaDB, because MariaDB had much more Intel testing equipment and was optimized for Intel.
I am curious whether that is still the case, and whether MariaDB should be more optimized for Intel?
For at least as long as I have been working for MariaDB (over 6 years), Intel supports the development of MariaDB both with hardware resources (such as huge servers that are used for stress testing and for running regular CI) and with dedicated performance testing. Off the top of my head, I can name a couple of performance bugs that were found by Intel employees: https://jira.mariadb.org/browse/MDEV-28369 ibuf_bitmap_mutex is an unnecessary contention point https://jira.mariadb.org/browse/MDEV-31953 madvise(frame, srv_page_size, MADV_FREE) is causing a performance regression Neither of these is in any way specific to the x86-64 ISA or its implementations. I don’t know if AMD ever contributed anything to MariaDB. Some 20 years ago, they may have worked with MySQL Ab or Innobase Oy to solve a problem that was reproduced on Opteron processors, which could have been a bug in the InnoDB synchronization primitives. While we try to be CPU agnostic (for example, there exist SIMD implementations of the ISO 3309 CRC-32 as well as the CRC-32C for multiple ISA extensions, be it the ARMv8 PMULL or the x86-64 PCLMUL or the POWER VPMSUM), starting with MariaDB Server 10.6 we make use of one x86-64 extension that might only be available on select Intel CPU models: 2024-01-02 9:52:15 0 [Note] InnoDB: Using transactional memory I am under the impression that AMD has not implemented the Intel TSX-NI a.k.a. RTM extension (xbegin, xtest, xabort). Transactional memory (called HTM) is also available on POWER v2.09 and s390x. Lock elision thanks to hardware memory transactions could help reduce the rate of cache line invalidation under some workloads. MariaDB Server was not designed with NUMA in mind, but I try to do what I can to avoid or fix some obvious bottlenecks in the InnoDB storage engine. Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB plc
Thanks for your reply.
Since you mention " MariaDB Server was not designed with NUMA ", in theory
would you recommend beefy single cpu servers for high load MariaDB rather
than dual cpu servers?
Also regarding "Lock elision thanks to hardware memory transactions could
help reduce
the rate of cache line invalidation under some workloads" is this related
to NUMA?
On Tue, Jan 2, 2024 at 5:05 PM Marko Mäkelä
On Sat, Dec 30, 2023 at 8:08 PM highclass99 via discuss
wrote: In the past when 2nd gen EPYC's were launching and beating Intel servers on most benchmarks, I visited a MariaDB conference and when I asked a senior MariaDB engineer, and asked whether he recommended AMD servers.
At that time, he recommended Intel for MariaDB, because MariaDB had much more Intel testing equipment and was optimized for Intel.
I am curious whether that is still the case, and whether MariaDB should be more optimized for Intel?
For at least as long as I have been working for MariaDB (over 6 years), Intel supports the development of MariaDB both with hardware resources (such as huge servers that are used for stress testing and for running regular CI) and with dedicated performance testing. Off the top of my head, I can name a couple of performance bugs that were found by Intel employees: https://jira.mariadb.org/browse/MDEV-28369 ibuf_bitmap_mutex is an unnecessary contention point https://jira.mariadb.org/browse/MDEV-31953 madvise(frame, srv_page_size, MADV_FREE) is causing a performance regression
Neither of these is in any way specific to the x86-64 ISA or its implementations.
I don’t know if AMD ever contributed anything to MariaDB. Some 20 years ago, they may have worked with MySQL Ab or Innobase Oy to solve a problem that was reproduced on Opteron processors, which could have been a bug in the InnoDB synchronization primitives.
While we try to be CPU agnostic (for example, there exist SIMD implementations of the ISO 3309 CRC-32 as well as the CRC-32C for multiple ISA extensions, be it the ARMv8 PMULL or the x86-64 PCLMUL or the POWER VPMSUM), starting with MariaDB Server 10.6 we make use of one x86-64 extension that might only be available on select Intel CPU models: 2024-01-02 9:52:15 0 [Note] InnoDB: Using transactional memory I am under the impression that AMD has not implemented the Intel TSX-NI a.k.a. RTM extension (xbegin, xtest, xabort). Transactional memory (called HTM) is also available on POWER v2.09 and s390x.
Lock elision thanks to hardware memory transactions could help reduce the rate of cache line invalidation under some workloads. MariaDB Server was not designed with NUMA in mind, but I try to do what I can to avoid or fix some obvious bottlenecks in the InnoDB storage engine.
Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB plc
participants (3)
-
highclass99
-
Jonas Krauss
-
Marko Mäkelä