I have an application written in Node.js which works fine when running on one server. When I try running it in a Vagrant virtual machine, I get ENOMEM
errors when trying to read from files. These files are not particularly big (one of the files triggering the error is 65 kilobytes, for example), and the virtual machine seems to have plenty of memory available. I'm using tmux
to have two consoles open, and when I run free -H
while the application is running, it reports plenty of free memory:
total used free shared buff/cache available
Mem: 3.8Gi 183Mi 3.1Gi 0.0Ki 577Mi 3.4Gi
Swap: 0B 0B 0B
I've also tried increasing the soft file limits from 1024 to 100_000 in case that was the issue:
$ ulimit -Sn
100000
The code triggering the error looks like this:
const nodeFs = require('node-fs');
// ...
const threadFilename = 'data/threads/' + id;
nodeFs.readFile(threadFilename, (err, strFileContents) => {
logger.debug(`nodeFs.readFile returned for thread ${id}`);
if (err) {
logger.error('Failed to read from ' + threadFilename);
logger.error(util.inspect(err));
return reject(err);
} else {
//...
}
});
And the error message that gets logged is:
error: [thread.js]Failed to read from data/threads/1853055ec62c5069
error: [thread.js][Error: ENOMEM: not enough memory, open 'data/threads/1853055ec62c5069'] {
errno: -12,
code: 'ENOMEM',
syscall: 'open',
path: 'data/threads/1853055ec62c5069'
}
This error message is repeated like a hundred times, once for each file I'm trying to open. (Note that "threads" here is referring to discussion threads; the program isn't doing anything fancy with multithreading)
If I try to open the node REPL and directly read the file, it works fine:
Welcome to Node.js v18.12.1.
Type ".help" for more information.
> const nodeFs = require('node-fs')
undefined
> nodeFs.readFile('data/threads/1853087ddbe2300c', (err, str) => { console.log("err", err, "str", str) })
undefined
> err null str <Buffer 7b 22 69 64 22 3a 22 31 38 35 33 30 38 37 64 64 62 65 32 33 30 30 63 22 2c 22 68 69 73 74 6f 72 79 49 64 22 3a 22 33 34 36 36 32 38 38 37 22 2c 22 6d ... 136972 more bytes>
I'm looking for advice on how to debug this further.