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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
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
https://www.technikaffe.de/cpu_vergleich-intel_xeon_e5_1650_v3-483-vs-intel_xeon_e3_1275_v5-598
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.
Whatever has more RAM. If RAM is limited to 32GB, then whatever has fastest disk io NVMe >SATA ssd >>>>>> hdd
If you need more than 64GB for your DB- cached- You either need to redesign it, or more than one host.
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.
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.
Thank you for this normal, common, LOW END TALK case scenario.
Also, it needed a reboo.
Says someone who uses StackOverflow as an example.
Thanks for a completely worthless fucking post.
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.
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
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.
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.
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.
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.
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)
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%
parroting earlier posts... redacted
Are indices included? Can easily be twice the db size.
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.
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.
Here is a shell script I use to capture the state of a Linux system:
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
scriptknow-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.
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.
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.