Node.js heeft onvoldoende geheugen

Vandaag heb ik mijn script voor bestandssysteemindexering uitgevoerd om de RAID-bestandsindex te vernieuwen en na 4 uur crashte het met de volgende fout:

[md5:]  241613/241627 97.5%  
[md5:]  241614/241627 97.5%  
[md5:]  241625/241627 98.1%
Creating missing list... (79570 files missing)
Creating new files list... (241627 new files)
<--- Last few GCs --->
11629672 ms: Mark-sweep 1174.6 (1426.5) -> 1172.4 (1418.3) MB, 659.9 / 0 ms [allocation failure] [GC in old space requested].
11630371 ms: Mark-sweep 1172.4 (1418.3) -> 1172.4 (1411.3) MB, 698.9 / 0 ms [allocation failure] [GC in old space requested].
11631105 ms: Mark-sweep 1172.4 (1411.3) -> 1172.4 (1389.3) MB, 733.5 / 0 ms [last resort gc].
11631778 ms: Mark-sweep 1172.4 (1389.3) -> 1172.4 (1368.3) MB, 673.6 / 0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x3d1d329c9e59 <JS Object>
1: SparseJoinWithSeparatorJS(aka SparseJoinWithSeparatorJS) [native array.js:~84] [pc=0x3629ef689ad0] (this=0x3d1d32904189 <undefined>,w=0x2b690ce91071 <JS Array[241627]>,L=241627,M=0x3d1d329b4a11 <JS Function ConvertToString (SharedFunctionInfo 0x3d1d3294ef79)>,N=0x7c953bf4d49 <String[4]\: ,\n  >)
2: Join(aka Join) [native array.js:143] [pc=0x3629ef616696] (this=0x3d1d32904189 <undefin...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/bin/node]
 2: 0xe2c5fc [/usr/bin/node]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [/usr/bin/node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/bin/node]
 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/usr/bin/node]
 6: v8::internal::Runtime_SparseJoinWithSeparator(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/bin/node]
 7: 0x3629ef50961b

Server is uitgerust met 16 GB RAM en 24 GB SSD-swap. Ik betwijfel ten zeerste of mijn script 36 GB geheugen overschreed. Het zou in ieder geval niet moeten

Script creëert index van bestanden die zijn opgeslagen als Array of Objects met metadata van bestanden (wijzigingsdatums, machtigingen, enz., geen big data)

Hier is de volledige scriptcode:
http://pastebin.com/mjaD76c3

Ik heb in het verleden al rare problemen met knooppunten ondervonden met dit script, waardoor ik bijv. index splitsen in meerdere bestanden omdat het knooppunt haperde bij het werken aan grote bestanden als String. Is er een manier om het geheugenbeheer van nodejs te verbeteren met enorme datasets?

Antwoord 1, autoriteit 100%

Als ik het me goed herinner, is er een strikte standaardlimiet voor het geheugengebruik in V8 van ongeveer 1,7 GB, als je deze niet handmatig verhoogt.

In een van onze producten hebben we deze oplossing gevolgd in ons implementatiescript:

node --max-old-space-size=4096 yourFile.js

Er zou ook een nieuwe ruimteopdracht zijn, maar zoals ik hier lees: a-tour-of-v8-garbage-collectionde nieuwe ruimte verzamelt alleen de nieuw gecreëerde kortetermijngegevens en de oude ruimte bevat alle gegevensstructuren waarnaar wordt verwezen, wat in jouw geval de beste optie zou moeten zijn.

Antwoord 2, autoriteit 34%

Als u het geheugengebruik van het knooppunt globaal wilt vergroten – niet alleen een enkel script, kunt u de omgevingsvariabele als volgt exporteren:
export NODE_OPTIONS=--max_old_space_size=4096

Dan hoef je niet met bestanden te spelen bij het uitvoeren van builds zoals
npm run build.

Antwoord 3, autoriteit 27%

Voor het geval iemand dit tegenkomt in een omgeving waar ze node-eigenschappen niet rechtstreeks kunnen instellen (in mijn geval een build-tool):

NODE_OPTIONS="--max-old-space-size=4096" node ...

U kunt de knooppuntopties instellen met behulp van een omgevingsvariabele als u ze niet kunt doorgeven op de opdrachtregel.

Antwoord 4, autoriteit 14%

