fred41

... thanks for your log files ... There are early fallbacks to small page memory usage, in all log files. Large pages are faster accessed compared to small pages. So it makes sense to improve the availability of large pages. Your 32GB system has a great potential to optimize the memory usage for tbbmalloc. The following hints could be helpful, to get the max. memory performance: 1. Restart your system more often (your logs show, that your server was up for more then 40 days) 2. Try to free some physical RAM, by disabling not used background applications/services, shrinking RAM disk, if exists, e.t.c. 3. Try a larger pagefile too (fixed size) Greets, Fred41

@1212PDMCDMPPM, the allocation performance on your win8.1 system is generally very good. The availability of large pages is 100%. The slower allocation times for some allocations in your log (~100ms) are probably caused by, ether peakes in system usage (overall CPU load) or specifically peakes in memory manager usage (thread/core load). This could be perhaps caused by other applications running in the background or arma (mission) itself? Do you have a RAM disk running? More then 4GB phys. RAM are used already before arma starts, you could try to free some RAM. You could also try to increase the size of your pagefile to recommendet size (~24GB, fixed size). Greets, Fred41

... thanks for your feedback ... There should be one log file per session in your A3 root dir 'malloc_.....log'. Please post this file here and let us see if tbbmaloc works correctly on your system. For detailed instruction how to install and use this allocator, please read the readme.md in my github repository (see initial post for a link). Greets, Fred41

PS. I stumbled upon this rather old item about Arma's memory management. I'm pretty sure you are aware of it, but just in case: http://www.bistudio.com/english/company/developers-blog/85-breaking-the-32-bit-barrier ... yes, i already know this document (honestly some parts make me still smile a bit and i am sure everybody familiar with the windows API can't resist too :) )

... you are running more then one ASM instances in server mode simultanous on the same system, that makes no sense and results in some resource conflicts ... ASM is able to monitor up to 4 arma server instances simultanous, while running only ONE ASM instance in server mode. As you already found out, switching back from tranparency mode is only possible by hitting a non transparent area in the ASM window :) Greets, Fred41

@NoPOW, thanks for your logs. I am done with investigating this part of allocator, so i currently don't need more log files with this experimental build. A question, is the 16GB RAM-disk really improving performance/smoothness for your system? @Viba, thanks to you too. Some hints for you: Your 16GB A2 server logs are looking fíne. Your 8GB A2 client system needs attention, there are early fallbacks to small pages. Because the use of large pages increase performance, you could try to make more of them available. 1. On your client system are already more then 2GB physical RAM used before arma starts. Try to free a bit of this RAM, by disabling/avoiding the start of unused applications/services. 2. Restart your client system more often to defragment physical memory. 3. The size of our pagefile could be increased. Try a fixed size pagefile, use the recommended value for size. @Grillob3, thanks. I plan to update the stable malloc build soon. Greets, Fred41

... good idea, and done :) ---------- Post added at 21:04 ---------- Previous post was at 20:52 ---------- ... only the user account, which is used to start arma need the 'lock pages in memory' privileg set ... I tried to explain this in the readme.md (github, see initial post for link). Greets, Fred41

@jonashendrickx, see post #167 and #171 in this thread for a solution. @NoPow, thanks again. You are the most helping man here :) The stuff i currently try to verify, requires longer arma runs. Specifically, because i have to observe the evolution/accumulation of some overhead/buffers. If you could provide more longer logs (perhaps via pastebin), this would be helpful. Everybody else: I still need logs from arma servers, running the experimental build for many hours/days !!! Greets, Fred41

... did you follow the hints from post #282, and still fallbacks to small pages (SP) in your log? ---------- Post added at 19:57 ---------- Previous post was at 19:56 ---------- @NoPOW, ok thanks.

@NoPow, thanks for your log. Could you please post the full log (to pastebin, i.e.), because i need more of this 'BS:' lines inside the session?

minor update: for all users with old/bad eyes (like me) or with large monitors, you can now add -b to the command line. The usage of -b param results in: - larger font size for variable fields - bolder graph lines in history view - more 'high' for user interface used per instance

@doveman, thanks for your report. Such crashes can have many reasons. Sometimes you find valuable informations about the crash reason, in your related .rpt file. The malloc log file that you posted is only 12 seconds in duration, so it is probably not related to the crash. Some few crashes, i got in the last months, were all related to phys_x. Intels memory allocator is very solid coded and the modification i made, are only of subtile nature.

... exactly ... DllTest.exe is a little tool to simulate arma sending data via ASMdll.dll. It is for testing data flow and output only. DLL and FSM folder are containing the 'source' files, just in case you want to code something similiar to ASM and have no clue how to start :)

@Krycek_dk, see post #167 and #171 in this thread for a solution.

