Opinion for the better game server

Question

Opinion for the better game server

bissagars

Mr or Mrs. 500

Points: 555
More actions
November 25, 2021 at 1:10 pm

#3956837

I am currently upgrading my game server and I have 3 options
1- Ryzen 5950x / 128GB ECC / 3.84Tb NVME RAID1 (3000/1500) 105
2- Xeon E-2176G / 64GB ECC / 960GB NVME RAID1 (3000 / 1050) + 512GB NVME RAID1 (3000/2000) 95
3- Xeon-E 2274G / 64GB ECC / 960GB NVME RAID1 (3000/1050) 70
I always used the second option to divide the Log and Data files on each disk but I am tempting to go with the just RAID1 option and put the data and log on the same disk as the NVME disks are fast enough now?
What do you guys think?
My game server database size is 55GB and currently running on old hardware with E5 1650 with 128GB RAM and the SQL ram usage is around 50GB ~ 60GB after one month of uptime running the server.
December 9, 2021 at 10:05 am

This was removed by the editor as SPAM
January 24, 2022 at 4:05 am

This was removed by the editor as SPAM
August 21, 2022 at 12:52 pm

This was removed by the editor as SPAM
August 21, 2022 at 12:56 pm

This was removed by the editor as SPAM
August 21, 2022 at 12:57 pm

This was removed by the editor as SPAM
August 21, 2022 at 12:57 pm

This was removed by the editor as SPAM

Viewing 15 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic. Login to reply

Mr. Brian Gale SSC-Insane Points: 24800 More actions · Answer 1

My opinion - I think it really depends on what you need and what growth looks like.

I would personally put the data and log files on different disks if you need fastest performance from the database. But with those fast disks, you probably won't notice much of an improvement by having the data and log on different physical disks unless you have a lot of write operations. But with the database being relatively small (55 GB) and the smallest set of disks in your list being 960GB, you may want to refactor some of those things around. With options 2 and 3 you have a LOT of disk for that small of a database and option 1 is a HUGE disk for such a small database.

Things to note with all 3 options - you have a max memory of 128 GB. With your current SQL RAM usage around 50-60 GB, what is your "MAX MEMORY" set to? If it is set to around 60 GB currently, that would explain why you never use it all up.

I would be looking at what you are wanting on that system and what you plan to use it for going forward. Having SO much extra disk while having only a little spare RAM in options 2 and 3 doesn't give you much room to grow into that system before you will need to buy more hardware (RAM).

My recommendation would be to use a modified version of number 2 - I would shrink the disk sizes down a bit in order to get more RAM. If I am "Upgrading" my system, I am not going to reduce RAM to what I see as the "bare minimum" (SQL + 4 GB for OS). I would keep the 128 GB of RAM and investigate how SQL is configured because it could easily be that you would benefit from the full 128 GB if it was configured differently. Even if it is configured to use 2 TB (I hope not) and it is only using 60 GB out of the 128 GB, I would want room to grow. If the utilization of the server increases over time, I want to make sure I have room for that growth.

Same thing with the disk within reason. I want room to grow, but having nearly 1.5 TB of disk with option 2 for a 55 GB database plus OS, which would probably total around 110 GB used, seems like overkill. BUT I also don't know how quickly you filled up that 55 GB in your database. If you are adding 55 GB per month, 1.5 TB of disk will only last about 27 months (roughly). But if that is 55 GB per year, then 1.5 TB of disk should last about 27 years; assuming linear growth. In 27 years, you are likely to upgrade the system multiple times and as such probably don't need to have 1.5 TB of disk.

On top of the RAM recommendation, you may benefit from in-memory tables, which would use more RAM. You might not; it really depends on how you are using the database, but in memory tables can offer some performance boosts while eating up more memory. Since you have the memory available, might as well use it. Mind you, I don't remember offhand if 2012 supports in-memory tables; MIGHT need to upgrade to 2017 or higher for those.

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

bissagars Mr or Mrs. 500 Points: 555 More actions · Answer 2

Mr. Brian Gale, thank you for this info.

This server specification can not be changed.

Also the disk space is already halved due to RAID 1.

On old server I have the same space 960GB and usually the disk is filled at 70~75%

I haven't set any limitation for the ram usage in SQL server.

During my hosting to this game server, I started from 16GB till 64GB, usually I don't restart the sql service so in fact with 64GB of ram I had to make a restart like very month, but it is not a big deal. The game is not much active for the past year so I expect a minimal growth, the 55GB database size is in 8 years , but I like to upgrade the server each year and there is good offers going now.

With the 128GB, I can keep the sql service for months without worrying with the ram usage, max I have seen used by sql was 65GB and that was with the sql running for 3 months without any limitation set.

I am afraid to change the SQL 2012 as it has been running fine with the game for 8 years now and it is kinda old game with old procedures and I go with the; if it is working don't change it 😀

This reply was modified 3 years ago by bissagars.
This reply was modified 3 years ago by bissagars.

Mr. Brian Gale SSC-Insane Points: 24800 More actions · Answer 3

If it was me, I would want the game server to have maximum uptime. Downtime means unhappy customers, no?

If I was a customer for a game and the server went down while I was playing, I wouldn't be too happy.

What I would recommend is still to do some administration on the SQL instance. If it is running with default max memory, that means it can use up to 2 TB! If you set this to a lower value (like 55 GB), SQL will flush things out of memory and you won't need to worry about cycling the service to get memory back. OR if you need more memory for other things, drop SQL's MAX MEMORY value lower.

