Avamar Client för Windows: Avamar-säkerhetskopiering slutförs inte med felet "avtar-fel <18866>: Slut på minne för cachefil" på Windows-klienter
Summary: Syftet med den här KB-artikeln är att ta itu med en specifik situation där klienten, för den typen av cacheproblem, inte kan tillåta mer minne för att cachefilen ska kunna växa och vilken KB-artikel 495969 inte gäller. ...
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
I det här scenariot har vi samma problem som i KB-495969 men lösningen gäller inte på grund av ett miljöproblem på en Windows-klient.
- KB-artikel 495969: Avamar-säkerhetskopiering misslyckas med "Inte tillräckligt med utrymme" och "slut på minne för cachefil"
- För FS-säkerhetskopieringar:
avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat' avtar Error <18866>: Out of memory for cache file 'C:\Program Files\avs\var\p_cache.dat' size 805306912 avtar FATAL <5351>: MAIN: Unhandled internal exception Unix exception Not enough space
- För VSS-säkerhetskopieringar:
avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat' avtar Error <18866>: Out of memory for cache file 'C:\Program Files\avs\var\p_cache.dat' size 1610613280 avtar FATAL <5351>: MAIN: Unhandled internal exception Unix exception Not enough space
- För Oracle-säkerhetskopiering:
avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\clientlogs\oracle-prefix-1_cache.dat'
avtar Error <18866>: Out of memory for cache file 'C:\Program Files\avs\var\clientlogs\oracle-prefix-1_cache.dat' size 100663840
avtar FATAL <5351>: MAIN: Unhandled internal exception Unix exception Not enough space
or this variant:
avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\clientlogs\oracle-prefix-1_cache.dat'
avtar Error <18864>: Out of restricted memory for cache file 'C:\Program Files\avs\var\clientlogs\oracle-prefix-1_cache.dat' size 100663840
avtar FATAL <5351>: MAIN: Unhandled internal exception Unix exception Not enough space
avoracle Error <7934>: Snapup of <oracle-db> aborted due to rman terminated abnormally - check the logs
- Med RMAN-loggen som rapporterar detta:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup plus archivelog command at 06/14/2018 22:17:40 RMAN-03009: failure of backup command on c0 channel at 06/14/2018 22:17:15 ORA-04030: out of process memory when trying to allocate 1049112 bytes (KSFQ heap,KSFQ Buffers) Recovery Manager complete.
Till en början trodde man att cachefilen inte kunde växa i storlek på grund av felaktigt "hashcachemax"-värde.
Klienten hade gott om ledigt RAM-minne (48 GB totalt RAM-minne) så vi ökade flaggans värde från -16 (max 3 GB filstorlek) till -8 (max 6 GB filstorlek).
Men problemet kvarstod och diskutrymmet var inte heller ett problem, det fanns gott om GB ledigt utrymme.
Cause
Ytterligare undersökningar med en binär testfil från ingenjörsteamet ledde till det faktum att MS OS inte släppte tillräckligt med oanvänt och sammanhängande minne som krävdes för att allokera/ladda in i minnet hela hashcachefilen för säkerhetskopieringen.
Det provades med en testbinär som skulle allokera minnet i mindre bitar för att se om vi kunde nå den punkt där operativsystemet skulle tillåta att hela filen p_cache.dat lästes in i minnet, men det hjälpte inte heller. Operativsystemet tillät fortfarande inte att filen lästes in i minnet av någon anledning.
Grundorsaken är gömd någonstans i operativsystemet, men i det här fallet kontaktade vi inte MS-teamet för ytterligare undersökningar från deras sida.
Istället hittade vi ett sätt att kringgå problemet genom att ställa in cachefilen så att den är mindre. Mer information finns i lösningsavsnittet nedan.
Det provades med en testbinär som skulle allokera minnet i mindre bitar för att se om vi kunde nå den punkt där operativsystemet skulle tillåta att hela filen p_cache.dat lästes in i minnet, men det hjälpte inte heller. Operativsystemet tillät fortfarande inte att filen lästes in i minnet av någon anledning.
Grundorsaken är gömd någonstans i operativsystemet, men i det här fallet kontaktade vi inte MS-teamet för ytterligare undersökningar från deras sida.
Istället hittade vi ett sätt att kringgå problemet genom att ställa in cachefilen så att den är mindre. Mer information finns i lösningsavsnittet nedan.
Resolution
För att komma runt det här problemet ställer vi in hashcachefilen så att den är av en mindre storlek så att operativsystemet inte skulle ha problem med att allokera den till minnet.
I det här fallet märktes det att operativsystemet också hade problem med att allokera mindre storlekar som 200+ MB så vi bestämde oss för att ändra storleken på p_cache.dat till bara 100 MB med hjälp av följande flagga:
--hashcachemax=100
På så sätt skulle hashcachefilen aldrig växa över 100 MB och skulle skriva över de gamla posterna.
När du har lagt till den flaggan måste du återvinna cachefilen genom att byta namn på eller ta bort p_cache.dat (att byta namn är det föredragna alternativet).
Efter den första säkerhetskopieringen, som skulle ta längre tid än vanligt som förväntat (att återskapa cachefilen), bör problemet vara löst.
I det här fallet märktes det att operativsystemet också hade problem med att allokera mindre storlekar som 200+ MB så vi bestämde oss för att ändra storleken på p_cache.dat till bara 100 MB med hjälp av följande flagga:
--hashcachemax=100
På så sätt skulle hashcachefilen aldrig växa över 100 MB och skulle skriva över de gamla posterna.
När du har lagt till den flaggan måste du återvinna cachefilen genom att byta namn på eller ta bort p_cache.dat (att byta namn är det föredragna alternativet).
Efter den första säkerhetskopieringen, som skulle ta längre tid än vanligt som förväntat (att återskapa cachefilen), bör problemet vara löst.
Additional Information
- Cacheminnet för växling på begäran rekommenderas inte i det här scenariot eftersom säkerhetskopian dirigeras till GSAN-lagring, så den monolitiska växlingscachen användes.
- Sidindelning på begäran har utformats för att dra nytta av säkerhetskopiering som skickas till DataDomain-lagring.
Affected Products
AvamarProducts
Avamar, Avamar Client for Windows, Avamar Plug-in for OracleArticle Properties
Article Number: 000060137
Article Type: Solution
Last Modified: 17 Jun 2025
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.