fred41

... this mallocxxxx.log file should be always generated by tbbmalloc (not by arma) ...

... just merge GMF_off.reg (see github repo, as administrator) or use regedit to change in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3.exe] value 'UseLargePages' manually back to 0 ... ---------- Post added at 19:08 ---------- Previous post was at 19:06 ---------- ... have you take a look in your mallocxxxx.log file (a3 rootdir), to verify that large pages are fully used?

... i am declined to agree, not ok ... The 'Lock pages in memory' privilege is obviously set correctly, but the physical RAM is heaviest fragmented, the result is, that windows can't find enough continous blocks to map as large pages for arma/tbbmalloc. Try to cleanup your system from unnecessary background processes/services, to free some RAM and to delay fragmentation. Read a bit in this thread, there are already a lot of additional hints. Greets, Fred41

@GodAmongMen, thanks for helping out :) I thing it is not a big challenge to find out, that this devbranch bug occurs with or without this tweak.

UPDATE: Since ASM supports upto 16 instances per system now, it is not optimal that 'slots' are still selected per first free slot first. To control which slot is prefered by an specific instance, you can now prefix the profilename with a number in range 0..15. example to select slot number 12 (zero based): -name=12MyServerWhatever In ASM.ini, a new param enableProfilePrefixSlotSelection=0/1, can be used to switch this new slot selection behavoir off/on (default 1/on).

... did you follow this hint: - find out the name of user account, that is used to run arma (start arma as usual, then open taskmanager and look for: 'taskmanager'->'processes'->'User Name' of arma3.exe process) ?

minor update for GMF.exe: - for simplified usage, GMF now prompts you for useraccountname in console window (please see initial post for changed usage details)

... because i don't own win8.1, may i ask you to make a snapshot with VMMAP (sysinternals), while arma3.exe is running? (open VMMAP, select arma3.exe process, 'FILE'->'Save as ...')

... hmmm, the only idea i have, is that your registry key value could be incorrect. Did you tried merging GMF_on.reg (right click-> merge)? ---------- Post added at 19:20 ---------- Previous post was at 18:29 ---------- ... yes you have to type your commands in the black console window, that is opened via cmd.exe ('Run as administrator') ...

UPDATE/FIX: I found an old debug line in ASMdll.dll, that could cause performance problems, while running many instances on same system, together with very high player numbers (only with enabled API monitoring, thx dwarden for report). Only the ASMdll.dll have to be replaced for this update. Greets, Fred41

... this "bcdedit /set increaseuserva" is used for 32bit OS to adjust the available virtual address space for applications and OS ... Unfortunately, the availability of large pages (continous blocks of 2 MB in physical RAM) is nothing we can enforce on windows OS. All we can do is to maintain our system as clear as possible or to allocate the memory as soon as possible past system start. But thanks for your hint.

... yes, i did ... There is everything well related to allocator setup (100% large pages). But, in your .rpt file, i see some mission related problems (syntax error in SM_CleanUp.sqf).

... no, your arma3.exe image is clearly mapped in a small page region here, mapped as large pages, the size of image region should be a multiple of 2MB (2048kB or 2048*1024B) ... ---------- Post added at 16:23 ---------- Previous post was at 16:19 ---------- @[FRL]Myke, ... and learned something again ... :D

wth means 'pebkac', please:confused:

@k0rd, this or something similiar :) (many systems are running tons of useless processes in the background and wasting a lot of resources this way, not only memory) @Hunkii, downloading binary files from github is a bit tricky: Use the 'RAW' button to download the tbbmalloc.dll as binary file. (i tried to give a related hint in initial post)

... assuming you mean UAC-settings at 'never notify', i would say yes ...

I think it is very unlikely, that this registry tweak has any effect to SweetFX. You could just set the related registry value 'UseLargePages' to 0, to fully disable this tweak and check what happens.

@NoPOW, exactly. The registry tweak it self, is per application (useraccount independend), the privilege is per useraccount/group.

I would recommend to make a desktop shortcut to start arma3.exe directly and if needed use 'Run as administrator' via right mouse click (you can start steam manually before arma). Bar in mind: Only, for useraccounts, that are member of the administrator group, you have to start arma via 'Run as administrator'. If your account, used to run arma, is not member of the administrator group and you have the privilege successfully granted to this account, then you can start arma as usual. Greets, Fred41

@Devast8nDiscoDave, really nice tool, but does it set the required privilege for non admin accounts too?

@Cyruz, thanks for sharing your experience.

... an additional, probably important hint for everybody running arma under a useraccount that is member of the Administrator group: You have to start arma via 'Run as administrator' too, in this case (because of UAC). An other (more secure) option is, to make an normal account (not member of the administrator group) to run arma. Greets, Fred41

@Greenfist and @mamasan8, thanks for helping out. Correct, setting 'UseLargePages' to 0, will fully disable this tweak. I think the biggest problem is, that users don't know, what useraccountname they should use with 'GMF.exe useraccountname'. I added a hint in initial post to hopefully make things more clear: - find out the name of user account, that is used to run arma (start arma, 'taskmanager'->'processes'->'User Name') @tarabas666, german secpol.msc terms are: 'Locale Richtlinien'->'Zuweisen von Benutzerrechten'->'Sperren von Seiten im Speicher' Greets, Fred41

... system cleaning has the best effect (considering it is free), but more RAM relaxes something too, means memory fragmentation is delayed with more RAM ...

... didn't realize there is an overall limit of 300 messages, should work now :) ---------- Post added at 17:01 ---------- Previous post was at 16:41 ---------- UPDATE: - for users with more then 4 instances (up to 16) a new commandline param, -o is introduced with this update - you can run upto 4 ASMs in server mode on same system, monitoring upto 4 arma server instances each, using different -o params (the param -o selects one of 4 instance blocks) Example for monitoring instance 5-8, use -o1 for ASM server (and the same for ASM client for remote monitoring) (UDP port numbers are calculated automatical based on your selected port settings)