starred/LinuxGSM

Fork 0

mirror of https://github.com/GameServerManagers/LinuxGSM.git synced 2026-04-25 06:05:57 +03:00

[GH-ISSUE #663] Feature request: ability to set CPU affinity from the start. #533

New issue

Closed

opened 2026-02-27 02:02:09 +03:00 by kerem · 13 comments

kerem commented

2026-02-27 02:02:09 +03:00

Owner

Originally created by @dynamittt on GitHub (Jan 31, 2016).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/663

Hello. Will it be possible to add CPU affinity setting to the script, so that one can choose the CPU cores to be used on a certain gameserver? Will be very useful.
I would also like to ask if anyone knows how one can force all other processes (OS related processes and other tasks unrelated to the server itself) to a specific core.
What I am trying to do is set the gameserver to a specific core(s) and everything else to another core(s).
Thank you very much in advance.

Originally created by @dynamittt on GitHub (Jan 31, 2016). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/663 Hello. Will it be possible to add CPU affinity setting to the script, so that one can choose the CPU cores to be used on a certain gameserver? Will be very useful. I would also like to ask if anyone knows how one can force all other processes (OS related processes and other tasks unrelated to the server itself) to a specific core. What I am trying to do is set the gameserver to a specific core(s) and everything else to another core(s). Thank you very much in advance.

kerem closed this issue

2026-02-27 02:02:10 +03:00

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@jaredballou commented on GitHub (Feb 1, 2016):

What are the commands you want to use, for what games, and what sort of flexibility and configuration would this require?

@jaredballou commented on GitHub (Feb 1, 2016): What are the commands you want to use, for what games, and what sort of flexibility and configuration would this require?

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 1, 2016):

Hi.
What would be the benefits of that ? Process balance is not an issue in linux as far as i know.

@UltimateByte commented on GitHub (Feb 1, 2016): Hi. What would be the benefits of that ? Process balance is not an issue in linux as far as i know.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@oalaro commented on GitHub (Feb 1, 2016):

Well for CS:GO some people suggest to use it. I also use it. Personal preference.
Find this line in your startscript
executable="./srcds_run" <-- CS:GO server for example executable .
Add taskset -c (core nr counting from 0) in front off the executable like this.
executable="taskset -c 0 ./srcds_run"
Now you have a CS:GO server running only on first core.
If you want to add multiple cores then just separate them with commas
For example, 0,5,7,9-11
executable="taskset -c 0,1,2 ./srcds_run"
Taskset man page http://linux.die.net/man/1/taskset

@oalaro commented on GitHub (Feb 1, 2016): Well for CS:GO some people suggest to use it. I also use it. Personal preference. Find this line in your startscript `executable="./srcds_run"` <-- CS:GO server for example executable . Add taskset -c (core nr counting from 0) in front off the executable like this. `executable="taskset -c 0 ./srcds_run"` Now you have a CS:GO server running only on first core. If you want to add multiple cores then just separate them with commas For example, 0,5,7,9-11 `executable="taskset -c 0,1,2 ./srcds_run"` Taskset man page http://linux.die.net/man/1/taskset

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 2, 2016):

What if some other stuff is using your core 0 ? (Which is very likely unless you assign every process to its own core) Then the whole thing is pointless. I don't get it. Especially for CSGO which is a pretty light server comapred to CPU intensive servers such as Garry's Mod.

@UltimateByte commented on GitHub (Feb 2, 2016): What if some other stuff is using your core 0 ? (Which is very likely unless you assign every process to its own core) Then the whole thing is pointless. I don't get it. Especially for CSGO which is a pretty light server comapred to CPU intensive servers such as Garry's Mod.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 2, 2016):

In the end, do you have any proof that this is useful, or is that just another pointless rumor saying that it's useful ?

@UltimateByte commented on GitHub (Feb 2, 2016): In the end, do you have any proof that this is useful, or is that just another pointless rumor saying that it's useful ?

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@oalaro commented on GitHub (Feb 2, 2016):

Well I only run CS:GO servers on my rig. Nothing else. What I did see when all servers were full, ( 1 physical core = 1 server) that it threw two scrds threads on one core for a moment and that in return cause a noticable lagspike. I don't see that when I had set affinity. All I saw was more stable sv/var under high load that's why i kept using it. That was like 1 year ago.

Especially for CSGO which is a pretty light server comapred to CPU intensive servers such as Garry's Mod.

Since they both use scrds I'd say they both CPU intensive

What if some other stuff is using your core 0 ?

You are contradicting yourself with that statement. If i set CS:GO affinity to first core and it uses 90% of that cores power then task scheduler should even consider using that core.

I was just pointing out that there doesn't need to be a script change to use affinity. It can already be done.

I'll run my servers with no affinity for few days to see if there is any difference.

