Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


CPU for database
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

CPU for database

What CPU would be better for MySQL database server?
More cores or better cores.

Best CPU for database
  1. Best CPU for database37 votes
    1. E3-1275 v5
      43.24%
    2. E5-1650 v3
      56.76%
«1

Comments

  • AidanAidan Member
    edited January 2018

    Both are comparatively the same speed per core, more cores would be better - though seeing as you're asking this, you'll likely be fine with 4 cores.

  • 1275 has a bit more performance per core

    We're talking about 100MHz when all cores are in use, a 1.7% per core performance difference in passmark.

  • WSSWSS Member

    @Aidan said:

    1275 has a bit more performance per core

    We're talking about 100MHz when all cores are in use, a 1.7% per core performance difference in passmark.

    It also has less L3 cache per core (that won't need to be scrubbed), has SSE3/4, a few less threads, but supports DDR3... really depends on what your needs are, but I'd say the benefits of the 1275 outweigh the slightly less abilities- unless you're going to need more than 64GB RAM.

  • i prefere cpu performance by check in cpubenchmark.net if avarage cpu mark is greater, then its better. just my thinking, dont know is it right way or not

  • I think the size of addressable memory is the deciding factor for database applications, when computing performance are comparable. So an E5 should be better than an E3.

    Thanked by 1vimalware
  • Whatever has more RAM. If RAM is limited to 32GB, then whatever has fastest disk io NVMe >SATA ssd >>>>>> hdd

  • WSSWSS Member

    @chihcherng said:
    I think the size of addressable memory is the deciding factor for database applications, when computing performance are comparable. So an E5 should be better than an E3.

    If you need more than 64GB for your DB- cached- You either need to redesign it, or more than one host.

    Thanked by 2vimalware Aidan
  • Use mariadb instead MySQL for better performance :)

  • How well you configure your DB is by far more performance relevant than the small diff between those processors. Btw. memory is more important, too.

    Thanked by 1vimalware
  • xyzxyz Member
    edited January 2018

    WSS said: If you need more than 64GB for your DB- cached- You either need to redesign it, or more than one host.

    Plenty of folk have DB servers with hundreds of GBs of RAM, StackOverflow (in 2016) being a prime example.
    Redesigning databases, particularly production databases, is often much easier said that done, assuming of course that it even yields any gains.

    But yeah, if one's asking the question (i.e. OP), they're not likely going to notice any difference. Still, as far as the question is concerned, the E5 is definitely superior for DB purposes, if cost/power isn't an issue.

  • WSSWSS Member

    @xyz said:

    WSS said: If you need more than 64GB for your DB- cached- You either need to redesign it, or more than one host.

    Plenty of folk have DB servers with hundreds of GBs of RAM, StackOverflow (in 2016) being a prime example.

    Thank you for this normal, common, LOW END TALK case scenario.

    Also, it needed a reboo.

    Redesigning databases, particular production databases, is often much easier said that done, assuming of course that it even yields a gain.

    Says someone who uses StackOverflow as an example.

    But yeah, if one's asking the question (i.e. OP), they're not likely going to notice any difference.

    Thanks for a completely worthless fucking post.

    Thanked by 1maldovia
  • xyzxyz Member

    Ouch, looks like I hit a nerve. My apologies.

  • @xyz said:
    Ouch, looks like I hit a nerve. My apologies.

    Bullshit. The vast majority of whole databases is less than hundreds of GB large and has no more than a couple of GB or maybe a couple of dozen GB memory available.

    And Stack Overflow is certainly not "plenty of folk".

    Btw, if you actually knew what you're talking about you'd know that sites like Stack Overflow have huge DBs - of which just a small part is "hot" (and in memory cache). The same is true for most other big DBs very few of which have no statistically hot zones.

    Accordingly, in huge DBs multi-level caching is used with memory just being used for the hottest zones. To offer an example: Often SSDs are used for indices and very elaborate schemes are in place to make sure that only the hottest data is in memory.

  • vt1vt1 Member
    edited January 2018

    I have a small website with Percona Database, 64k users, 55 tables and 44 million rows. Around 18 gb.

    I'm choosing between

    https://www.hetzner.com/dedicated-rootserver/px61-ssd

    https://www.hetzner.com/dedicated-rootserver/px91-ssd

    Thanked by 1vimalware
  • xyzxyz Member
    edited January 2018

    bsdguy said: The vast majority of whole databases is less than hundreds of GB large and has no more than a couple of GB or maybe a couple of dozen GB memory available.

    I wholly agree with you. The vast majority of DBs can probably run fine on a 256MB VPS, if tuned properly.
    But there are also many DBs which are larger - they certainly aren't anywhere in the vast majority, but I wouldn't call them insignificant in number either.

    And Stack Overflow is certainly not "plenty of folk".

    They're an example which is easy to state, and they provide the information publicly. There's probably better examples somewhere, but I happen to know that one in particular.
    Note that "plenty of folk" is not "vast majority" - if you're confusing the two, don't.

    Btw, if you actually knew what you're talking about you'd know that sites like Stack Overflow have huge DBs - of which just a small part is "hot" (and in memory cache).

    I'm very well aware of that. And I'm sure they do as well. And yet they decide to use servers with hundreds of GBs of RAM. Care to guess why?

    And of course, not everyone has workloads like that.

    Back to the original point: don't make pointless suggestions about appropriate amount of RAM when you don't even have a clue what the purpose is.

  • xyzxyz Member

    vt1 said: I have a small website with Percona Database, 64k users, 55 tables and 44 million rows. Around 18 gb.

    Either is likely fairly overpowered. If you're seeing the CPU being the limiting factor, consider looking at how you can tune your application.
    But since you're already running the database, why not take into consideration what you already have and how much more/less you need? We're not going to be able to guess your load any better than you observing it.

  • FAT32FAT32 Administrator, Deal Compiler Extraordinaire

    @vt1 said:
    I have a small website with Percona Database, 64k users, 55 tables and 44 million rows. Around 18 gb.

    I'm choosing between
    https://www.hetzner.com/dedicated-rootserver/px61-ssd
    https://www.hetzner.com/dedicated-rootserver/px91-ssd

    In my opinion, I would say both are enough for your case because it fits in the memory well. Although you get some performance increase in PX91, it is not obvious until your database grows about 3x larger. RAM is usually the bottleneck for database server, not the CPU. (Go for PX61, you save some money too)

  • vt1vt1 Member
    edited January 2018

    @FAT32 said:
    In my opinion, I would say both are enough for your case because it fits in the memory well.

    Yep, I'm choosing between more performant cores and the number of cores. I believe, on the more productive core, mysql could execute queries faster.

    I use only InnoDB, and MySQL consumes around 29gb of my current 32gb server. CPU is a bit old 1230v3, so I'm looking for an upgrade.

    My mysql config
    https://www.dropbox.com/s/bzi2nsiffu30o2s/my.cnf.txt?dl=0

  • Guess you definitely have to go to Skylake E3 or Ivybridge+ 3.x Ghz E5 to bump the buffer_pool_size above 29GB.

    Have you checked actual buffer pool utilization?

    I'm not following how an 18GB database uses up a 29GB buffer pool. Your active set should be at most 40-70%

  • kkrajkkkrajk Member
    edited January 2018

    parroting earlier posts... redacted

  • @vimalware said:
    I'm not following how an 18GB database uses up a 29GB buffer pool. Your active set should be at most 40-70%

    Are indices included? Can easily be twice the db size.

    Thanked by 1vimalware
  • exception0x876exception0x876 Member, Host Rep, LIR

    vt1 said: I use only InnoDB, and MySQL consumes around 29gb of my current 32gb server. CPU is a bit old 1230v3, so I'm looking for an upgrade.

    I don't believe E3-1275 v5 will be a very noticeable upgrade over E3-1230v3. However, if you could post your current server load info, it would definitely help.

  • vt1vt1 Member

    @exception0x876 said:
    However, if you could post your current server load info, it would definitely help.

    How can I measure it? Thank you.

  • exception0x876exception0x876 Member, Host Rep, LIR

    @vt1 said:

    @exception0x876 said:
    However, if you could post your current server load info, it would definitely help.

    How can I measure it? Thank you.

    You can install some monitoring solution. Or just provide a few screenshots of the output of "top" command when your server is under a regular usage.

  • chihcherngchihcherng Veteran
    edited January 2018

    @vt1 said:
    How can I measure it? Thank you.

    Here is a shell script I use to capture the state of a Linux system:

    :
    SYS_STATUS=`hostname`-`date +%Y%m%d-%H%M`.txt
    
    ( echo "Hostname: `hostname`"
    date; free -m; ps ax; w; netstat -n; df -k;
    vmstat 5 12
    date; free -m; ps ax; w; netstat -n; df -k) > $SYS_STATUS
    
  • WSSWSS Member

    @chihcherng said:

    @vt1 said:
    How can I measure it? Thank you.

    Here is a shell script I use to capture the state of a Linux system:

    :
    SYS_STATUS=`hostname`-`date +%Y%m%d-%H%M`.txt
    
    ( echo "Hostname: `hostname`"
    date; free -m; ps ax; w; netstat -n; df -k;
    vmstat 5 12
    date; free -m; ps ax; w; netstat -n; df -k) > $SYS_STATUS
    

    Well, there goes the need for sysadmins. @jarland, @raindog308 - it's been a chore!

  • @WSS said:
    Well, there goes the need for sysadmins. @jarland, @raindog308 - it's been a chore!

    Me gonna be a billionaire very soon. Me gonna grab and sell that script know-how to them clueless huge DB companies and governments still having expensive DB specialists and admins and consultants and wasting cycles too.

    And @jarland is going to have to change my nick to "DB-Expert-Billionaire", hehe.

  • Personally, e3 would suffice with some optimization.

  • raindog308raindog308 Administrator, Veteran

    WSS said: If you need more than 64GB for your DB- cached- You either need to redesign it, or more than one host.

    xyz said: Redesigning databases, particularly production databases, is often much easier said that done, assuming of course that it even yields any gains.

    True, but I can tell you innumerable tales that go like this: "OMG it was taking hours to do that query but we put in an index/added partitioning/rewrote the query/removed an expensive func in the query/etc. and now it is completing in under 15 seconds..."

    Bad SQL or bad schema design will defeat any amount of hardware.

    bsdguy said: How well you configure your DB is by far more performance relevant than the small diff between those processors. Btw. memory is more important, too.

    As a former professional DBA, this brings a tear of joy to my eye ;-)

    @vt1 (OP, who is not part of most of the banter above), your questions are not bad or wrong, as you're probably not a DB professional. Pick a good CPU but you might want to spend a little time reading up on MySQL performance if that is becoming an issue.

    There are scripts you can run (e.g., mysqltuner.pl) that will give you nice reports, though you'll need the basics to understand them. In general, you want to find the bottlenecks, and then shave away at them until something else is a bottleneck.

Sign In or Register to comment.