The DataCore Server

System Memory Considerations

April 2021

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.

The authority on real-time data

 Table of contents

Changes to this document 3

SANsymphony’s cache 4
How much physical memory do I need? 4
When does SANsymphony reserve memory for its cache? 4
How to monitor SANsymphony’s cache's allocation 5

DataCore drivers and services 7

DataCore system drivers 7
The DataCore Executive service 8
SANsymphony features 9
Asynchronous Replication 9
Continuous Data Protection (CDP) 9
Disk Pools 9
Storage Allocation Unit management 9
Encryption 10
Auto-reclamation 10
Manual-reclamation 10
Inline Deduplication and Compression (ILDC) 10
Performance Recording 10
Live and Recorded Performance 10
Historical Performance Recording 10
Snapshot 11
Virtual Disks 12
Single Virtual Disks 12
Dual and Mirrored Virtual Disks 12
Dynamic Data Resilient (DDR) Virtual Disks 12

Third-party applications and services 13

Previous Changes 14
Changes to this document
The most recent version of this document is available from here:
https://datacore.custhelp.com/app/answers/detail/a_id/838

Changes since June 2019

Added
Disk Pools
Encryption
Manual reclamation

Inline Deduplication and Compression (ILDC)

Updated
Disk Pools
Autoreclamation (minor clarification – storage source vs virtual disk)

Removed
SANsymphony cache – default settings
The table that was in this section has been removed as it is now referenced in
SANsymphony’s online help.

For previous changes made to this document please see page 14

Page | 3 The DataCore Server – System Memory Considerations

SANsymphony’s cache
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.

Amount of physical disks in the DataCore Server (TB)

1-4 5-15 16-99 100-159 160-254 255-359 360-511 512+

Virtual
5 10 50 80 128 180 250 300+
Disks
Phys.
Memory 8 16 48 96 128 256 512 1024
(GB)

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.

See Changing Cache Size:

https://docs.datacore.com/SSV-WebHelp/changing_cache_size.htm

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.

Page | 4 The DataCore Server – System Memory Considerations

 SANsymphony’s cache – How to monitor cache allocation

How to monitor SANsymphony’s cache's 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:

Page | 5 The DataCore Server – System Memory Considerations

 SANsymphony’s cache – How to monitor cache allocation

Using the SANsymphony Console ‘Live Performance’ feature

Select the ‘Home’ tab on the top of the Management Console and select 'Live Performance'.

In the next window select DataCore Servers from the 'Category' column and then the
DataCore Server(s) from the 'Instances' column next to it. Now select 'Cache Size' from the
‘Counters’ column and click the 'Add' button.

Click the 'Done' button to display the allocated cache value.

Notes
The value displayed in the ‘Max’ column is the amount reserved by SANsymphony for its
cache.

The ‘Last’, ‘Average’ and ‘Min’ values should be ignored as they are misleading. During the
start-up/stopping of the SANsymphony software, the allocated system memory is either
gradually loaded or unloaded respectively, so depending on how fast the DataCore Server
can load/unload the system memory will skew the ‘Last’, ‘Average’ and ‘Min’ values.

Page | 6 The DataCore Server – System Memory Considerations

DataCore drivers and services
DataCore system drivers
From SANsymphony version 10.0 PSP 2 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 is to avoid accidentally consuming the remaining system memory, used by the Windows
operating system and any other third-party applications and services, which can
inadvertently make the DataCore Server unstable. However, if even more system memory is
still required by the DataCore system drivers then they will also use any ‘remaining’ system
memory as well.

The DataCore Console and all other DataCore services (Executive, SNMP Agent, Intelligence,
Performance Monitor and Updater etc.) will not use memory that has already been assigned
to SANsymphony.

This behavior is not configurable.

Windows Task Manager and the DcsAddMem.exe process

Whenever SANsymphony is started, the DcsAddMem.exe processes runs and it will begin to
allocate system memory from the Windows operating system exclusively for SANsymphony’s
cache – see the section ‘SANsymphony’s cache’ on page 4.

However, after the system memory has

been allocated to SANsymphony’s cache,
the DcsAddMem.exe will remain displayed
in Windows Task Manger when actually the
process is no longer running. Also, over
time, the size of the memory assigned to
the DcsAddMem.exe process in Task
Manager may start to shrink and, in some
cases, the process may disappear from Task
Manager completely, even though the
SANsymphony software is still running.

