config.addMiddleware = function(bodyParser, app, q, qx, qewdConfig) {
// your own addMiddleware code ....
// when QEWD.js is started, install memory limit monitoring for workers
q.on('started', function() {
var checkWorkerMemoryDelay = q.userDefined.checkWorkerMemoryDelay || 300000; // default every 5 minutes
var memoryLimitMonitor = null
var workerMemoryLimit = q.userDefined.workerMemoryLimit || 1024; // default 1 GB max. per worker
var monitorMemoryLimit = function() {
// every 5 minutes, check current memory consumption of all workers
q.handleStats(function(messageObj) {
var checkWorkerMemoryLimit = function(workerStat) {
// if a worker exceeds our given memory limit, send it a stopWorker message to shut it down gracefully and release it's memory
if (+workerStat.memory.rss > workerMemoryLimit) {
console.log(`Worker ${workerStat.pid} reached rss memory limit (${workerStat.memory.rss} MB > ${workerMemoryLimit} MB), stopping worker ...`)
q.stopWorker(workerStat.pid)
}
}
let workerStats = messageObj.worker
if (workerStats) {
workerStats.forEach(checkWorkerMemoryLimit)
}
});
}
// now install the memory limit monitor interval timer
memoryLimitMonitor = setInterval(monitorMemoryLimit, checkWorkerMemoryDelay)
console.log(`Memory limit monitoring for workers has started on master ${process.pid} (rss limit = ${workerMemoryLimit})`)
// when QEWD.js is stopped, clear the memory limit monitor interval timer
q.on('stop', function() {
if (memoryLimitMonitor) {
clearInterval(memoryLimitMonitor)
console.log(`Memory limit monitoring for workers has stopped on master ${process.pid}`)
}
});
})
};
It does sound like there’s some kind of fault here. I’m not aware of any memory leaks in mg-dbx but I’ll check this – specifically the part that invokes Cache functions – before the next release.
One notorious area where the V8 engine can consume an excess amount of memory is related to the garbage collector. The V8 engine tends to be a little slow in cleaning up objects that it identifies as being out of scope. A consequence of this is that JS scripts that quickly generate lots of JS objects can consume a lot of memory in a short period of time. However, the garbage collector should (and usually does) spring into action before memory usage becomes critical. Most of the time it simply appears that Node.js/V8 is a bit greedy.
With this ‘issue’ in mind all object classes managed by mg-dbx (global, class and cursor) all have Close and Reset methods. The Reset method is particularly useful as it allows the same JS container to be reused – and, as such, avoids V8 allocating further memory to hold the (new) Cache object.
I’ll carry out some further investigation before the next update.
Chris.
--
You received this message because you are subscribed to the Google Groups "Enterprise Web Developer Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise-web-develope...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/enterprise-web-developer-community/42422a22-7ca8-4850-a6d4-3e97e4e70a37n%40googlegroups.com.