Hier zijn enkele vlagwaarden om wat extra informatie toe te voegen over hoe u meer geheugen kunt toestaan wanneer u uw node-server opstart.

1 GB – 8 GB

#increase to 1gb
node --max-old-space-size=1024 index.js
#increase to 2gb
node --max-old-space-size=2048 index.js 
#increase to 3gb
node --max-old-space-size=3072 index.js
#increase to 4gb
node --max-old-space-size=4096 index.js
#increase to 5gb
node --max-old-space-size=5120 index.js
#increase to 6gb
node --max-old-space-size=6144 index.js
#increase to 7gb
node --max-old-space-size=7168 index.js
#increase to 8gb 
node --max-old-space-size=8192 index.js 

Antwoord 5, autoriteit 8%

Ik had net hetzelfde probleem met mijn EC2-instantie t2.micro die 1 GB geheugen heeft.

Ik heb het probleem opgelost door een wisselbestand te maken met diturl en stel de volgende omgevingsvariabele in.

export NODE_OPTIONS=--max_old_space_size=4096

Eindelijk is het probleem verdwenen.

Ik hoop dat dit nuttig is voor de toekomst.

Antwoord 6, autoriteit 7%

Ik kwam dit probleem tegen toen ik probeerde te debuggen met VSCode, dus ik wilde alleen toevoegen dat dit de manier is waarop je het argument aan je debug-setup kunt toevoegen.

Je kunt het toevoegen aan de eigenschap runtimeArgsvan je configuratie in launch.json.

Zie voorbeeld hieronder.

{
"version": "0.2.0",
"configurations": [{
        "type": "node",
        "request": "launch",
        "name": "Launch Program",
        "program": "${workspaceRoot}\\server.js"
    },
    {
        "type": "node",
        "request": "launch",
        "name": "Launch Training Script",
        "program": "${workspaceRoot}\\training-script.js",
        "runtimeArgs": [
            "--max-old-space-size=4096"
        ]
    }
]}

Antwoord 7, autoriteit 6%

Ik worstelde hier zelfs mee na het instellen van –max-old-space-size.

Toen realiseerde ik me dat ik opties –max-old-space-size voor het karma-script moest plaatsen.

het is ook het beste om beide syntaxis te specificeren –max-old-space-size en –max_old_space_size mijn script voor karma :

node --max-old-space-size=8192 --optimize-for-size --max-executable-size=8192  --max_old_space_size=8192 --optimize_for_size --max_executable_size=8192 node_modules/karma/bin/karma start --single-run --max_new_space_size=8192   --prod --aot

referentie https://github.com/angular/angular-cli/issues/1652

Antwoord 8, autoriteit 5%

Ik had een soortgelijk probleem toen ik AOT hoekig bouwde. Het volgen van commando’s heeft me geholpen.

npm install -g increase-memory-limit
increase-memory-limit

Bron: https://geeklearning.io/angular-aot-webpack-memory -Trick /

9, Autoriteit 3%

Stappen om dit probleem op te lossen (in Windows) –

1. Opdrachtprompt openen en typ %appdata%Druk op ENTER
2. Navigeer naar %appdata%& gt; NPM-map
3. Open of bewerk ng.cmdin uw favoriete editor
4. Toevoegen --max_old_space_size=8192NAAR HET IND EN ELSE BLOK

Uw node.cmdBestand ziet er als volgt uit na de wijziging:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe" "--max_old_space_size=8192" "%~dp0\node_modules\@angular\cli\bin\ng" %*
) ELSE (
  @SETLOCAL
  @SET PATHEXT=%PATHEXT:;.JS;=;%
  node "--max_old_space_size=8192" "%~dp0\node_modules\@angular\cli\bin\ng" %*
)

Antwoord 10, autoriteit 2%

Ik wil er alleen aan toevoegen dat in sommige systemen, zelfs het verhogen van de knooppuntgeheugenlimiet met --max-old-space-size, het niet genoeg is en dat er een OS-fout is zoals deze:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

In dit geval komt dit waarschijnlijk omdat u de maximale mmap per proces heeft bereikt.

Je kunt de max_map_count controleren door uit te voeren

sysctl vm.max_map_count

en vergroot het door te rennen

sysctl -w vm.max_map_count=655300

