System Memory Considerations(Formerly Known as FAQ 1543)
Explore this Page
Overview
This guide helps understand how a DataCore Servers physical memory is used by SANsymphony and other DataCore drivers
and servers. It also gives general recommendations and requirements for optimum performance and stability.
Change Summary
Changes since June 2019
| Section(s) | Content Changes |
|---|---|
|
Added – New sections |
Cache in SANsymphony
How Much Physical Memory Do I Need?
The following table gives a rough estimate of the amount of physical memory a DataCore Server should have installed to help plan for any current and future requirements.
The values above are based on default SANsymphony cache, Disk Pool and Continuous Data Protection (CDP) History Log settings.
This amount of physical memory available to the DataCore Server will determine the amount that is reserved by SANsymphony for its own caching.
Refer to the Changing Cache Size documentation for more information.
When Does SANsymphony Reserve Memory for its Cache?
Whenever the SANsymphony software is started.
A check is made to see how much total physical memory is in the server (or in the case of a Hyperconverged DataCore Server - the virtual machine) and, using the values above, will try to reserve physical memory for its exclusive use.
How to Monitor SANsymphony’s Cache Allocation
Viewing DataCore Server object in the SANsymphony console
Select the DataCore Server and using the ‘Info’ tab locate how ‘RAM’ the DataCore Server can see and how much of that has been allocated for use with SANsymphony’s cache.
For example:
When the SANsymphony software is stopped, all system memory used for its cache is released back to the Windows operating system.
For example:
How can I view the cache size using the SANsymphony Console ‘Live Performance’ feature?
To view the cache size:
- Open the DataCore Management Console and select the Home tab.
- Click Live Performance.
- In the Category column, select DataCore Servers.
- In the Instances column, select the desired DataCore Server(s).
- In the Counters column, select Cache Size, then click Add.
- The value displayed in the Max column shows the amount of cache reserved by SANsymphony.
- Ignore the Last, Average, and Min values, as they may be misleading. During startup or shutdown, SANsymphony gradually loads or unloads allocated system memory, which can skew these readings.
How do DataCore Drivers and Services Use System Memory?
DataCore System Drivers
From SANsymphony version 10.0 PSP2 and later, all DataCore system drivers (Dcs*.sys), if required, will use up to a total of 40% of the system memory already reserved by SANsymphony.
This prevents accidental consumption of the remaining system memory used by the Windows operating system and other third-party applications and services, which could make the DataCore Server unstable. However, if additional system memory is still required by the DataCore system drivers, they will also use any remaining system memory.
Other DataCore services
The DataCore Console and all other DataCore services (Executive, SNMP Agent, Intelligence, Performance Monitor, Updater, etc.) will not use memory already assigned to SANsymphony.
This behavior is not configurable.
Why Does the DcsAddMem.exe Process Appear in Windows Task Manager After SANsymphony Starts?
Whenever SANsymphony is started, the DcsAddMem.exe process runs and begins allocating system memory from the Windows operating system exclusively for SANsymphony’s cache. Refer to the Cache in SANsymphony section.
However, after the system memory has been allocated, DcsAddMem.exe will still appear in Windows Task Manager even though the process is no longer running. Over time, the size of the memory assigned to DcsAddMem.exe in Task Manager may start to shrink, and in some cases, the process may disappear from Task Manager completely, even though SANsymphony is still running.
This does not mean that SANsymphony has less or no memory for its cache. It is simply an idiosyncrasy of how Task Manager handles the DcsAddMem.exe process after SANsymphony has started. Therefore, using the DcsAddMem.exe process in Task Manager to determine the amount of memory used by SANsymphony is not reliable.
To track how much memory is really being used by SANsymphony, refer to How to Monitor SANsymphony’s Cache Allocation for more information.
What Is the DataCore Executive Service and How Does It Use Memory?
The DataCore Executive Service provides a communication interface between all “user-level” applications and the DataCore system drivers. These applications include:
- SANsymphony Console
- DataCore PowerShell Cmdlets
- SANsymphony’s vCenter Integration
- DataCore Microsoft and vSphere plugins
In addition, the service is responsible for:
- Monitoring and displaying performance statistics (e.g., Live Performance, Performance Recording, and Storage Allocation statistics for Disk Pools and vDisks).See “Performance Recording” on page 10.
- Reporting status updates from specific DataCore system drivers for different objects in the SANsymphony Console (e.g., mirror recovery progress, Disk Pool statuses, and Port statuses).
- Updating and distributing configuration changes between DataCore Servers within the same Server Group and/or remote Replication Groups.
- Transmitting Asynchronous Replication Data to remote Replication Groups. See “Asynchronous Replication” on page 9.
Memory Usage
The memory requirements for this service increase based on:
- The number of tasks it is performing.
- The number of objects (Physical Disks, Disk Pools, virtual disks, Ports, and Hosts) in the configuration.
As tasks are completed (e.g., a Performance Recording session ends) or as the configuration reduces (example: vDisks are removed), memory usage decreases.
Because of these variables, it is difficult to provide specific memory usage values at any given moment. However, here are some general long-term guidelines:
| Virtual Disks in the Configuration | Approximate Memory Required (GiB) |
|---|---|
| 1 – 20 |
1 |
| 50 – 100 | 3 |
| 500+ | 5 |
SANsymphony Features
Asynchronous Replication
- Source virtual disks: 8 MiB for each virtual disk configured as an Asynchronous Replication source.
- Destination virtual disks: No additional memory is required for a virtual disk configured as an Asynchronous Replication destination.
Continuous Data Protection (CDP)
- 5 MiB per 1 GiB of History Log for each CDP-enabled virtual disk.
Disk Pools
Storage Allocation Unit (SAU) Management
The table below shows the amount of memory used for “typical” amounts of physical storage. These values can be used to calculate requirements for your own disk pools with different physical disk sizes:
| Storage Allocation Unit size (MiB) | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| Total Physical Disk (TiB) | 4 MiB | 8 MiB | 16 MiB | 32 MiB | 64 MiB | 128 MiB | 256 MiB | 512MiB | 1024 MiB |
| 0.5 |
8.75 |
4.36 | 2.19 | 1.09 | 0.55 | 0.27 | 0.14 | 0.07 | 0.03 |
| 1 | 17.5 | 8.75 | 4.36 | 2.19 | 1.09 | 0.55 | 0.27 | 0.14 | 0.07 |
| 5 | 87.5 | 43.75 | 21.88 | 10.94 | 5.47 | 2.73 | 1.37 | 0.68 | 0.34 |
| 10 | 175 | 87.5 | 43.75 | 21.88 | 10.94 | 5.47 | 2.73 | 1.37 | 0.68 |
| 100 | - | - | 43.75 | 210.9 | 109.4 | 54.7 | 27.34 | 13.67 | 6.83 |
| 1024 | - | - | - | - | - | - | 280 | 140 | 70 |
- There is an upper limit of approximately eight million SAUs per disk pool, regardless of their size.
- The smaller the SAU size, the smaller the maximum possible physical disk size a disk pool can hold before this limit is reached.
- Refer to What is the Maximum Physical Storage that a Disk Pool Can Manage? FAQ documentation for more information.
Examples:
Example 1: A disk pool has 20 TiB of physical storage and a 128 MiB SAU size. This would require twice the amount as a disk pool with 10 TiB of physical storage:
5.47 × 2 = 10.94 MiB
Example 2: A disk pool with 7.5 TiB of physical storage and a 4 MiB SAU size would require 1.5 times the amount as a disk pool with 5 TiB of physical storage:
87.5 × 1.5 = 131.25 MiB
Encryption
- Introduced in 10.0 PSP9.
- Allow for double the amount of memory listed in the table above when using Encryption.
Auto-Reclamation
-
This Disk Pool function uses 200 KiB of system memory for each storage source managed by the Disk Pool.
- For example, a mirrored virtual disk will use 200 KiB of memory on each DataCore Server managing the mirror.
Manual-Reclamation
- No additional memory is required for manual reclamation.
Inline Deduplication and Compression (ILDC)
- Introduced in 10.0 PSP12.
- Uses approximately 1.5 GiB of the memory already reserved by SANsymphony’s cache, regardless of whether the feature is in use.
- When configured, ILDC may consume up to 30% of the memory reserved for SANsymphony’s cache operations, depending on the workload.
Performance Recording
- Live and Recorded Performance:
- Memory usage depends on the number of counters being recorded in the session.
- General rule: For every 50 counters being measured, the Executive Service’s memory requirement increases by approximately 10%.
Historical Performance Recording:
- Depending on configuration complexity (example; number of mirror ports and host mappings), the Executive Service’s memory requirement may increase by approximately 10–15%.
Snapshot
This will depend on the size of the virtual disk used for the snapshot source.
| Virtual Disk size (GiB) | Memory required for each snapshot |
|---|---|
| 1-127 |
4KiB + 4KiB for each additional GiB |
| 128-511 | 128KiB + 1KiB for each additional GiB |
| 512+ | 128KiB + 0.25KiB for each additional GiB |
The calculation is made for each snapshot regardless of the number of source virtual disks.
Working Examples
Example 1: Single Virtual Disk with Multiple Snapshots
A single virtual disk, 64 GiB in size, has five snapshots.- Each snapshot uses 4 KiB of memory plus an additional (4 × 63) KiB (for the size of the virtual disk source), giving a total of 256 KiB per snapshot.
- Therefore, five snapshots from a single 64 GiB virtual disk will use 1.3 MiB of memory.
Example 2: Multiple Large Virtual Disks with Snapshots
Six virtual disks, each 2 TiB in size (2048 GiB), each have one snapshot.
- A snapshot for a 2 TiB virtual disk uses 128 KiB of memory plus an additional ((2048 – 512) × 0.25) KiB, giving a total of 512 KiB.
- Therefore, six snapshots, each from a different 2 TiB virtual disk, will use 3 MiB of memory.
Virtual Disks
Single Virtual Disks
A single virtual disk requires approximately 20 bytes of memory, regardless of size.
Dual and Mirrored Virtual Disks
Memory usage depends on the size of the virtual disk being mirrored. Each DataCore Server managing the storage sources in a mirrored virtual disk will use the following additional memory:
| Virtual Disk size (GiB) | Memory Required |
|---|---|
| Up to 32 | 2 MiB per TiB of virtual disk size |
| 33 – 64 | 1 MiB per TiB of virtual disk size |
| 65 – 128 | 0.5 MiB per TiB of virtual disk size |
| 129 – 256 | 0.25 MiB per TiB of virtual disk size |
| 257 – 1024 | 0.125 MiB per TiB of virtual disk size |
Dynamic Data Resilient (DDR) Virtual Disks
Memory usage depends on the size of the virtual disk being mirrored.
- The DataCore Server acting as the ‘Parent’ for the DDR virtual disk requires slightly more memory than a dual or mirrored virtual disk, as it maintains two in-memory bitmaps for the ‘Child’ and ‘Backup’ storage sources.
- The DataCore Servers acting as either the ‘Child’ or ‘Backup’ for the DDR virtual disk continue to use the same values as mirrored virtual disks (see the previous table).
| Virtual Disk size (TiB) | Memory Required |
|---|---|
| Up to 32 | 3 MiB per TiB of virtual disk size |
| 33 – 64 | 1.5 MiB per TiB of virtual disk size |
| 65 – 128 | 0.75 MiB per TiB of virtual disk size |
| 129 – 256 | 0.375 MiB per TiB of virtual disk size |
| 257 – 1024 | 0.1875 MiB per TiB of virtual disk size |
Third-Party Applications and Services
If, during start-up, third-party applications are already using a significant amount of physical memory, SANsymphony may not be able to reserve as much as it expects. In this case, a warning message will be posted in the SANsymphony Console and the Windows System Event Log.
SANsymphony will still start but will use less than the expected amount of memory for its cache.
If SANsymphony has already started and reserved memory for its own caching, no other applications running on the DataCore Server—including the Windows operating system—can use that reserved memory. If Windows does not have enough memory to perform its own tasks, the DataCore Server may behave erratically.
Possible Symptoms
- Windows System Event Logs may report “insufficient memory” warnings or errors.
- The DataCore Servers acting as either the ‘Child’ or ‘Backup’ for the DDR virtual disk continue to use the same values as mirrored virtual disks (see the previous table).
- Historical and Performance Recording timeouts may be reported in the SANsymphony Console.
- Creation of new Asynchronous Replications may fail. The destination replication server may report as “Offline”, and existing replications that were “In Log” may now report as being in “Standby”.
- Support Bundles may fail or take a significantly long time to complete.
- Snapshot creation may fail, and existing snapshots may unexpectedly report as “Failed” without any apparent hardware issue.
- Fibre Channel and iSCSI Ports may suddenly report as being unavailable.
Previous Changes
| Section(s) | Content Changes | Date | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Added new sections | June 2019 | ||||||||||||||||||||||||
SANsymphony’s cache
| Updated Updated with enhancements added with PSP11. | June 2019 | ||||||||||||||||||||||||
| SANsymphony inside a Virtual Machine | Removed – This information was moved to ‘Hyper-converged Virtual SAN - Deployment Best Practices’. | June 2019 | ||||||||||||||||||||||||
| The DataCore Server's Cache – When there is not enough memory to allocate | Added information about changes introduced in SANsymphony 10.0 PSP 5 Update 2 (and greater). | February 2017 | ||||||||||||||||||||||||
| The DataCore Server's Cache – General | This section has been re-ordered with many of the explanations simplified. | February 2017 | ||||||||||||||||||||||||
| DataCore Server Cache – How memory is assigned to DataCore Cache | Updated – Added information for Windows Hyper-V and VMware ESXi regarding memory settings for running SANsymphony in a Virtual Machine. | February 2016 | ||||||||||||||||||||||||
| The DataCore Server Cache | Updated – Corrected inaccurate values for default percentages of Physical RAM allocated to the DataCore Cache driver in SANsymphony-V 10.0.0 or higher.
| June 2015 | ||||||||||||||||||||||||
| Overview | Added – Important changes since SANsymphony-V 10.0 PSP2; explained new enhanced memory management behavior. | April 2015 | ||||||||||||||||||||||||
| Sequential Storage | Added – New feature introduced in SANsymphony-V 10.0 PSP1. | November 2014 | ||||||||||||||||||||||||
| Mirrored Virtual Disks | Updated – Rewrote the description of ‘The Bitmap’ and updated the table with detailed information. | August 2014 | ||||||||||||||||||||||||
| How much memory do I really need? | Updated – Moved section to the end of the document and added a guide table for determining Physical RAM requirements. | July 2014 | ||||||||||||||||||||||||
| The DataCore Server Cache | Updated – Added values for SANsymphony-V 10.x. | June 2014 | ||||||||||||||||||||||||
| Added – New section | February 2014 | ||||||||||||||||||||||||
| The DataCore Server Cache | Updated – Added instructions on finding how much physical memory is used by the DataCore Cache. | February 2014 | ||||||||||||||||||||||||
| - | This document replaces DataCore’s Technical Bulletin 7b “System Memory Considerations for DataCore Servers” and contains fully updated and rewritten information for SANsymphony-V 9.0 PSP 4 and greater. | January 2014 | ||||||||||||||||||||||||