How to measure VAS with FSUIPC


measuring-vas-fsuipc2.pngYou can measure the status of the VAS using FSUIPC and place the measurement on screen.

If you don’t know what VAS is, please read first this post :: How Memory is Managed by the OS.
Further you can read all about Memory issues in this category.

With FSUIPC you can measure the Available FS memory (as it is called in the FSUIPC Offset Status.pdf). With the offset code 024C with Type S32 you measure the Available Virtual Address Space in kilobytes. This value is updated every 10 seconds.

The Available VAS + the Virtual Size of the process Prepar3D.exe equals ± 4GB as being the total VAS space for each 32 bits process. With other words: the  4GB VAS space minus the virtual size of the process Prepar3D.exe equals the remaining available virtual address space. When this VAS space is consumed…you get an OOM error message.vas-maxed-out2.png

How to show Available VAS on screen.

  1. In Prepar3D open Add-ons – FSUIPC and select tab Logging.
  2. Check: IPC reads  in Log Details and FS Window (or FS Title Bar) in Display to
  3. Fill Offset = 024C and Type =32 in the Specific value checks
  4. Close with OK
  5. You can drag and resize the green FS Window bar as desired to any convenient place on the screen. Once configured in FSUIPC it will appear again at next start.

measuring-vas-fsuipc.pngYou could also place the information in the FS Title Bar for a better reading result.

The value in the Title bar is read as 2643028 x KB=2.643 MB …as we speak of 2.6 GB.vas-maxed out3.PNG

How could you reach an OOM situation on startup?


vas-maxed-out1.png

In the image above you see the development of a coming OOM:: Out of Memory situation of the virtual address space. When a value of 4096 MB  (4GB) is reached, you get this message:vas-maxed-out2.png

How could you reach an OOM situation on startup?

start-scenario.pngThere are 2 possibilities for start after you have activated prepar3d.exe. Either the previous flight starts or the Prepar3D® Training Scenario Setup screen is activated.

When scrolling through the list of airplanes, textures are loaded. The texture map pages textures out if they have not been used in 10 seconds.  

Unfortunately, the timer used to age texture has not been initialized yet when the scenario start-up screen loads.  

The textures for the aircraft you looked at, but didn’t pick, will stay loaded until roughly 10 seconds after the simulation finishes loading.  This makes it much easier to run out of memory on startup.  

If you go to the vehicle select screen, after the sim is loaded up, the textures should page out ok while in the preview screen.  You can still have issues if you scroll too fast though because of the 10 second limit.  

For the next release, Update 2.5,  textures will page out in both versions of the vehicle select screen and the textures will page our much more quickly.

Issue is soved in V2.5

Source: Prepar3D®


How to prevent?

Select_vehicle-01.pngAt startup of the sim with the Prepar3D® Training Scenario Setup screen the virtual space is used for approx. 0.8 GB.

When scrolling through the list of airplanes with its different textures, each airplane will consume an amount of VAS.

At the moment you reach the 4GB limit you get the OOM error message.

If you won’t run the risk of OOM at startup, you could reduce the number of airplanes in the folder ../Simobjects/Airplanes, so you have little to choose (little to scroll) OR you start the sim with the Previous Flight which automatically runs at startup.

If you want to change the aircraft then, just go to Vehicles select screen and select the vehicle. You could also reduce the risk when you make a list of your Favorites. (Hit the asterix on the line of your choice and check the asterix “Show Only Favorites”).

According to Prepar3D® this should be improved in the next release.

If you want to watch the development of your VAS with FSUIPC click HERE to read how you can view on screen.

Monitoring RAM and virtual memory usage


perfmonitor-2Performance Monitor is the principle tool for monitoring system performance and for identifying the location of the bottleneck. To start Performance Monitor, click Start, click Control Panel, click Administrative Tools, and then double-click Performance Monitor. Here is a summary of some important counters and what they tell you:

  • Memory, Committed Bytes:
    This counter is a measure of the demand for virtual memory.
    This shows how many bytes were allocated by processes and to which the operating system has committed a RAM page frame or a page slot in the pagefile (or perhaps both). As Committed Bytes grows greater than the available RAM, paging will increase, and the pagefile size that is being used will also increase. At some point, paging activity starts to significantly affect performance.
  • Process, Working Set, _Total:
    This counter is a measure of the virtual memory in “active” use.
    This counter shows how much RAM is required so that the virtual memory being used for all processes is in RAM. This value is always a multiple of 4,096, which is the page size that is used in Windows. As demand for virtual memory increases beyond the available RAM, the operating system adjusts how much of a process’s virtual memory is in its Working Set to optimize available RAM usage and minimize paging.
  • Paging File, %pagefile in use:
    This counter is a measure of how much of the pagefile is actually being used.
    Use this counter to determine whether the pagefile is an appropriate size. If this counter reaches 100, the pagefile is full, and things will stop working. Depending on the volatility of your workload, you probably want the pagefile large enough so that it is generally no more than 50-075 percent used. If much of the pagefile is being used, having more than one on different physical disks, may improve performance.
  • Memory, Pages/Sec:
    This counter is one of the most misunderstood measures.
    A high value for this counter does not necessarily imply that your performance bottleneck stems from a shortage of RAM. The operating system uses the paging system for purposes other than swapping pages because of memory over-commitment.
  • Memory, Pages Output/Sec:
    This counter shows how many virtual memory pages were written to the pagefile to free RAM page frames for other purposes each second.
    This is the best counter to monitor if you suspect that paging is your performance bottleneck. Even if Committed Bytes is greater than the installed RAM, if Pages Output/sec is low or zero most of the time, there is no significant performance problem from insufficient RAM.
  • Memory, Cache Bytes,
    Memory, Pool Nonpaged Bytes,
    Memory, Pool Paged Bytes,
    Memory, System Code Total Bytes,
    Memory, System Driver Total Bytes:
    The sum of these counters is a measure of how much of the 2 GB of the shared part of the 4-GB virtual address space is actually being used. Use these to determine whether your system is reaching one of the architectural limits.
  • Memory, Available MBytes:
    This counter measures how much RAM is available to satisfy demands for virtual memory (either new allocations, or for restoring a page from the pagefile).
    When RAM is in short supply (for example, Committed Bytes is greater than installed RAM), the operating system will try to keep a certain fraction of installed RAM available for immediate use by copying virtual memory pages that are not in active use to the pagefile. Therefore, this counter will not reach zero and is not necessarily a good indication of whether your system is short of RAM.

