RecoverPoint: Der Replikationsprozess stürzt ab, wenn der Arbeitsspeicher des Phase1-Caches nicht mehr ausreicht

Der Status der Consistency Group befindet sich weiterhin in der Initialisierung, aber die Normalverteilung scheint nie zu starten und die CG wechselt nicht in einen aktiven Status. Ein Replikationsprozess stürzt mit einer Assertion ab, wenn der Phase1-Cachespeicher nicht ausreicht und die RecoverPoint-Appliances auf der Zielseite nicht in das Zieljournal schreiben können. Symptome in den Protokollen /home/kos/replication: Behauptung: XXXX/XX/XX 18:59:25.693 - #2 - 17936/16776 - AssertLogSender: Senden des Protokolls: topic=DistributorGroupHandler, msg=Assertion fehlgeschlagen: bIsPhase1CacheMemorySufficient Zeile 1825 Datei DistributorGroupHandlerPhase1.cc PID: 16776 Info: Regulärer Phase1-Cache-Speicher nicht ausreichend m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXXXX) 0) ),gridCopyID=0) XXXX/XX/XX 18:59:25.694 - #2 - 16911/16776 - RemoteLogSender: got event (uniqueId=0, eventTime=1584471565693987), EventID_KBOX_ASSERTION_FAILED(3031), SiteUID(0xxxxxxxxxxxxxxxxxxxx), seDetails=Sender=replication, Topic=DistributorGroupHandler, msg=Assertion fehlgeschlagen: bIsPhase1CacheMemorySufficient Zeile 1825 Datei DistributorGroupHandlerPhase1.cc PID: 16776 Info: Regulärer Phase1-Cache-Speicher nicht ausreichend m_GroupGridCopyRID = (groupCopyRID=(kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXX) 0) ),gridCopyID=0) Statistiken, die einen hohen Datenfluss anzeigen: XXXX/XX/XX 18:52:41.520 - #2 - 7676/7665 - AccumulatorFormatManager::p rintStatistics: Gruppenstatistiken für Gruppe Option ( kVolSlot = XXXXXXXXXX groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXX) 0) gridID = 0): { STATISTIKEN: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 Beschreibung: init nc einphasige Geschwindigkeit . STATISTIKEN: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 8-Sekunden-Fenster: Durchschnitt: 1,14e + 03 MB/s STATISTIKEN: name=InitNCOnePhaseSpeed kVolSlot = 1346840554 groupUID = GroupCopy(1346840554 SiteUID(0xXXXXXXXXXXXXX) 0) gridID = 0 77 sec window: Durchschnitt: 1,06e + 03 MB/s Eine Consistency Group befindet sich im Initialisierungsstatus: 17.03.2020 18:56:05.070 - #2 - 7954/7665 - InitNCState::D istributeOnePhase: Verteilen einer Phase m_groupID = (groupCopyRID=( kVolSlot=XXXXXXXXXX,globalCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) 0) ),gridCopyID=0) Der Phase1-Consumer für diese Consistency Group zeigt einen hohen Verbrauch für die Assertion: XXXX/XX/XX 18:56:05.241 - #2 - 7954/7665 - MemoryManager: viscus on assert + Countdowns = 2413/390 + min. Speicherbedarf = 433429 (fest 329537 flexibel 103892) + flexibel nutzbarer Raum = 37977/3864963 + Poolspeicherplatznutzung = 37985/4194500 (max. 143544) >> 1160635626647715840 :p hase1#22 >> (groupTaskID=(sessionID=1817723153,replicationLinkID=(kVolSlot=XXXXXXXXX,srcCopyID=GlobalCopy(SiteUID(0xXXXXXXXXXXXX) >> 0) ,destCopyID=GlobalCopy(SiteUID Ein Replikations-StackTrace tritt ebenfalls auf: 17.03.2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 3: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZNK6Kashya23DistributorGroupHandler21waitForMemoryIfNeededEv+0x5b2) [0xxxxxxxxxxxxx] 17.03.2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 4: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler25addSequencesToPhase1CacheENS_9SequencesERNS_15ReplicationModeE+0x939) 17.03.2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 5: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler23handleSplittedSequencesENS_9SequencesERKNS_15ReplicationModeERKb+0x20a) 17.03.2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 6: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya23DistributorGroupHandler15handleSequencesENS_9SequencesERKNS_15ReplicationModeERKb+0x577) 17.03.2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 7: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya19Distributor_AO_IMPL23continueHandleSequencesENS_9SequencesENS_15ReplicationModeEbRKNS_10GridCopyIDE+0xf7) 17.03.2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 8: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya16SequencesRequest21continueHandleRequestERNS_28JournalRegulationRequestBase14RequestHandlerE+0x30b) 17.03.2020 18:56:05.278 - #0 - 7954/7665 - StackTrace: errno=0 9: /home/kos/kashya/archive/lib/libreplication_libsrelease.so(_ZN6Kashya31JournalRegulationThread_AO_IMPL9process_iERKNS_16GroupGridCopyRIDE+0x36f)

Problemumgehung: Ändern Sie den Wert der Tweak-t_phase1CacheMemoryThreadSleepTime auf 5000. (Erhöhung der Wartezeit von 10 Mikrosekunden auf 5 Millisekunden). Dadurch wird sichergestellt, dass erst dann eine Bestätigung erfolgt, wenn der Thread 5 Millisekunden lang auf den Arbeitsspeicher wartet. Wenn das Problem weiterhin auftritt: 1. Erfassen Sie auch die Protokolle des Produktionsstandorts. Da es uns die Datenmenge mitteilt, die zum Zeitpunkt des Problems von der Produktion gesendet wird. 2. Ändern Sie den Wert der Positionsveränderung t_maxNoOfTriesToWaitForPhase1CacheMemory auf 10. Hinweis: Diese Optimierungen sind nur für Version 5.1.3 und höher relevant. Wenn die Codeversion nicht 5.1.3 oder höher ist, MUSS RecoverPoint auf den neuesten Code aktualisiert werden, um diese Optimierungen nutzen zu können. Lösung: Die Technikabteilung von Dell EMC untersucht derzeit dieses Problem. Es wird noch an einer dauerhaften Lösung gearbeitet. Wenden Sie sich an das Dell EMC Kundensupportcenter oder Ihren Servicemitarbeiter, um Unterstützung zu erhalten und geben Sie die Lösungs-ID an.