This does not mean that SANsymphony has less/no memory for its cache, but is simply an
idiosyncrasy of how Task Manager handles the DcsAddMem.exe process once the
SANsymphony software has started. Therefore, using the DcsAddMem.exe process to
determine the amount of memory used by SANsymphony is not reliable.

To track how much memory is really being used by SANsymphony, please see ‘How to
monitor SANsymphony’s cache's allocation’ on page 5.

Page | 7 The DataCore Server – System Memory Considerations

 DataCore drivers and services

The DataCore Executive service

The DataCore Executive Service provides a communication interface between all the ‘user-
level’ applications and the DataCore system drivers. These applications include the
SANsymphony Console, DataCore PowerShell Cmdlets, SANsymphony’s vCenter Integration
and both of the DataCore Microsoft and vSphere plugins.

The service is also responsible for the following:

• Monitoring and displaying Performance statistics (e.g. Live Performance, Performance

Recording and Storage Allocation statistics for Disk Pools and vDisks). Also see
‘Performance Recording’ on page 10.

• Status reporting from specific DataCore system drivers for different objects in the
SANsymphony Console (e.g. Mirror recovery progress, Disk Pool and Port statuses).

• Updating and distributing all configuration changes between DataCore Servers in the
same Server Group and/or remote Replication Groups.

• The transmitting of Asynchronous Replication Data to remote Replication Groups.

Also see ‘Asynchronous Replication’ on page 9.

