Lagging because of memory paging errors

[schoschi666 10]

I noticed something intresting on my system:

Most of the time Arma3 starts to lagg and my fps drop below 30 (while they're most of the time in sp-missions above 40fps, Arma3Bench Stratis shows 55 fps avg), the Windows performance monitor is showing in the memory area under "paging errors" some peaks, sometimes massive peaks, while it shows a zero-line when Arma runs smooth.

While my CPU-0 (the most demanded core) usage is pretty steady below 80% and shows no correlation to the laggs, and my SLI GPUs are just bored anyway.

Paging error means, that a process needs to access data that was put from physical RAM into the virtual memory, which is the paging file of windows (on a SSD in my case).

Since I have 8GB RAM and the physical memory usage by the system while running SIXTupdater, Addons and ARM3 is only about 50%, I guess the paging errors happen, because Arma can only use like 2GB of RAM and further Arma data is then put into the virtual memory by the system, and if Arma needs to access that data (from HDD/SSD) it laggs and fps drops.

Performance monitor shows that Arma3 uses most of the time like 1900MB of physical RAM, and like 1700MB of virtual RAM.

I guess this is a general RAM usage issue of Arma, and not just my system.

I thought about a possible solution: Why not use a RAMdisk and then set the windows paging file location to it, so everytime the inevitable virtual memory swaping of Arma and access of that data happens it actually happens on RAM too, an not the HDD/SSD?

This should make Arma perform even better than using the RAMdisk to copy the whole arma files on it, because then arma would still use virtual memory on the HDD/SSD!

One would need like 16GB to be able to set a big enough RAMdisk for windows paging file.

Edited August 11, 2014 by Schoschi666

[flyinpenguin 30]

Dude, that is a brilliant idea! Im going to explore this a bit and come back here with some results. I personally have 12Gb of RAM but in a bad format because I fried a stick of 4Gb :p If I can specify that extra third stick not running in dual channel to be this... that would be epic. Anyways, glad you posted this. Never would have thought of using a RAMdisk to bypass bohemia's silly 2Gb restriction

---------- Post added at 00:57 ---------- Previous post was at 00:34 ----------

Well I tried it out. It smoothed the lag out, but did not increase my frames dramatically like I was hoping. So it does seem like a viable option to use to help improve performance, but definitely will not suddenly make your frames increase a ton. I will probably run this setup for a while and see if I can't break my machine :p

[Harzach 2517]

In a 64-bit environment, putting your paging file on RAMdisk makes no sense.

RAM (GB) = X

Paging file (GB) = Y

System commit limit = X + Y

You are reserving RAM to use as (less efficient) VRAM when you run out of ... RAM. Placing the paging file on RAM effectively reduces your total system commit by the size of the paging file.

By the time you have enough RAM for this to not matter, there is no longer any reason to do it. Increase/upgrade your RAM and be done with it.

Of course, if you are still working in a 32-bit environment, it's a perfectly viable solution - 4 GB RAM max system memory plus an extra X GB for RAMdisk.

[flyinpenguin 30]

Whereas you are correct in normal circumstances, Arma is an exception. As I understand it, Arma limits the amount of RAM you can use to roughly 2Gb and then starts using the paging file even when there is still RAM available.

[schoschi666 10]

In a 64-bit environment, putting your paging file on RAMdisk makes no sense.

RAM (GB) = X

Paging file (GB) = Y

System commit limit = X + Y

You are reserving RAM to use as (less efficient) VRAM when you run out of ... RAM. Placing the paging file on RAM effectively reduces your total system commit by the size of the paging file.

By the time you have enough RAM for this to not matter, there is no longer any reason to do it. Increase/upgrade your RAM and be done with it.

Of course, if you are still working in a 32-bit environment, it's a perfectly viable solution - 4 GB RAM max system memory plus an extra X GB for RAMdisk.

I know this is how VRAM is supposed/called to work, but it seems like it doesnt for ARMA!?

I use Windows 7 64bit, and like I said, while overall physical RAM usage of my 8GBs when playing Arma is around 50% (so I'm not running out of it), Arma only takes like 1900MB of it (max mem set to 4000, using tbb3malloc custom memory allocater for Arma doesnt help either) and still uses 1700MB of virtual memory, while 4GB physicaly are still available!? (at least thats what windows performance monitor says)

Also the lagging clearly correlates with said memory paging "error" peaks.

Please check this yourself on your system: run Windows performance monitor (task-manager->performance monitor), switch to the "memory" tab, start Arma and play a singleplayer mission, if you experience lagging and fps drop (use fps display) wait a few seconds and then alt-tab to windows desktop with the performance monitor, notice that alt-tabbing out of Arma produces a paging-error peak itself, but there should be some more previous ones in the diagram.

I can't find any other reason for the lagging, CPU diagram courses look unremarkable, yes CPU-0 is more stressed than others but no clear peaks correlated to the lagging, Arma running as high priority process (not realtime), speedstepping and core parking dactivated, GPU performance usage drops from around 50% to below 40% when the lagging occurs because it seems they need to wait for some other bottleneck and can't perform, Arma and Windows are on dedicated SSDs, tried every tweaking like "gime more frames" registry tweak and tbb3malloc custom memory allocater....

still I get lagging and framerate drops to below 30fps, while normally I have above 40fps, Arma3Bench Stratis shows 55 fps average and 39 fps minimum, Altis 49 fps avg, though strangely on some runs those benchs perform 20% worse

Edited August 11, 2014 by Schoschi666