@oalaro commented on GitHub (Feb 2, 2016): Well I only run CS:GO servers on my rig. Nothing else. What I did see when all servers were full, ( 1 physical core = 1 server) that it threw two scrds threads on one core for a moment and that in return cause a noticable lagspike. I don't see that when I had set affinity. All I saw was more stable sv/var under high load that's why i kept using it. That was like 1 year ago. > Especially for CSGO which is a pretty light server comapred to CPU intensive servers such as Garry's Mod. Since they both use scrds I'd say they both CPU intensive > What if some other stuff is using your core 0 ? You are contradicting yourself with that statement. If i set CS:GO affinity to first core and it uses 90% of that cores power then task scheduler should even consider using that core. I was just pointing out that there doesn't need to be a script change to use affinity. It can already be done. I'll run my servers with no affinity for few days to see if there is any difference.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 2, 2016):

Since they both use scrds I'd say they both CPU intensive

Nope ! One uses shitload of physics and lua addons, the other doesn't !

You are contradicting yourself with that statement. If i set CS:GO affinity to first core and it uses 90% of that cores power then task scheduler should even consider using that core.

My thought is : It's not because a process is using exclusively core 0, that other processes won't use it, even if it's used at 90%. But if you reach 90% of a CPU core with CSGO, i'm curious to know what mods and how many people are on it... And mostly... What damn bad CPU you're using.

I'll run my servers with no affinity for few days to see if there is any difference.

Yep, i'm curious to see if you notice any difference. Though you'd need a well defined protocol to test it more accurately.

@UltimateByte commented on GitHub (Feb 2, 2016): > Since they both use scrds I'd say they both CPU intensive Nope ! One uses shitload of physics and lua addons, the other doesn't ! > You are contradicting yourself with that statement. If i set CS:GO affinity to first core and it uses 90% of that cores power then task scheduler should even consider using that core. My thought is : It's not because a process is using exclusively core 0, that other processes won't use it, even if it's used at 90%. But if you reach 90% of a CPU core with CSGO, i'm curious to know what mods and how many people are on it... And mostly... What damn bad CPU you're using. > I'll run my servers with no affinity for few days to see if there is any difference. Yep, i'm curious to see if you notice any difference. Though you'd need a well defined protocol to test it more accurately.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@dynamittt commented on GitHub (Feb 3, 2016):

Hello. For example, ucc-bin-real (Killing floor and RO Dedicated servers) does not support multiple cores.
I think that it will be very useful if you give us the ability to simply set the CPU/s we would like to use in the server start script.
The most common usage (A dual core processor example is given) would be to set a game server executable to use only the first core, and every other process to use the other core.

@dynamittt commented on GitHub (Feb 3, 2016): Hello. For example, ucc-bin-real (Killing floor and RO Dedicated servers) does not support multiple cores. I think that it will be very useful if you give us the ability to simply set the CPU/s we would like to use in the server start script. The most common usage (A dual core processor example is given) would be to set a game server executable to use only the first core, and every other process to use the other core.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 3, 2016):

Not supporting multiple core, means it will use the power of 1 core maximum... Not that it won't start with a multiple core server. Days when you had to assign a process to one core to get better performances are quite far away to me... I think it's pointless, whatever the amount of cores you have, until proven wrong.
You'd better let resource balance make its job.
Let me explain :

Let's assume you have a 2 core machine (VPS ?! What server is dual core these days ?)
If a core is only assigned to one game server and, not any other process can use this core (let's say it's possible, even if i think it would be a real pain to setup), then if you're using 20% of that core with your game server, and other processes need 1 and a half cores, other processes will be slowed down. I see your point, where core 0 would be the game server, and core 1 would be other processes... So other processes would never affect the game... But if other processes reach your whole remaining core, you either have a not powerful machine enough, or would better let those processes using remaining power in core 0.
A good server is a well balanced one, on which complete CPU saturation doesn't occur, ever, so this feature would be a patch for bad admins or not powerful enough servers according to the use you make.

I think it would be a worthless effort work on this until proven wrong, until somebody gives a practical use that actually has more benefits than downsides.

@UltimateByte commented on GitHub (Feb 3, 2016): Not supporting multiple core, means it will use the power of 1 core maximum... Not that it won't start with a multiple core server. Days when you had to assign a process to one core to get better performances are quite far away to me... I think it's pointless, whatever the amount of cores you have, until proven wrong. You'd better let resource balance make its job. Let me explain : Let's assume you have a 2 core machine (VPS ?! What server is dual core these days ?) If a core is only assigned to one game server and, not any other process can use this core (let's say it's possible, even if i think it would be a real pain to setup), then if you're using 20% of that core with your game server, and other processes need 1 and a half cores, other processes will be slowed down. I see your point, where core 0 would be the game server, and core 1 would be other processes... So other processes would never affect the game... But if other processes reach your whole remaining core, you either have a not powerful machine enough, or would better let those processes using remaining power in core 0. A good server is a well balanced one, on which complete CPU saturation doesn't occur, ever, so this feature would be a patch for bad admins or not powerful enough servers according to the use you make. I think it would be a worthless effort work on this until proven wrong, until somebody gives a practical use that actually has more benefits than downsides.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 3, 2016):

