This article is a general comment, based on our observations/troubleshooting at few Customer site(s), on why on some SYSTEMS, the RMM SYNC Engine shows zero percent (0%) and stays that way for a period of time.
Background:
Customers often wonder why the RMM syn is "stuck" at "zero %" for a very long time without making progress.
Symptom:
<>
Before you Begin:
<>
Use case:
Migration SYNC's, or Disaster Recovery SYNC's using RMM's Standard Sync Engine
Applicable To:
Any current RMM version and any ORIGIN OS.
Preparation/Pre-Req:
ORIGIN, RMM and Target environment must comply with latest RMM Pre-reqs published.
Steps/Comments:
Based on our observations/troubleshooting at other Customer site(s), here is a general comment on why on some SYSTEMS the RMM STANDARD SYNC Engine shows 0% and stays that way for a period of time.
RMM operates in an "Agent-less" mode, which means that it doesn't require additional software installations on ORIGIN systems for tracking the I/O's & data changes.
In this mode, the first step of the RMM SYNC process involves a comprehensive scan of the entire file system to identify all files and gather essential information, such as modification timestamps and file sizes, etc.
Although RMM SYNC's always run in very low priority mode (& hence less intrusive), this scanning process is reliant on available system resources as well as the disk Input/Output Operations Per Second (IOPS) capability, especially when dealing with a significant number of files.
If you observe a synchronization operation staying at 0% progress for an extended duration, it typically indicates that the scanning phase is "affected", resulting in a longer-than-normal completion time. This is often due to a combination of two factors: a large number of files and insufficient disk IOPS performance on the source system.
We generally come across these on "older" systems such as Windows 2008, or systems with "older" disks .
In most cases, this issue arises due to insufficient disk IOPS, often caused by antivirus, or anti-malware software not being configured to exclude our processes. However, it can also be attributed to sluggish disk Input/Output on the source, such as when dealing with a virtual machine subject to I/O throttling in a cloud environment or an older physical machine equipped with slow disk hardware.
While the other factors listed below have the potential to impact synchronization throughput and may affect later stages of the process, it's essential to recognize that the primary culprits for the prolonged 0% status during the initial synchronization phase are the two factors mentioned earlier:
a) Dependency on available "hardware resources" (CPU/Memory, etc.) on the source system.
b) The quantity, size, and type of data being processed.
c) The extent and nature of ongoing Input/Output operations.
d) Firewall settings
and various other considerations.
The best recommendation in all such cases is to leave the RMM Sync running longer and see if it can make progress on the migration, and in parallel we can help investigate the source of the slowness.
We trust that this provides a clearer understanding of the situation.
Post Changes: <>
Important Note(s): <>
Related Reference(s):
https://rackware.freshdesk.com/a/solutions/articles/5000879431