en herstel het zodat het niet opnieuw wordt ingesteld na een herstart door deze regel toe te voegen

vm.max_map_count=655300

in /etc/sysctl.confbestand.

Controleer hiervoor meer info.

Een goede methode om de fout te analyseren is door het proces uit te voeren met strace

strace node --max-old-space-size=128000 my_memory_consuming_process.js

Antwoord 11

als u het geheugen globaal voor node (windows) wilt wijzigen, gaat u naar geavanceerde systeeminstellingen -> omgevingsvariabelen -> nieuwe gebruikersvariabele

variable name = NODE_OPTIONS
variable value = --max-old-space-size=4096

Antwoord 12

U kunt de omgevingsvariabelen van Windows ook wijzigen met:

$env:NODE_OPTIONS="--max-old-space-size=8192"

Antwoord 13

Onlangs kwam ik in een van mijn projecten hetzelfde probleem tegen. Ik heb een aantal dingen geprobeerd die iedereen kan proberen als foutopsporing om de oorzaak te achterhalen:

1. Zoals iedereen suggereerde, verhoog de geheugenlimiet in node door deze opdracht toe te voegen:

   {
      "scripts":{
         "server":"node --max-old-space-size={size-value} server/index.js"
      }
   }
   

Hier size-valuedie ik heb gedefinieerd voor mijn toepassing was 1536 (aangezien mijn kubernetes-podgeheugen een limiet van 2 GB was, verzoek 1,5 GB)

Definieer dus altijd de size-valueop basis van uw frontend-infrastructuur/architectuurlimiet (iets minder dan de limiet)

Eén strikte toelichting hier in de bovenstaande opdracht, gebruik --max-old-space-sizena de opdracht nodeen niet na de bestandsnaam server/index.js.

1. Als je een ngnixconfiguratiebestand hebt, controleer dan de volgende dingen:

   • worker_connections: 16384(voor zware frontend-applicaties)
     [nginx is standaard 512verbindingen per worker, wat te laag is voor moderne toepassingen]

   • use: epoll(efficiënte methode) [nginx ondersteunt verschillende verbindingsverwerkingsmethoden]

   • http: voeg de volgende dingen toe om te voorkomen dat uw werknemer druk wordt met het afhandelen van een ongewenste taak. (client_body_timeout , reset_timeout_connection , client_header_timeout,keepalive_timeout ,send_timeout).

2. Verwijder alle logging/tracking-tools zoals APM , Kafka , UTM tracking, Prerender(SEO) enz. middlewaresof schakel uit.

3. Nu foutopsporing op codeniveau: verwijder in uw hoofdbestand serverde ongewenste console.logdie alleen maar een bericht afdrukt.

4. Controleer nu voor elke serverroute, bijv. app.get() , app.post() ...onderstaande scenario’s:

• data => if(data) res.send(data)// moet je echt wachten op data of dat api iets terugstuurt als antwoord waarop ik moet wachten?? , Zo niet, wijzig dan als volgt:

data => res.send(data) // this will not block your thread, apply everywhere where it's needed

• anders deel: als er geen foutmelding komt, return res.send({}), NEEconsole.log here.

• foutgedeelte: sommige mensen definiëren het als errorof errwat voor verwarring en fouten zorgt. zoals dit:

  `error => { next(err) } // here err is undefined`
   `err => {next(error) } // here error is undefined`
   `app.get(API , (re,res) =>{
       error => next(error) // here next is not defined
    })`
  

• verwijder winston, elastic-epm-nodeandere ongebruikte bibliotheken met de opdracht npx depcheck.

• Controleer in het axios-servicebestand de methoden en log goed of niet zoals:

   if(successCB) console.log("success") successCB(response.data) // here it's wrong statement, because on success you are just logging and then `successCB` sending  outside the if block which return in failure case also.
  

