Severe memory fragmentation results in a large memory allocation request to fail resulting in an out-of-memory panic. When using2-way NDMP, a call to theFCP driver (which sends IO to the safe container) utilizes an IO memory allocation scheme where the memory can become severely fragmented. This eventually (about 4-6 months) results in a large memory allocation request being denied due to the request being larger than the largest free memory and the SP panic is induced.
Resolution
Work Around (1) Implement 3-way NDMP.
OR
(2) Scheduling proactive SP reboots every 4-6 months will clear the memory.
Fix
This issue is fixed in Unity OE 5.2.1.0.5.013.
Additional Information
1)What is the difference between 2-way NDMP, and 3-ways NDMP? With 2-way NDMP, backup traffic is transferred directly from the Unity primary storage system to the Backup Target System using a zoned Fibre Channel (FC) connection.
With 3-way NDMP, both data and metadata are transferred from the source Unity system over a local area network (LAN) or wide area network (WAN). Data is also transferred through the DMA.
2-way NDMP (There is FC connection to Unity, it will call FCP driver to allocate memory)
3-way NDMP (No FC connection to Unity)
2)Which versions would be impacted by this issue? This is a day one issue, it could affect all the Unity array as long as 2-way NDMP is utilized and runs for a long time.