Šiandien paleidau savo scenarijų failų sistemos indeksavimui, kad atnaujinčiau RAID failų indeksą ir po 4h jis sugedo su tokia klaida:
[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
Serveris turi 16gb RAM ir 24gb SSD swap. Labai abejoju, kad mano scenarijus viršijo 36 gb atminties. Bent jau neturėtų
Skriptas sukuria failų indeksą, saugomą kaip objektų masyvą su failų metaduomenimis (modifikavimo datos, leidimai ir t. t., jokių didelių duomenų).
Čia's pilnas scenarijaus kodas: http://pastebin.com/mjaD76c3
Jau anksčiau su šiuo scenarijumi susidūriau su keistomis mazgo problemomis, dėl kurių buvau priverstas, pvz., suskaidyti indeksą į kelis failus, nes dirbant su tokiais dideliais failais, kaip String, mazgas strigdavo. Ar yra koks nors būdas pagerinti nodejs atminties valdymą dirbant su didžiuliais duomenų rinkiniais?
Jei teisingai pamenu, "V8" yra griežta standartinė atminties naudojimo riba - maždaug 1,7 GB, jei jos nedidinate rankiniu būdu.
Viename iš mūsų produktų diegimo scenarijuje laikėmės šio sprendimo:
node --max-old-space-size=4096 yourFile.js
Taip pat būtų nauja erdvinė komanda, bet, kaip čia perskaičiau: a-tour-of-v8-garbage-collection naujoje erdvėje surenkami tik naujai sukurti trumpalaikiai duomenys, o senojoje erdvėje yra visos nurodytos duomenų struktūros, kas jūsų atveju turėtų būti geriausias variantas.
Su šia problema susidūriau bandydamas derinti su "VSCode", todėl tiesiog norėjau pridurti, kaip galite pridėti argumentą prie derinimo sąrankos.
Jį galite pridėti prie savo konfigūracijos runtimeArgs
savybės launch.json
.
Žr. toliau pateiktą pavyzdį.
{
"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"
]
}
]}
su tuo susidūriau net nustatęs --max-old-space-size.
Tada supratau, kad reikia prieš karmos scenarijų įdėti parinktis --max-old-space-size.
taip pat geriausia nurodyti abi sintakses --max-old-space-size ir --max_old_space_size mano karma scenarijuje:
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