• Behoed jezelf voor het gebruik van stringify , parseenz. op een grote dataset. (wat ik ook kan zien in je hierboven getoonde logs.

5. Last but not least, voor elke keer dat uw toepassing crasht of pods opnieuw worden opgestart, controleert u de logboeken. Zoek in het logboek specifiek naar deze sectie: Security context
   Dit geeft je waarom, waar en wiede boosdoenerachter de crash is.

Antwoord 14

Voor andere beginners zoals ik, die geen geschikte oplossing voor deze fout hebben gevonden, controleer de geïnstalleerde node-versie(x32, x64, x86). Ik heb een 64-bits CPU en ik heb de x86-nodeversie geïnstalleerd, waardoor de fout CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory.

Antwoord 15

Deze opdracht werkt perfect. Ik heb 8GB ram in mijn laptop, dus ik heb size=8192 ingesteld. Het draait allemaal om ram en je hebt ook een ingestelde bestandsnaam nodig. Ik voer de opdracht npm run builduit, daarom heb ik build.jsgebruikt.

node --expose-gc --max-old-space-size=8192 node_modules/react-scripts/scripts/build.js

Antwoord 16

In mijn geval heb ik de node.js-versie geüpgraded naar de nieuwste (versie 12.8.0) en het werkte als een tierelier.

Antwoord 17

Upgrade het knooppunt naar de nieuwste versie. Ik zat op node 6.6 met deze fout en upgrade naar 8.9.4 en het probleem was weg.

Antwoord 18

Voor het geval het mensen kan helpen die dit probleem hebben bij het gebruik van nodejs-apps die veel logboekregistratie produceren, heeft een collega dit probleem opgelost door de standaarduitvoer(en) naar een bestand te pipen.

Antwoord 19

Als u niet nodezelf probeert te starten, maar een andere soft, bijvoorbeeld webpack, kunt u de omgevingsvariabele en cross-envpakket:

$ cross-env NODE_OPTIONS='--max-old-space-size=4096' \
  webpack --progress --config build/webpack.config.dev.js

Antwoord 20

Voor hoekige projectbundeling heb ik de onderstaande regel toegevoegdaan mijn pakage.json-bestand in de sectie scripts.

"build-prod": "node --max_old_space_size=5120 ./node_modules/@angular/cli/bin/ng build --prod --base-href /"

Om mijn code te bundelen, gebruik ik npm run build-prodin plaats van ng build --requiredFlagsHere

hoop dat dit helpt!

Antwoord 21

Voor Angularheb ik dit zo opgelost

In Package.json, binnen de scripttag voeg dit toe

"scripts": {
  "build-prod": "node --max_old_space_size=5048 ./node_modules/@angular/cli/bin/ng build --prod",
},

Nu in terminal/cmdin plaats van ng build --prodte gebruiken, gebruik gewoon

npm run build-prod

Als je deze configuratie alleen voor buildwilt gebruiken, verwijder dan gewoon --prodvan alle 3 plaatsen

Antwoord 22

Gebruik de optie --optimize-for-size. Het gaat zich richten op het gebruik van minder ram.

Antwoord 23

In mijn geval had ik npm installuitgevoerd op de vorige versie van node, na een dag heb ik de node-versie geüpgraded en ram npm installvoor een paar modules. Hierna kreeg ik deze foutmelding.
Om dit probleem op te lossen heb ik de map node_module van elk project verwijderd en npm installopnieuw uitgevoerd.

Ik hoop dat dit het probleem kan oplossen.

Opmerking: dit gebeurde op mijn lokale computer en het werd alleen op de lokale computer opgelost.

Antwoord 24

Als een van de gegeven antwoorden niet voor u werkt, controleer dan of uw geïnstalleerde node compatibel is (d.w.z. 32-bits of 64-bits) met uw systeem. Gewoonlijk treedt dit type fout op vanwege incompatibele knooppunt- en besturingssysteemversies en terminal/systeem zal u daar niets over vertellen, maar u blijft een geheugenfout geven.

Antwoord 25

Als je geheugen of RAM beperkt is, voer dan de volgende opdracht uit.

ng serve –source-map=false

Het zal in staat zijn om de applicatie te starten. Voor mijn voorbeeld heeft het 16 GB RAM nodig. Maar ik kan werken met 8 GB RAM.

Antwoord 26

Voer deze opdracht uit
ng build –configuration

Antwoord 27

Controleer of u de 32-bits versie van node niet op een 64-bits machine hebt geïnstalleerd. Als u node op een 64-bits of 32-bits machine draait, moet de nodejs-map zich respectievelijk in Program Files en Program Files (x86) bevinden.

Antwoord 28

In tsconfig. Json-bestand Ik heb doel :”es05″ gewijzigd in doel:”es2020″
Het werkte voor mij.