Specing out new MariaDB/MySQL Server

I’m working on specing out a new server for a project at work and am looking for some input. The current server is a Dell R630 with 2x e5-2667 v3 CPUs with 128gb RAM, and a pair of Intel SATA SSDs in RAID 1 for the database storage. Currently the database is around 115gb and growing. Planning to run Rocky Linux for the OS on the new machine; the old one is Centos 7.

The current server is becoming pretty CPU bound in our workload; we’re regularly seeing all cores at 100%. I guess my main question is whether we should go AMD or Intel and if we should go for as many cores as we can get for our money or if we should go for higher clock speed cores or something in the middle.

My boss was leaning towards getting something like a used R820/830 quad e5-46xx v2/v3/v4 server as we already have some of those running Postgres for a different application. But I’ve been trying to steer us towards something more modern, say Xeon Scalable or EPYC.

If anyone has any good benchmark resources for this sort of thing please point me at them; my Google searching hasn’t turned up very much.

You need to figure out what your workload requires the most. Since you don’t have to worry about license fees, then you could totally go Epyc for max core count per dollar. If you need single core performance, then Intel is the best bang. If you need lower power, Epyc is going to be the best performance per watt.

Used server in production sounds like a disaster waiting to happen.


Agreed. Unless there is still a warranty on that thing that you can legally own that would not be smart. Keep in mind that if you do not get the server as used/refurbished from the vendor, then it is quite likely that the original purchaser’s warranty cannot be transferred to you.

The company has been pretty much running on used/refurb servers for the past 10+ years, so we’re well versed in what we’re getting into there. We usually buy from a supplier that has some warranty.

Is there a way to determine if our workload will scale well with more cores/threads without moving to a server that has more cores/threads? There doesn’t seem to be a lot of information out there on the subject, or my Google Fu is failing me this time around. :slight_smile:

In case it’s useful, the server is running a MariaDB database that’s backing a Laravel based website.

1 Like

You would need an SQL Analyzer tool to really help with that. You could see if you have a lot of blocked processes that are waiting on other queries to finish before moving on; higher IPC single core clocks could help with this. If you are just processing a lot of queries and they are waiting for resources, then higher core numbers may help.

Caveat here is that it could be over all system IO devices causing issues, like disk read/write, memory speed, and etc. Really a DBA would be good for looking over this as you would want to make sure that you are actually optimized for your workload before throwing hardware at the issue.

Thanks! This gives me a direction to look in. I figure anything we get is going to be higher IPC; it’s just a matter of choosing higher clocked/lower core count CPU(s) vs. lower clocked/higher core count CPU(s) at this point.

I wish we had a proper DBA on staff to look at it… I do feel like there are some query optimization issues, but it’s hard to convince the devs of that. Probably just going to throw hardware at the problem and see if we can kick the can down the road a while longer.

1 Like

Been looking through the data in our monitoring system(collectd+Grafana) and found the following:

  1. We need to improve our indexes; we’re doing a very large number of “Read Random Next” queries which according to the docs means they’re not using an index.
  2. Throughout most of the day we’re staying under 30 threads of “running” queries, but during peak times we’re getting spikes in the 60-80 thread range.

My conclusions:
We should get something with as much clock speed as possible that has 80 or so threads. The current server has 32 threads, so when we get spikes in load it’s having trouble coping.


That is a valid brute force approach but only Zen will give you that an a reasonable price. If you are going used, then Zen1 is not going to give you the single IPC high clock speed you need. The competing Xeon systems are gong to be at least one magnitude more expensive.

I am sure that if you were to add some proper indexes on those commonly hit tables, you can get those concurrent thread counts inflight times down.

Maybe look at hiring an outside consultant DBA? Should be cheaper than a new server.