Page MenuHomeFeedback Tracker

Linux: Startup -maxMem= values beyond 2047 are broken
New, WishlistPublic

Description

Starting the Linux Dedicated Server with -maxMem= values significantly larger than 2047 reduces the memory available to the server process (compared to -maxMem=2047). This significantly reduces server performance and even prevents some missions from loading at all.

I attached my memory usage measurements taken with -maxMem=2047 and -maxMem=4095 (which is approximately the maximum amount of memory a 32-bit user-space process can utilize when running on a 64-bit kernel). Each line is structured as follows: unix timestamp, virtual memory in MiB, reserved memory in MiB, entire process' cpu time (seconds), individual threads' cpu time (seconds). The values are measured every second from server starup until termination via #shutdown.

Use proc_stat_maxmem_2047.log as reference:

  • After startup (no mission is loaded by default) the RSS idles at 283M during mission voting.
  • After a mission is loaded the RSS peaks at 1122M until the server is #shutdown.

Now proc_stat_maxmem_4095.log shows reduced memory usage:

  • During startup the RSS peaks at 253M and drops to 137M during mission voting.
  • Once a mission loads the RSS peaks at 979M, but the mission fails to load (clients return to the mission voting screen).
  • Back to the mission voting screen the RSS idles at 711M. {F25407} {F25408}

Details

Legacy ID
2953472216
Severity
None
Resolution
Open
Reproducibility
Always
Category
Dedicated Server
Steps To Reproduce
  1. start dedicated server with -maxMem=2047
  2. load mission and monitor server process' memory usage
  3. start with -maxMem=4095

4a. monitor memory usage, values will be lower than previous measurements
OR
4b. mission fails to load (clients will drop back to mission vote screen)

Additional Information

I assume this is due to -maxMem= being parsed into a (signed!) int32_t which is then left shifted by 20. This results in values >= 2048 to wrap around to negative values. Using -maxMem=6143 apparently produces the same behaviour as -maxMem=2047, since the value overflows by exactely the range of an (u)int32_t (2047+4096 = 6143).

Event Timeline

Actium edited Steps To Reproduce. (Show Details)Jan 17 2015, 12:15 AM
Actium edited Additional Information. (Show Details)
Actium set Category to Dedicated Server.
Actium set Reproducibility to Always.
Actium set Severity to None.
Actium set Resolution to Open.
Actium set Legacy ID to 2953472216.May 7 2016, 8:06 PM
Actium added a subscriber: Actium.

This bug is related to bug #22323.

servers are still limited to 2047

while i think arma should better report its errors, it otherwise would not be expected that a server be run with incorrect settings

Firstly, according the the Biki values higher than 2047 will fall back to 2047, which is not what happens: https://community.bistudio.com/wiki/Arma_3_Startup_Parameters#Performance

Secondly, 64-bit Linux kernels have always granted 32-bit user-space applications the entire 32-bit address-space (unlike Windows which requires a 32-bit executable to be linked with /LARGEADDRESSAWARE to unlock the full 4 GiB). Consequently I consider 0 to 4096 a logical and thus valid range for -maxMem=.

Thirdly, this is an integer overflow due to an unchecked input parameter, which is always(!) a software bug. If a user can supply parameters which can lead to unexpected behaviour this must be caught by the application in question.

Fourthly, the -maxMem= values do not behave as advertised. Apparently the server uses way more memory than permitted via -maxMem= (after the integer overflow), but at some point fails anyway.

i'm not disagreeing that the game should handle the error correctly, but simply responding to your title that 'values beyond 2047 are broken' - only the error handling is broken; i could have phrased my sentence better

if the server only supports 2047 internally, it only supports 2047 (regardless of x64 linux), and to put a larger value is intentionally trying to break it, in other words, 'undefined behavior' - it is not to be expected in a real operating scenario.

that said, the wiki needs to be updated to clarify which options and defaults apply to only the Game, and Server; for example i believe the game actually supports 3072 (unless that never made it out of dev-branch - http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2721184&highlight=maxmem#post2721184 )

edit:
+1, title is technically correct :D