I would also look at upgrading to a newer SQL Version (2019 perhaps). That way you can be on a supported version. Might as well get some support with the SQL instance, no?

With the disk being 70+% full, I would recommend getting more disk, but it sounds then like the server is being used for more than just SQL, in which case, I would be evaluating if those other processes are hurting performance of the SQL stuff. If I was building and maintaining a SQL instance for a gaming server, and I was doing maintenance like upgrades, I would want to make sure that the server was running in optimal state to keep those who buy my game happy. Stealing resources and misconfiguring the database might upset my users.

Also, just so I understand right, when you say "960 GB Raid 1" I assumed you meant you have 2 960 GB disks, but you actually meant you have 2 480 GB disks in RAID 1? Or do you mean you have 1 960 GB disk split into 2 partitions so you can do software RAID 1 on it? I really hope it isn't that 3rd option as that is a really really bad idea.

Just my 2 cents.

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

bissagars Mr or Mrs. 500 Points: 555 More actions · Answer 4

It is 960GBx2 in software RAID1 with just 1 partition.

I don't have performance or uptime problem with current server, I saw those 3 servers with good offers and they have better hardware than my current server so why not upgrade specially the cost is basically the same with the old server.

Mr. Brian Gale SSC-Insane Points: 24800 More actions · Answer 5

I am just giving my suggestions. My opinion, I would upgrade the server to have the same or more resources than the current server. I would also do database administration,

In general, if I am upgrading a system, I want all of the resources to be the same or larger than the previous system. Since you would be upgrading from roughly 50% memory free to roughly 5% memory free if you went with option 2 or 3, I would not go that route. Option 1 is the one I would go for simply for the RAM. Now with disk, you are using 70%+ of a 960 GB drive, so I would want more disk there as well. So I would be looking at option 1 or 2 for disk. Since it is running a database, I would want to have 2 disks at a minimum - 1 for data, 1 for log as there are performance benefits of doing it that way. That being said, you could always go with option 1 and pull one of the drives from your current system and set it up in the new one.

So my approach would be to go with option 1 and raid some parts (the 960 GB drives) from the current system once things are transferred over. Wipe the disks and use the older disks for the log. That is assuming the disks are not ancient and at risk of failure or slow, but if they are solid and stable still, and fast disks, put the log files on them and data on the large disk. You want your log files on the fastest disk to get the best performance. BUT it also depends on your current specs. I mean if your current disks are half the speed (for example) and you are not having performance issues (that you are aware of), then putting the log on your current disk will give you roughly the same performance.

I still think that upgrading to 2019, or at LEAST 2017, so you are on a supported version of SQL Server would be a good idea though. Last thing you would want is for your DB to fail and have no support and thus your game is down while you try to figure out how to handle it. Plus, with a new server, you will likely want to put a newer Server OS on it and SQL Server 2012 is not supported on Windows Server 2019 - https://bornsql.ca/blog/unsupported-but-working-versions-of-sql-server-on-windows-server-2019/#:~:text=For%20official%20purposes%2C%20this%20is%20the%20list%20you,%20%20Yes%20%207%20more%20rows%20

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

bissagars Mr or Mrs. 500 Points: 555 More actions · Answer 6

I guess I am going to go with option 1.

between I am running SQL 2012 on Windows server 2019 without any issue.

Mr. Brian Gale SSC-Insane Points: 24800 More actions · Answer 7

It might run without issues for you, but it is not a supported configuration. A windows update OR a SQL update could break the SQL instance on that server.

If it was me, I would take a downtime window and upgrade the instance. Multiple ways to do it, the approach you take depends on the application configuration. If you can do a side-by-side implementation where you have 2012 running and 2019 and then push an update to your application so people use 2019 instead, you could minimize downtime. Alternatley, you could do an in-place upgrade.

But I know I wouldn't want a "critical" system running in an unsupported configuration. Just because my car ran fine yesterday doesn't mean it will run fine tomorrow if I don't take care of it. SQL needs maintenance too (patches, updates, statistics maintenance, checkdb, backups, etc). Just because it is running fine in an unsupported configuration today doesn't mean it will continue to run that way.

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

Mr. Brian Gale SSC-Insane Points: 24800 More actions · Answer 8

Had another thought on this - since you don't want to do updates on the SQL instance, why not look at putting it in Azure in a SQL Managed instance instead of buying a whole server for the SQL instance? Or if it is just a single database, that is an option too in Azure.

Advantage here is you don't have to worry about updates and upgrades as they happen transparently to you. Plus you get more guaranteed uptime. Only downside is the monthly/yearly costs rather than a one-time cost for a new server. BUT even with a one-time cost for the server, you are still paying for the electricity and licenses and maintenance on the server. Servers, while they do essentially just work (most of the time) after you get it set up, there is still windows updates, and licenses for all of the tools you put on there. And you need to monitor the hardware to ensure that nothing is at risk of failure. Having 1 disk die in a 2 disk RAID 1 configuration is OK if you have a spare disk to toss in, but if they both die, you are SOL. Plus you also have to maintain your backups.

With Azure, you take the hardware completely out of the equation. And if you go with a SQL managed instance (or SQL Single Database) instead of an Azure VM, you take the OS out of the problem too. You just have to manage SQL!

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.