Full machine or VDS help

[Caliban55]

The main problem is with ArmA2/3 hitting enormous problems when reaching a high client count (50+), depending on the mission. This can be somewhat worked around with a good mission design that is tailored to handle those large client numbers, but in the end you are hitting a limit of the ArmA engine here (something we from the community complained about for some time, ArmA would need a complete engine/netcode rework...).

A better CPU helps to some degree, but it will only give you some more time before the mission needs a restart.

My recommendation would be to limit the player number to a decent value, unless you have a mission specifically designed to handle large player number, especially if you are running multiple ArmA servers.

[Caliban55]

If you haven't done this yet, try the the latest patch to version 1.26 for ArmA3. The patch addresses some network function and overhead send, which should help with the server performance a bit. I would not excpect miracles though .

[J-English]

Cheers calib,i was going to make a move tommorow,you was right tho,the mod itself is causing lagg at certain amount of players that join the server.We had a vehicle store issue bug,Players could not purchase vehicles as soon a number of players joined and the server fps would drop,they would get an error at the store.

After sometime vehicles would all spawn all at once after 10 minutes because players would spam the buy button trying to purchase vehicles.

This caused alot of server lagg.So i think its a combination wasteland thats bugged and running arma 3 in a virtualization world.They fixed 1 issue tho.

News from the developer
lag is caused by a spawnthreaditis, or having too many simultaneous scripts running at the same time.

Lag seems to increase exponentially as new scripts are started; I made the territory system jump to nearly 80s of execution time by spawning many new threads on the server, compared to its normal 10s.

My 2 solutions for decreasing lag will be:

- Reduce usage of TPG_fnc_MP for client-to-server communication, in favor of regular public variable event handlers; a call to TPG_fnc_MP is very resource-intensive due to the number of checks it runs on the data. Using TPG_fnc_MP for vehicle store purchases during lag resulted in a 2 minute delay, and a public variable event only took 3 seconds, which is reasonably within the 15s timeout for vehicle store purchases.

- Consolidate all the town vehicle respawning threads into a single one; Right now, every single town vehicle has its own thread to check whether the vehicle meets the conditions required to respawn at its original location. These 200+ threads make for a major portion of the load on the thread scheduler, and are with no doubt another reason for server lag. Even if they are asleep most the time, the scheduler has to continuously loop over all of them before continuing to process other threads.

I pushed a couple commits tonight, implementing the public variable workaround for some calls to TPG_fnc_MP. It won't improve the server FPS by a large margin, but it should definitely reduce vehicle store errors.

see how it goes

[J-English]

So we got a seperate standalone arma 3 server but we are getting insane amount of dsync.
I dont know why thats happening,first day it was ok,but now its been dsyncing for the last 3 days.Players are skipping alot,they would disappear.Not when its just full..Its just happend now with no more than 30 odd players on.Server being ddos`d im not sure
Any ideas to why its doing this?

Thanks

Your server is currently being hosted on a Dual Intel Xeon E5-2690v2 (Ivy Bridge-E 3.0ghz) node with 20 total processor cores and 128 gigabytes of RAM. The database code for this node is dallas-icosa30; its OS is Windows.

[kraze]

That's almost two and a half cores of usage there. That's insane for 30 players. When is the last time a reboot occurred?

[J-English]

1 hour at most when it was last rebooted

[soja]

Is it sitting at near 100% usage with only a couple players? Is this normal for ARMA?

[J-English]

CPU usage: 35.89% currently with 50 players online.
Even with 30 players earlier on we was getting alot of dsync..red and yellow chains.Alot of lagg.

[J-English]

looks like it starting to run smooth ,currently 63 players online.
strange..

[Caliban55]

In your server.cfg, try to add the following command:

Code: Select all

guaranteedUpdates = false;

This will/should prevent the guaranteed send of network packets through the connected clients. As before mentioned, highly mission dependent, and what clients are doing on the server.

Give it a try and experiment with the setting - for some servers it helped.

[J-English]

Ok cheers calibaan ,will try this.

[J-English]

Code: Select all

guaranteedUpdates = false;

this seems to work calibaan,Alot less dsync if any at times,alot less server crashes also.
Thankyou calibaan!.

I just wanted to know,when were on the server in console,sometimes we execute this command manually ingame :

Code: Select all

{ if (!alive _x) then { deleteVehicle _x } } forEach vehicles;

This clears all burnt out vehicles and also currently clears vehicles on fire.This helps the server FPS and less lagg.
Is it possible to implement this into our wasteland PBO so it automatically executes roughly every half hour.
in the wasteland server files there is a wastelandservclean.sqf file but i think its kinda buggy and not very effective.

[Caliban55]

Glad that the desync option worked for you.

Wait, you have the debug console enabled on your server? This is a big no-go security wise, as anyone can issue commands through the console. Should never be enabled on a MP server.

For what you have in mind cleaning destroyed objects (this includes AI unit corpses), you can use the BI manager module. To do this, for wrecks in this case, define the following values in your description.ext file:

wreckLimit = PUT_A_LIMIT_NUMBER_HERE;
wreckRemovalMinTime = PUT_A_TIME_HERE;
wreckRemovalMaxTime = PUT_A_TIME_HERE;

For example:

Code: Select all

wreckLimit =5;
wreckRemovalMinTime = 1;
wreckRemovalMaxTime = 1800;

With the upcoming version 1.28, you can (and should) also use the manager mode configuration command:

Code: Select all

wreckManagerMode

The same option is available for corpses.

The debug console can (and should) be disabled by the following command:

Code: Select all

enableDebugConsole = 0;

Link to the available commands for the description.ext:
https://community.bistudio.com/wiki/Description.ext

[J-English]

thnx calib!

to disable the debug command will this go into our server.cfg ?

enableDebugConsole = 0;

[Caliban55]

No, enableDebugConsole is a parameter command that has to be put into the description.ext (and only there, any other place will have no effect).