I don't know too much about CPU affinity however a modern distro should be able to correctly handle processes across its cores. Having quick google. affinity might be useful for say multiple physical CPU's where moving a process between them might cause a performance hit or possible bugs.

I think this answer sums it up for me

The scheduler already tries to keep threads on the same cores, and to avoid migrations. This suggests that there's probably not a lot of mileage in managing thread affinity manually, unless:

you can demonstrate that for some reason the kernel is doing a bad a job for your particular application; or
there's some specific knowledge about your application that you can exploit to good effect.

http://stackoverflow.com/questions/14170127/pros-and-cons-of-cpu-affinity

So in summery there appears to not be much point unless srcds is being a naughty boy and crashing with multiple cores or you know the inside out of srcds. Otherwise you may a well just let your Linux Kernel handle it (its clever shit is the Linux Kernel).

Also you could be reducing your overall server performance if affinity dedicates a whole core just to one game server process. Secondly if affinity does not dedicate a whole core to one process why does it even matter as other processes can still use a core and slow down your server. In fact if there was another process hogging that core your server would not be able to move your game server process to another core and thus slowing it down.

Maybe this might of been useful quite a few years ago when multi-core systems where quite new but not now
So it looks like you will get as much performance improvement as cleaning a windows registry
http://www.howtogeek.com/171633/why-using-a-registry-cleaner-wont-speed-up-your-pc-or-fix-crashes/

Hope thats useful

@dgibbs64 commented on GitHub (Feb 3, 2016): I don't know too much about CPU affinity however a modern distro should be able to correctly handle processes across its cores. Having quick google. affinity might be useful for say multiple physical CPU's where moving a process between them might cause a performance hit or possible bugs. I think this answer sums it up for me > The scheduler already tries to keep threads on the same cores, and to avoid migrations. This suggests that there's probably not a lot of mileage in managing thread affinity manually, unless: > > you can demonstrate that for some reason the kernel is doing a bad a job for your particular application; or > there's some specific knowledge about your application that you can exploit to good effect. http://stackoverflow.com/questions/14170127/pros-and-cons-of-cpu-affinity So in summery there appears to not be much point unless srcds is being a naughty boy and crashing with multiple cores or you know the inside out of srcds. Otherwise you may a well just let your Linux Kernel handle it (its clever shit is the Linux Kernel). Also you could be reducing your overall server performance if affinity dedicates a whole core just to one game server process. Secondly if affinity does not dedicate a whole core to one process why does it even matter as other processes can still use a core and slow down your server. In fact if there was another process hogging that core your server would not be able to move your game server process to another core and thus slowing it down. Maybe this might of been useful quite a few years ago when multi-core systems where quite new but not now So it looks like you will get as much performance improvement as cleaning a windows registry http://www.howtogeek.com/171633/why-using-a-registry-cleaner-wont-speed-up-your-pc-or-fix-crashes/ Hope thats useful

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@jaredballou commented on GitHub (Feb 9, 2016):

Yeah, the default kernel scheduler should be able to segregate loads to individual cores, CFS groups threads by tree when possible and will quickly move the process to its own core if one is available. If you really want to add this in though, I might add a "before_executable_command" setting so that you can just put whatever arbitrary command you want there. I don't think making more variables and trying to manage cpu scheduling from inside LGSM is a good idea, but I'll be happy to put this into my fork to test.

@jaredballou commented on GitHub (Feb 9, 2016): Yeah, the default kernel scheduler should be able to segregate loads to individual cores, CFS groups threads by tree when possible and will quickly move the process to its own core if one is available. If you really want to add this in though, I might add a "before_executable_command" setting so that you can just put whatever arbitrary command you want there. I don't think making more variables and trying to manage cpu scheduling from inside LGSM is a good idea, but I'll be happy to put this into my fork to test.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 10, 2016):

Well, this suggestion does not seem lile it's gonna be adopted.
Feel free to re-open if you have interesting elements to add to the discussion. For now, i'm closing this.

@UltimateByte commented on GitHub (Feb 10, 2016): Well, this suggestion does not seem lile it's gonna be adopted. Feel free to re-open if you have interesting elements to add to the discussion. For now, i'm closing this.

kerem commented

2026-02-27 02:02:10 +03:00

Author

Owner

@lock[bot] commented on GitHub (Jul 19, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Jul 19, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

kerem referenced this issue

2026-02-27 03:53:22 +03:00

[PR #533] [MERGED] Update pzserver #3122