The memory requirement for this service increases the more tasks it has to perform and as
the number of objects (Physical Disks, Disk Pools, virtual disks, Ports and Hosts etc.) in the
configuration increases. Conversely as tasks are completed (e.g. a Performance Recording
session is ended) or the configuration reduces in size (e.g. vDisks are removed

This, therefore, makes it very difficult to give specific values to the amount of memory that
the DataCore Executive Service will require at a given moment. There are some general
‘rules-of thumb’ that can be applied over the long-term though;

# Virtual Disks in the configuration Approximate Memory Required (GB)

1 - 20 1

50 - 100 3

500+ 5

Page | 8 The DataCore Server – System Memory Considerations

SANsymphony features
Asynchronous Replication
8MB for each virtual disk configured as an Asynchronous Replication source. No additional
memory is required for a virtual disk configured as Asynchronous Replication destination.

Continuous Data Protection (CDP)

5MB per 1GB of History Log for each CDP-enabled virtual disk.

Disk Pools
Storage Allocation Unit management
The table below shows the amount of memory used for ‘typical’ amounts of physical storage
and these can be used to work out the requirements for your own disk pools with different
physical disk sizes.

Storage Allocation Unit size (MB)

Total
Physical 4 8 16 32 64 128 256 512 1024
Disk (TB)

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 - - 437.5 210.9 109.4 54.7 27.34 13.67 6.83
1024 - - - - - - 280 140 70

Notes
There is an upper limit, for each disk pool, of approximately eight million SAUs 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. Also see ‘What is the maximum Physical
Storage that a Disk Pool can manage?’
https://datacore.custhelp.com/app/answers/detail/a_id/968

Example 1
A disk pool has 20TB of physical storage and a 128mb SAU size. This would require twice the
amount as a disk pool with 10TB of physical storage in it
i.e. 5.47 x 2 = 10.94MB

Example 2
A disk pool with 7.5TB of physical storage and a 4mb SAU size. This would require 1.5 times
the amount as a disk pool with 5TB of physical storage in it
i.e. 87.5 x 1.5 = 131.25MB

Page | 9 The DataCore Server – System Memory Considerations

 SANsymphony features

Encryption
This was a new feature added in 10.0 PSP 9. Allow for double the amount of memory listed in
the table above when using Encryption.

Auto-reclamation
This Disk Pool function will use 200KB of system memory for each storage source managed
the Disk Pool. I.e., a mirrored Virtual Disk will use 200KB of memory on each DataCore Server
managing the mirror.

Manual-reclamation
No additional memory is required for manual reclamation.

Inline Deduplication and Compression (ILDC)

This was a new feature added in 10.0 PSP 12, it will use approximately 1.5GB of the memory
already reserved by SANsymphony’s own cache, regardless of if the feature is being used or
not. When configured, ILDC may consume up to a maximum of 30% of the memory reserved
for SANsymphony’s own cache operations depending on the workload that the ILDC
function has to perform.

Performance Recording
Live and Recorded Performance
This will depend on the number of counters being recorded in the session. While a specific
value of system memory required cannot be given, the overall increase is usually not
significant, and the following general rule can be applied;

For every 50 counters being measured, the additional memory requirement of the Executive
service will increase by approximately 10%.

Historical Performance Recording

Depending on the complexity of the configuration (e.g. the number of mirror port and Host
mappings) the additional memory requirement of the Executive service will increase by
approximately 10 – 15%.

Page | 10 The DataCore Server – System Memory Considerations

 SANsymphony features

Snapshot
This will depend on the size of the virtual disk used for the snapshot source.

Virtual Disk size (GB) Memory required for each snapshot

1-127 4KB + 4KB for each additional GB

128-511 128KB + 1KB for each additional GB

512+ 128KB + 0.25KB for each additional GB

Notes:
The calculation is made for each snapshot regardless of the number of source virtual disks.

Working example 1
A single virtual disk 64GB in size has five snapshots.

Each snapshot will use 4KB of memory plus an additional

‘(4 x 63) KB’ (for the size of the virtual disk source) giving a
total of 256KB per snapshot.

Therefore, five snapshots from a single 64GB virtual disk

will use 1.3 MB of memory.

Working example 2
Six virtual disks, each 2TB in size (or 2048GB) each have one snapshot.

A snapshot for a 2TB virtual disk will use 128KB of memory

plus an additional ‘((2048 – 512) x 0.25) KB’ giving a total of
512KB.

Therefore, six snapshots, each from a different 2TB virtual

disk, will use a 3MB of memory.

Page | 11 The DataCore Server – System Memory Considerations

 SANsymphony features

Virtual Disks

Single Virtual Disks

A single virtual disk requires ~20 bytes of memory regardless of size.

Dual and Mirrored Virtual Disks

This will depend 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 (TB) Memory required

Up to 32 2MB / per TB of virtual disk size

33 - 64 1MB / per TB of virtual disk size

65 - 128 0.5MB / per TB of virtual disk size

129 - 256 0.25MB / per TB of virtual disk size

257 - 1024 0.125MB / per TB of virtual disk size

Dynamic Data Resilient (DDR) Virtual Disks

This will depend on the size of the virtual disk being mirrored. The DataCore Server acting as
the ‘Parent’ for the DDR virtual disk will require slightly more memory than a dual or
mirrored virtual disk as it has to maintain 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 will
continue to use the same values for mirrored virtual disks (in the previous table).

Virtual Disk size (TB) Memory required

Up to 32 3MB / per TB of virtual disk size

33 - 64 1.5MB / per TB of virtual disk size

65 - 128 0.75MB / per TB of virtual disk size

129 - 256 0.375MB / per TB of virtual disk size

257 - 1024 0.1875MB / per TB of virtual disk size

Page | 12 The DataCore Server – System Memory Considerations

Third-party applications and services
If during start-up other, third party applications are already using significant amount 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 be using 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 will be able to use that reserved memory,
including the Windows operating system. If the Windows operating system does not have
enough memory to perform its own tasks then the DataCore Server may behave erratically.

Symptoms may include:

• Windows own System Event logs may report ‘insufficient memory’ warnings or errors.

• SANsymphony Disk Pool operations involving the allocation or reclamation of Storage

Allocation Units (SAUs) may take significantly longer than expected or even stop
working altogether.

• Historical and Performance Recording timeouts may be reported in the

SANsymphony Console.

• The creation of new Asynchronous Replications may fail. The Destination Replication
Server may report as being ‘Off-line’. 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.

• The creation of snapshots may fail and existing Snapshots may unexpectedly report
as being ‘Failed’ without any obvious physical hardware problem.

• Fibre Channel and iSCSI Ports may suddenly report `being unavailable.

Page | 13 The DataCore Server – System Memory Considerations

Previous Changes
June 2019
Added
Disk Pools – Auto reclamation

Virtual Disks – Mirrored and Single

Dynamic Data Resiliency (DDR)

Updated
SANsymphony’s cache
How to monitor SANsymphony’s cache's allocation

SANsymphony features
• Performance Recording
• Snapshot
• Virtual Disks - Mirrored and Single

Removed
SANsymphony inside a Virtual Machine
This information has been moved to the document
‘Hyper-converged Virtual SAN - Deployment Best Practices’

February 2017
Added
The DataCore Server's Cache - When there is not enough memory to allocate
Added information about the difference in SANsymphony 10.0 PSP 5 Update 2 (and greater)

Updated
The DataCore Server's Cache - generally
This section has been re-ordered with many of the explanations simplified.

February 2016
Updated
The DataCore Server Cache - How memory is assigned to DataCore Cache
Added new information for Windows Hyper-V and VMware ESXi with regard to memory settings for running
SANsymphony in a Virtual Machine.

June 2015
Updated
The DataCore Server Cache
The previous values for the default percentages of Physical RAM allocated to the DataCore Cache driver in
SANsymphony-V 10.0.0 or higher were inaccurate.

Previous (incorrect) Values Corrected Values

Available Phys. RAM % Allocated for Cache Available Phys. RAM % Allocated for Cache
4GB 50 8GB 53
5 – 48GB 65 16GB 59
49 – 96GB 75 32GB 62
97GB+ 80 64GB+ 65

Page | 14 The DataCore Server – System Memory Considerations

 Previous Changes

April 2015
Added
Overview
Important changes since SANsymphony-V 10.0 PSP2
Explained the new enhanced memory management behavior added in version 10.0 PSP 2

2014 and earlier

November
Added
Sequential Storage
Added information for the new feature introduced in SANsymphony-V 10.0 PSP1

August
Updated
Mirrored Virtual Disks
Rewrote the description of ‘The Bitmap’; and updated the table with more detailed information.

July
Updated
How much memory do I really need?
This section has been moved to the end of the document and now includes a table to be used as a ‘guide’ to
determine the amount of Physical RAM that should be considered for a DataCore Server based on the amount of
capacity that is being managed.

June
Updated
The DataCore Server Cache
Added values for SANsymphony-V 10.x

February
Added
What if System Memory gets too low?
Performance Recording and Support Bundles

Updated
The DataCore Server Cache
How to find how much physical memory is in use by DataCore Cache

January
This document replaces DataCore’s Technical Bulletin 7b “System Memory Considerations for DataCore Servers” and
contains completely updated, and rewritten, information for SANsymphony-V 9.0 PSP 4 and greater.

Page | 15 The DataCore Server – System Memory Considerations

 The authority on real-time data

Copyright © 2021 by DataCore Software Corporation. All rights reserved.

DataCore, the DataCore logo and SANsymphony are trademarks of DataCore Software Corporation. Other DataCore
product or service names or logos referenced herein are trademarks of DataCore Software Corporation. All other
products, services and company names mentioned herein may be trademarks of their respective owners.

ALTHOUGH THE MATERIAL PRESENTED IN THIS DOCUMENT IS BELIEVED TO BE ACCURATE, IT IS PROVIDED “AS IS”
AND USERS MUST TAKE ALL RESPONSIBILITY FOR THE USE OR APPLICATION OF THE PRODUCTS DESCRIBED AND
THE INFORMATION CONTAINED IN THIS DOCUMENT. NEITHER DATACORE NOR ITS SUPPLIERS MAKE ANY
EXPRESS OR IMPLIED REPRESENTATION, WARRANTY OR ENDORSEMENT REGARDING, AND SHALL HAVE NO
LIABILITY FOR, THE USE OR APPLICATION OF ANY DATACORE OR THIRD PARTY PRODUCTS OR THE OTHER
INFORMATION REFERRED TO IN THIS DOCUMENT. ALL SUCH WARRANTIES (INCLUDING ANY IMPLIED
WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE AND AGAINST
HIDDEN DEFECTS) AND LIABILITY ARE HEREBY DISCLAIMED TO THE FULLEST EXTENT PERMITTED BY LAW.

No part of this document may be copied, reproduced, translated or reduced to any electronic medium or machine-
readable form without the prior written consent of DataCore Software Corporation