Source: Microsoft

4GB Patch for FSX.EXE


Lets’ start with current available information from MSDN:
On 32-bit editions of Windows, applications have 4 gigabyte (GB) of virtual address space available. The virtual address space is divided so that 2 GB is available to the application and the other 2 GB is available only to the system.
The 4-gigabyte tuning (4GT) feature, formerly called 4GT RAM Tuning, increases the virtual address space that is available to the application up to 3 GB, and reduces the amount available to the system to between 1 and 2 GB.
For applications that are memory-intensive, such as our FSX app, the use of a larger virtual address space can provide considerable performance and scalability benefits.

However, the file cache, paged pool, and nonpaged pool are smaller, which can adversely affect applications with heavy networking or I/O. Therefore, you might want to test your application under load, and examine the performance counters to determine whether your application benefits from the larger address space.
To enable 4GT, use the BCDEdit /set command to set the increaseuserva boot entry option to a value between 2048 (2 GB) and 3072 (3 GB).
The /3GB switch is supported on 32-bit editions like Windows XP Professional, VISTA, W7X32.

The /3GB switch makes a full 3 GB of virtual address space available to applications and reduces the amount available to the system to 1 GB. On Windows Server 2003, the amount of address space available to applications can be adjusted by setting the /USERVA switch in Boot.ini to a value between 2048 and 3072, which increases the amount of address space available to the system. This can help maintain overall system performance when the application requires more than 2 GB but less than 3 GB of address space.

To enable an application to use the larger address space, set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header. The linker included with Microsoft Visual C++ supports the /LARGEADDRESSAWARE switch to set this flag. Setting this flag and then running the application on a system that does not have 4GT support should not affect the application.

On 64-bit editions of Windows, 32-bit applications marked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag have 4 GB of address space available.

fsx_exe_4GB.PNGThis very little tool patches our x86 executable fsx.exe in order to let it have 4GB (instead of only 2GB) of virtual memory on x64 platforms. To gain these 2GB, you just have to use this tool to patch the executable (*.exe file) of the software you want to have these additional GB’s of virtual memory.

You can download the tool from this website.
It can be used by clicking on it and choosing the file or through command line (e.g.: “4gb_patch file.exe”).
It automatically creates a backup copy of the original executable.

A modified fsx.exe (SP2) is available upon request via our download page.

Resources: MSDN, NTCORE.com

Address Space Monitor


Address Space Monitor is a simple utility to monitor a process’ use of its address space.  To begin monitoring a process, choose the “Process|Attach …” menu option and type in the process id of the process to be monitored. The “Attach to process” dialog box now features a process browser so that you can select the process by name.

Alternatively you can choose to spawn a new process. If you select the “Process|Run…” menu option you will be presented with the “Run” dialog box. From here you can browse for the executable file for the process you wish to start and the initial working directory for the process. You can also enter in any required command line arguments.

While monitoring a process, the display is split into three sections.

The top section shows the address space of the process in a gauge format, from low addresses (close to zero) on the left, rotating clockwise to high addresses (2GB for 32-bit processes, 8TB for 64-bit processes) on the right.

Free address space is shown in green, reserved addresses in yellow and used (committed) memory regions in red.

The next section of the display shows the largest free regions of address space as colored ellipses in descending order of size. The full width of the display represents a quarter of the total address space for the process (about 512MB for 32-bit processes, about 2TB for 64-bit processes) and large regions are shown as half an ellipse covering the full width of the display even if they exceed half the total address space.

The regions are colored according to their upper address so that they can be tracked as their lower parts are used up. Low regions start from yellow, going through magenta at half way, to cyan at the upper end of the address space.

The final section has some textual summaries for the address space.

The first number is the total amount of committed address space for the whole process,  the second number is the total amount of reserved address space for the process, the third number is the total amount of free memory and the final number is the size of the largest free address space region.

For committed and reserved regions these totals may be larger than what you might expect from looking at other memory analysis tools as all address space is counted, including mapped files and shared memory regions, rather than just regions which are mapped to physical memory or swap file space.

The utility has most use for 32-bit processes as 64-bit process tend to be dominated by a very large (only fractionally smaller that 8TB) region of free address space from the 2GB boundary upwards.

Address Space Monitor now supports recording both single snapshots of a process’ address space as well as recordings of a process’ address space over time. A snapshot can be recorded through the “File|Save as…” menu options, and redisplayed through the “File|Open…” option.

A recording can either be started through the “File|Record…” option or, when creating a new process, by selecting the “Record” check box in the “Run” dialog box and browsing for the name of a file to record. In both cases the recording will stop when the process being monitored exits. While recording the “File|Record…” menu option will display a tick icon. The recording can be halted manually by reselecting the “File|Record…” menu option while the menu option displays a tick mark.

The utility can be downloaded from HERE

Source: Charles Bailey.