'virtual memory', a often missunderstood concept ...

[fred41 42]

... just found this statement in latest SITREP #00166:

 

Sadly we're not really much closer to finding the cause of the potentially drastic performance degradation that some players experience at seemingly random play times. Clues do point to memory management, but it's not quite so straight forward as an identifiable 'memory leak' or a common factor among cases (e.g. little available RAM). The game appears to run out of available memory, and fails to negotiate for more from the OS for unknown reasons (a process which actually happens without problems quite often, via memory allocators).

 

From user reports, it looks like problems happens, when virtual memory used by arma process is 3000-3500MB.

 

Considering the fact that each user process on windows, has its own virtual address space and that arma is still a 32 bit process,

it seems natural that such problems are related to the limitation of 32 bit address space.

 

Even if the total 'mapped' virtual memory is still some hundreds MB below the limit of 4096MB, it is more likely that a request for a larger block of memory fails later,

simple because there is no continous block of virtual address left, large enough to map the requested ammount (fragmentation of address space).

 

This seems not to be fully understood and i hope my hint will help to rethink the current 'bug hunting' approach.

 

A recommended tool for address space analysis is VMMAP:

 

https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx

 

 

Regards

 

[lex__1 422]

https://feedback.bistudio.com/T118335

thanks for the address on vmmap

https://channel9.msdn.com/shows/defrag-tools/defrag-tools-7-vmmap

[lex__1 422]

... just found this statement in latest SITREP #00166:

 

 

From user reports, it looks like problems happens, when virtual memory used by arma process is 3000-3500MB.

 

Considering the fact that each user process on windows, has its own virtual address space and that arma is still a 32 bit process,

it seems natural that such problems are related to the limitation of 32 bit address space.

 

Even if the total 'mapped' virtual memory is still some hundreds MB below the limit of 4096MB, it is more likely that a request for a larger block of memory fails later,

simple because there is no continous block of virtual address left, large enough to map the requested ammount (fragmentation of address space).

 

This seems not to be fully understood and i hope my hint will help to rethink the current 'bug hunting' approach.

 

A recommended tool for address space analysis is VMMAP:

 

https://technet.microsoft.com/en-us/sysinternals/vmmap.aspx

 

 

Regards

The amount of VM process arma3.exe on startup ~ 1600-2000 MB. Through 30-40-60 minutes, the volume VM arma3.exe process reaches the limit of ~ 3200-3400mb.

If you withdraw from the mission, in the main menu of the game, VM arma3.exe process will not return to the initial volume of ~ 1600-2000 MB.

Arma3.exe process works like a pump to increase VM heap has no way of dumping of VM heap.

At the same time, the process arma3.exe uses RAM ~ 1200-2800mb.

Never takes the RAM above ~ 2800-2900mb.

The problem, acceptable volume overflow VM must not exist in any process for 32 bit/64 bit.

No error formation volume VM heap from the process. There is a problem the VM heap from the process, deallocation of unnecessary blocks.

[Dwarden 1125]

welcome 'back' fred41 ;) nice to see you still around