@Tankbuster, i am sorry i have to tell you, this idea has not much chances to be real. My son has left arma weeks ago and this 'smart device' idea was planned to teach him a bit coding, while having fun with iPod :/ @Zach72, this sounds misterious. I assume you know that @ASM consist of 3 essential components: 1. fn_ASM.fsm (included in ASM.pbo, 'addons' folder or '@ASM\addons' folder) 2. ASM.dll (+asm.ini, a3 root dir) 3. ArmaServerMonitor.exe (can run from everywhere) This 3 components are exchanging data in a specific format and therefore they must 100% of same version (preferable the latest and most advanced). To ensure this, the best way to update is updating all files together, otherwise you will have strange data displayed. Did you shutdown all arma instances, while replacing the .dll?

@Nuno Basto, some hints for your system: - restart yourt box more often (system is already 34 days up and 6GB phys. RAM are already occupied before arma starts) - set a pagefile of fixed size, use the recommended size as a start (~24GB) - disable applications/services, wich you don't really need This way you would improve the availability of large pages on your system a lot. @jonashendrickx, i am a bit unsure, how i can help you. It seems to be a very specific problem on your system (wrong mission, virus, what ever).

EXPERIMENTAL BUILD UPDATED: - overhead caused by fragmentation reduced significantly, from upto 40%, down to just +5% (experimental build only) Please test this new build and post me your log file. Especially on long running server, a much lower memory footprint should be observable. Greets, Fred41

@Nuno_Basto, it should be possible to find out, what account TADST use to start arma? First idea: taskmanager (while arma server is running), tab->processes, select 'show processes from all users' Then add this user to the privileged users/groups via secpol.msc. Restart. If this not work immediately, try to start TADST via 'Run as Administrator'. @NoPOW, thanks for running experimental and posting feedback. Your log seems to confirm, what i already assumed, when investigating dwardens server log files. What mission did you run here? @SpanishSurfer, your log file tells, that your system probably runs great. There are 100% large pages available, even if your system is up for nearly 4 days, before this session started and you had only 7.6GB phys. RAM free. Only suggestion for your system: Check your logfile from time to time and find out how often you have to restart your box (fallback). I think something like once per week could be enough for such a clean system. If you want support research, you could run the experimental build. There are some more data in the logfile, to investigate internal behavoir under arma load. Greets, Fred41

One thing more: If the user account, which is used to run arma, is in the adminstrator group, then you MUST start arma with 'run as administrator' too (because of UAC).

... really nice video, sometimes one gesture can say more then 1000th words :D Let's hope that BI is less arrogant. And of course, an minimal-overhead api, like MANTLE, should unload our overused mainthread a lot (arma, dayz, ......).

... when is your birthday :P minor update: different shades of gray used for gridlines in history graph, for better approximation of time and values

@Nuno Basto, always use the latest build from github repository (see initial post for link), or use the experimental build to support research (see link at post #267). Did you set the 'lock pages in memory' privileg correctly? Did you restart your system once?

... you shouldn't be unhappy ;) UPDATE: Added a -wwidth param (for commandline), to set the horizontal number of pixels/samples for historygraph. For best scaling, use a multiple of 300 for this width value. usage example: ArmaServerMonitor.exe -server -n2 -lASMlog -t2 -w1200 And now dwarden, don't forget our deal, i think at least stable 50 FPS in all MP situations, would be appropriate :cool:

minor update: - added vertical gridlines, for each 60 pixel/seconds, for more intuitive time aproximation - added hints to most of variable fields, to help new users understanding meanings of fields - changed the width of history windows from 800 to 600 pixel (scales to exactly 10 minutes now) and supports smaller monitors

INTERNAL FRAGMENTATION CHECK ADDED: For further optimizations, i added a fragmentation check to the latest experimental build. This feature logs around each 20 sec., the amount of different, empty memory blocks from internal lists. You can help to improve this allocator, by running this experimental binary on your (full) server for some hours: https://github.com/fred41/tbbmalloc_arma/tree/master/binary_experimental It would be helpful, if your feedback contains informations like: - map/mission running - average player number - average local AI number So there are 3 builds now available: stable, folder binary stable without any log, folder binary_nolog experimental, folder binary_experimental Thanks for support in advance, Fred41 ---------- Post added at 13:16 ---------- Previous post was at 13:01 ---------- @Denco, it is very likely, that other applications in the background are consuming some of your 8GB RAM. Check with taskmanager/processexplorer, what applications this are and terminate them, if possible. Arma currently shouldn't use more RAM than 4GB (max. virt. address space) + ~1.6GB (stream buffer) = 5.6GB. So, there should be normally enough left, from your 8 GB, on a clean system.