我在这里有一个赏金的问题:
看起来好像是由于VPS的最大内存大小,现在在将VPS内存大小增加到4GB之后,当GC似乎启动时节点JS消耗3.x GB.然后在节点之前需要大约1小时到GC再次变得敏感,至少看起来就像服务器监控工具一样:空闲内存达到0,然后持续约60分钟进程运行(CPU负载上升),之后Node.JS应用程序再次发送数据.
这么长的垃圾收集过程"正常"吗?我错过了什么吗?
这里有一些图表来说明它:图1:CPU负载1 Min,图2:网络流量,Mbps,图3:CPU utlization
![在此处输入图像说明] [1]
对于那些没有按照上面的链接,这个问题是关于使用Pub/Sub和Redis接收消息然后发送到所有连接的客户端的节点应用程序.
我已经注释掉"发送给客户"并且内存增加大幅减慢,让我相信这可能是部分原因,这是该部分的代码:
nUseDelay=1;
....
....
if(nUseDelay>0) {
setInterval(function() {
Object.getOwnPropertyNames(ablv_last_message).forEach(function(val, idx, array) {
io.sockets.emit('ablv', ablv_last_message[val]);
});
ablv_last_message= {};
}, 15000*nUseDelay);
}
Run Code Online (Sandbox Code Playgroud)
如果我评论出来:
// Object.getOwnPropertyNames(ablv_last_message).forEach(function(val, idx, array) {
// io.sockets.emit('ablv', ablv_last_message[val]);
// });
Run Code Online (Sandbox Code Playgroud)
内存增加似乎非常缓慢.为什么会这样?这是一个所谓的"关闭",如果是这样,如何理想地重新编码?
这里是完整的代码,这不是一件非常复杂的工作,它看起来更像是任何这种情况的标准框架,其中Node.JS应用程序将中央应用程序的信息发送给所有连接的客户端:
var nVersion="01.05.00";
var nClients=0;
var nUseDelay=1;
var ablv_last_message = [];
// Production
var https = require('https');
var nPort = 6000; // Port of the Redis Server
var nHost = "123.123.123.123"; // Host that is running the Redis Server
var sPass = "NOT GONNA TELL YA";
var fs = require('fs');
var socketio = require('socket.io');
var redis = require('redis');
// The server options
var svrPort = 443; // This is the port of service
var svrOptions = {
key: fs.readFileSync('/etc/ssl/private/key.key'),
cert: fs.readFileSync('/etc/ssl/private/crt.crt'),
ca: fs.readFileSync( '/etc/ssl/private/cabundle.crt')
};
// Create a Basic server and response
var servidor = https.createServer( svrOptions , function( req , res ){
res.writeHead(200);
res.end('Hi!');
});
// Create the Socket.io Server over the HTTPS Server
io = socketio.listen( servidor );
// Now listen in the specified Port
servidor.listen( svrPort );
console.log("Listening for REDIS on " + nHost + ":" + nPort);
io.enable('browser client minification'); // send minified client
io.enable('browser client etag'); // apply etag caching logic based on version number
io.enable('browser client gzip'); // gzip the file
io.set('log level', 1); // reduce logging
io.set('transports', [
'websocket'
, 'flashsocket'
, 'htmlfile'
, 'xhr-polling'
, 'jsonp-polling'
]);
cli_sub = redis.createClient(nPort,nHost);
if(sPass != "") {
cli_sub.auth(sPass, function() {console.log("Connected!");});
}
cli_sub.subscribe("vcx_ablv");
console.log ("Completed to initialize the server. Listening to messages.");
io.sockets.on('connection', function (socket) {
nClients++;
console.log("Number of clients connected " + nClients);
socket.on('disconnect', function () {
nClients--;
console.log("Number of clients remaining " + nClients);
});
});
cli_sub.on("message",function(channel,message) {
var oo = JSON.parse(message);
ablv_last_message[oo[0]["base"]+"_"+oo[0]["alt"]] = message;
});
if(nUseDelay>0) {
var jj= setInterval(function() {
Object.getOwnPropertyNames(ablv_last_message).forEach(function(val, idx, array) {
io.sockets.emit('ablv', ablv_last_message[val]);
});
ablv_last_message= {};
}, 5000*nUseDelay);
}
Run Code Online (Sandbox Code Playgroud)
在这里运行应用程序几分钟之后的堆转换分析:![在此处输入图像描述] [2]
我想我会碰到这个问题,因为还没有给出令人满意的答案.
顺便说一句,我把NGINX放在Node.JS应用程序的前面,所有内存问题都消失了,节点应用程序现在稳定在500MB左右 - 1GB.
我们最近遇到了同样的问题。
Socket.io v0.9.16 会自动为每个连接打开 5 个通道,并且很难关闭它们。我们有 18 台服务器正在运行,它们不断增加内存,直到冻结并重新启动服务器。
通过更新到 Socket.io v0.9.17,问题消失了。
我们花了一到三个星期的时间检查每一行代码以找到罪魁祸首。
归档时间: |
|
查看次数: |
1068 次 |
最近记录: |