บางวันฉันได้ค้นหาวิธีการแก้ไขข้อผิดพลาด

Error: EMFILE, too many open files

ดูเหมือนว่าหลายคนมีปัญหาเดียวกัน คำตอบปกติเกี่ยวข้องกับการเพิ่มจำนวนของตัวอธิบายไฟล์ ดังนั้นฉันได้ลอง:

sysctl -w kern.maxfiles=20480,

ค่าเริ่มต้นคือ 10240 นี่เป็นสิ่งที่แปลกในสายตาของฉันเพราะจำนวนไฟล์ที่ฉันจัดการในไดเรกทอรีอยู่ภายใต้ 10240 แม้แต่คนแปลกหน้าฉันยังคงได้รับข้อผิดพลาดเดียวกันหลังจากฉันเพิ่มจำนวนตัวอธิบายไฟล์ .

คำถามที่สอง:

หลังจากการค้นหาจำนวนหนึ่งฉันพบวิธีแก้ไขปัญหา "ไฟล์เปิดมากเกินไป":

var requestBatches = {};
function batchingReadFile(filename, callback) {
  // First check to see if there is already a batch
  if (requestBatches.hasOwnProperty(filename)) {
    requestBatches[filename].push(callback);
    return;
  }

  // Otherwise start a new one and make a real request
  var batch = requestBatches[filename] = [callback];
  FS.readFile(filename, onRealRead);

  // Flush out the batch on complete
  function onRealRead() {
    delete requestBatches[filename];
    for (var i = 0, l = batch.length; i < l; i++) {
      batch[i].apply(null, arguments);
    }
  }
}

function printFile(file){
    console.log(file);
}

dir = "/Users/xaver/Downloads/xaver/xxx/xxx/"

var files = fs.readdirSync(dir);

for (i in files){
    filename = dir + files[i];
    console.log(filename);
    batchingReadFile(filename, printFile);

น่าเสียดายที่ฉันยังคงได้รับข้อผิดพลาดเดียวกัน เกิดอะไรขึ้นกับรหัสนี้?

หนึ่งคำถามสุดท้าย (ฉันใหม่สำหรับ javascript และ node) ฉันอยู่ในขั้นตอนการพัฒนาเว็บแอปพลิเคชั่นพร้อมคำขอจำนวนมากสำหรับผู้ใช้ประมาณ 5,000 คนต่อวัน ฉันมีประสบการณ์หลายปีในการเขียนโปรแกรมกับภาษาอื่นเช่น python และ java ตอนแรกฉันคิดว่าจะพัฒนาแอพพลิเคชั่นนี้ด้วย django หรือ play framework จากนั้นฉันก็ค้นพบโหนดและฉันต้องบอกว่าความคิดของโมเดล I / O ที่ไม่บล็อกนั้นดีมากมีเสน่ห์และส่วนใหญ่ทั้งหมดนั้นเร็วมาก!

แต่ปัญหาแบบไหนที่ฉันควรคาดหวังจากโหนด? มันเป็นเว็บเซิร์ฟเวอร์ที่ได้รับการพิสูจน์แล้วหรือไม่? คุณมีประสบการณ์อย่างไร

เพราะเมื่อสง่างาม-FSไม่ทำงาน ... หรือคุณเพียงต้องการที่จะเข้าใจว่าการรั่วไหลมาจาก ทำตามขั้นตอนนี้

(เช่นเกี้ยวพาราสี -f จะไม่แก้ไขเกวียนของคุณหากปัญหาของคุณอยู่กับซ็อกเก็ต)

จากบทความบล็อกของฉัน: http://www.blakerobertson.com/devlog/2014/1/11/how-to-determine-whats-causing-error-connect-emfile-nodejs.html

วิธีการแยก

คำสั่งนี้จะส่งออกจำนวนของการจัดการเปิดสำหรับกระบวนการ nodejs:

lsof -i -n -P | grep nodejs

COMMAND     PID    USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
...
nodejs    12211    root 1012u  IPv4 151317015      0t0  TCP 10.101.42.209:40371->54.236.3.170:80 (ESTABLISHED)
nodejs    12211    root 1013u  IPv4 151279902      0t0  TCP 10.101.42.209:43656->54.236.3.172:80 (ESTABLISHED)
nodejs    12211    root 1014u  IPv4 151317016      0t0  TCP 10.101.42.209:34450->54.236.3.168:80 (ESTABLISHED)
nodejs    12211    root 1015u  IPv4 151289728      0t0  TCP 10.101.42.209:52691->54.236.3.173:80 (ESTABLISHED)
nodejs    12211    root 1016u  IPv4 151305607      0t0  TCP 10.101.42.209:47707->54.236.3.172:80 (ESTABLISHED)
nodejs    12211    root 1017u  IPv4 151289730      0t0  TCP 10.101.42.209:45423->54.236.3.171:80 (ESTABLISHED)
nodejs    12211    root 1018u  IPv4 151289731      0t0  TCP 10.101.42.209:36090->54.236.3.170:80 (ESTABLISHED)
nodejs    12211    root 1019u  IPv4 151314874      0t0  TCP 10.101.42.209:49176->54.236.3.172:80 (ESTABLISHED)
nodejs    12211    root 1020u  IPv4 151289768      0t0  TCP 10.101.42.209:45427->54.236.3.171:80 (ESTABLISHED)
nodejs    12211    root 1021u  IPv4 151289769      0t0  TCP 10.101.42.209:36094->54.236.3.170:80 (ESTABLISHED)
nodejs    12211    root 1022u  IPv4 151279903      0t0  TCP 10.101.42.209:43836->54.236.3.171:80 (ESTABLISHED)
nodejs    12211    root 1023u  IPv4 151281403      0t0  TCP 10.101.42.209:43930->54.236.3.172:80 (ESTABLISHED)
....

สังเกตเห็นว่า: 1023u (บรรทัดสุดท้าย) - นั่นคือตัวจัดการไฟล์ที่ 1024 ซึ่งเป็นค่าเริ่มต้นสูงสุด

ตอนนี้ดูที่คอลัมน์สุดท้าย นั่นบ่งชี้ว่าทรัพยากรใดเปิดอยู่ คุณอาจเห็นจำนวนบรรทัดทั้งหมดที่มีชื่อทรัพยากรเดียวกัน หวังว่าตอนนี้จะบอกคุณว่าจะดูรหัสของคุณสำหรับการรั่วไหลที่

หากคุณไม่ทราบกระบวนการหลายโหนดขั้นแรกให้ค้นหาว่ากระบวนการใดมี pid 12211 ซึ่งจะบอกคุณเกี่ยวกับกระบวนการ

ในกรณีของฉันข้างต้นฉันสังเกตเห็นว่ามีที่อยู่ IP ที่คล้ายกันจำนวนมาก พวกเขาทั้งหมด54.236.3.### โดยทำการค้นหาที่อยู่ IP ก็สามารถที่จะกำหนดในกรณีของฉันมันเกี่ยวข้องกับ pubnub

การอ้างอิงคำสั่ง

ใช้ไวยากรณ์นี้เพื่อพิจารณาว่ามีการเปิดจำนวนเท่าใดที่กระบวนการเปิด ...

ในการรับจำนวนไฟล์ที่เปิดสำหรับ pid ที่แน่นอน

ฉันใช้คำสั่งนี้เพื่อทดสอบจำนวนไฟล์ที่เปิดหลังจากทำกิจกรรมต่าง ๆ ในแอพของฉัน

lsof -i -n -P | grep "8465" | wc -l

# lsof -i -n -P | grep "nodejs.*8465" | wc -l
28
# lsof -i -n -P | grep "nodejs.*8465" | wc -l
31
# lsof -i -n -P | grep "nodejs.*8465" | wc -l
34

ขีด จำกัด กระบวนการของคุณคืออะไร

ulimit -a

บรรทัดที่คุณต้องการจะมีลักษณะเช่นนี้:

open files                      (-n) 1024

เปลี่ยนขีด จำกัด อย่างถาวร:

• ทดสอบบน Ubuntu 14.04, nodejs v. 7.9

ในกรณีที่คุณคาดว่าจะเปิดการเชื่อมต่อมากมาย (websockets เป็นตัวอย่างที่ดี) คุณสามารถเพิ่มขีด จำกัด ได้อย่างถาวร:

• ไฟล์: /etc/pam.d/common-session (เพิ่มที่ส่วนท้าย)

  session required pam_limits.so

• ไฟล์: /etc/security/limits.conf (เพิ่มที่ส่วนท้ายหรือแก้ไขหากมีอยู่แล้ว)

  root soft  nofile 40000
  root hard  nofile 100000

• รีสตาร์ท nodejs ของคุณและล็อกเอาต์ / ล็อกอินจาก ssh

• สิ่งนี้อาจไม่ทำงานกับ NodeJS รุ่นเก่าที่คุณจะต้องรีสตาร์ทเซิร์ฟเวอร์
• ใช้แทนถ้าโหนดของคุณทำงานด้วย uid ที่แตกต่างกัน

การใช้graceful-fsโมดูลโดย Isaac Schlueter (ผู้ดูแล node.js) น่าจะเป็นทางออกที่เหมาะสมที่สุด มันจะถอยกลับเพิ่มขึ้นหากพบ EMFILE สามารถใช้แทนการดรอปดาวน์สำหรับfsโมดูลในตัวได้

ฉันไม่แน่ใจว่าสิ่งนี้จะช่วยให้ทุกคนหรือไม่ฉันเริ่มทำงานในโครงการขนาดใหญ่ที่มีการพึ่งพามากมายซึ่งทำให้ฉันมีข้อผิดพลาดเดียวกัน เพื่อนร่วมงานของฉันแนะนำให้ฉันติดตั้งwatchmanโดยใช้การชงและแก้ไขปัญหานี้ให้ฉันได้

brew update
brew install watchman

แก้ไขเมื่อวันที่ 26 มิถุนายน 2019: ลิงค์ Github เพื่อเฝ้าดู

ฉันพบปัญหานี้ในวันนี้และหาวิธีแก้ปัญหาที่ดีสำหรับฉันฉันสร้างโมดูลเพื่อแก้ไขมัน ฉันได้รับแรงบันดาลใจจากตัวอย่างของ @ fbartho แต่ต้องการหลีกเลี่ยงการเขียนทับโมดูล fs

โมดูลที่ฉันเขียนคือFilequeueและคุณใช้มันเหมือน fs:

var Filequeue = require('filequeue');
var fq = new Filequeue(200); // max number of files to open at once

fq.readdir('/Users/xaver/Downloads/xaver/xxx/xxx/', function(err, files) {
    if(err) {
        throw err;
    }
    files.forEach(function(file) {
        fq.readFile('/Users/xaver/Downloads/xaver/xxx/xxx/' + file, function(err, data) {
            // do something here
        }
    });
});

คุณอ่านไฟล์มากเกินไป โหนดอ่านไฟล์แบบอะซิงโครนัสมันจะอ่านไฟล์ทั้งหมดพร้อมกัน ดังนั้นคุณอาจจะอ่านขีด จำกัด 10240

ดูว่างานนี้:

var fs = require('fs')
var events = require('events')
var util = require('util')
var path = require('path')

var FsPool = module.exports = function(dir) {
    events.EventEmitter.call(this)
    this.dir = dir;
    this.files = [];
    this.active = [];
    this.threads = 1;
    this.on('run', this.runQuta.bind(this))
};
// So will act like an event emitter
util.inherits(FsPool, events.EventEmitter);

FsPool.prototype.runQuta = function() {
    if(this.files.length === 0 && this.active.length === 0) {
        return this.emit('done');
    }
    if(this.active.length < this.threads) {
        var name = this.files.shift()

        this.active.push(name)
        var fileName = path.join(this.dir, name);
        var self = this;
        fs.stat(fileName, function(err, stats) {
            if(err)
                throw err;
            if(stats.isFile()) {
                fs.readFile(fileName, function(err, data) {
                    if(err)
                        throw err;
                    self.active.splice(self.active.indexOf(name), 1)
                    self.emit('file', name, data);
                    self.emit('run');

                });
            } else {
                self.active.splice(self.active.indexOf(name), 1)
                self.emit('dir', name);
                self.emit('run');
            }
        });
    }
    return this
};
FsPool.prototype.init = function() {
    var dir = this.dir;
    var self = this;
    fs.readdir(dir, function(err, files) {
        if(err)
            throw err;
        self.files = files
        self.emit('run');
    })
    return this
};
var fsPool = new FsPool(__dirname)

fsPool.on('file', function(fileName, fileData) {
    console.log('file name: ' + fileName)
    console.log('file data: ', fileData.toString('utf8'))

})
fsPool.on('dir', function(dirName) {
    console.log('dir name: ' + dirName)

})
fsPool.on('done', function() {
    console.log('done')
});
fsPool.init()

เช่นเดียวกับพวกเราทุกคนคุณเป็นเหยื่อของ I / O อะซิงโครนัส ด้วยการโทรแบบอะซิงโครนัสถ้าคุณวนรอบไฟล์จำนวนมาก Node.js จะเริ่มเปิดตัวอธิบายไฟล์เพื่อให้แต่ละไฟล์อ่านแล้วจะรอการดำเนินการจนกว่าคุณจะปิดมัน

ตัวอธิบายไฟล์จะยังคงเปิดอยู่จนกว่าเซิร์ฟเวอร์จะสามารถอ่านทรัพยากรได้ แม้ว่าไฟล์ของคุณจะเล็กและการอ่านหรืออัปเดตนั้นรวดเร็ว แต่ก็ใช้เวลาพอสมควร แต่ในเวลาเดียวกันลูปของคุณก็ไม่หยุดที่จะเปิดไฟล์ descriptor ใหม่ ดังนั้นถ้าคุณมีไฟล์จำนวนมากเกินไปวงเงินที่จะถึงเร็ว ๆ นี้และคุณจะได้รับที่สวยงามEMFILE

มีวิธีแก้ไขปัญหาเดียวคือสร้างคิวเพื่อหลีกเลี่ยงผลกระทบนี้

ขอบคุณผู้เขียนAsyncมีฟังก์ชั่นที่มีประโยชน์มากสำหรับสิ่งนั้น มีวิธีการที่เรียกว่าAsync.queueคุณสร้างคิวใหม่ด้วยการ จำกัด แล้วเพิ่มชื่อไฟล์ลงในคิว

หมายเหตุ: หากคุณต้องเปิดไฟล์หลาย ๆ ไฟล์มันเป็นความคิดที่ดีที่จะจัดเก็บไฟล์ที่เปิดอยู่ในปัจจุบันและไม่ต้องเปิดไฟล์อีกครั้งอย่างไม่สิ้นสุด

const fs = require('fs')
const async = require("async")

var q = async.queue(function(task, callback) {
    console.log(task.filename);
    fs.readFile(task.filename,"utf-8",function (err, data_read) {
            callback(err,task.filename,data_read);
        }
    );
}, 4);

var files = [1,2,3,4,5,6,7,8,9,10]

for (var file in files) {
    q.push({filename:file+".txt"}, function (err,filename,res) {
        console.log(filename + " read");
    });
}

คุณจะเห็นว่าแต่ละไฟล์ถูกเพิ่มเข้าไปในคิว (ชื่อไฟล์ console.log) แต่เฉพาะเมื่อคิวปัจจุบันอยู่ภายใต้ขีด จำกัด ที่คุณตั้งไว้ก่อนหน้านี้

async.queue รับข้อมูลเกี่ยวกับความพร้อมของคิวผ่านการติดต่อกลับการโทรกลับนี้จะถูกเรียกก็ต่อเมื่อมีการอ่านไฟล์ข้อมูลและการกระทำใด ๆ ที่คุณต้องทำสำเร็จ (ดูวิธีการอ่านไฟล์)

ดังนั้นคุณจะไม่สามารถอธิบายไฟล์ได้

> node ./queue.js
0.txt
    1.txt
2.txt
0.txt read
3.txt
3.txt read
4.txt
2.txt read
5.txt
4.txt read
6.txt
5.txt read
7.txt
    1.txt read (biggest file than other)
8.txt
6.txt read
9.txt
7.txt read
8.txt read
9.txt read

ฉันเพิ่งเขียนตัวอย่างโค้ดเล็กน้อยเพื่อแก้ไขปัญหานี้ด้วยตัวเองโซลูชันอื่น ๆ ทั้งหมดปรากฏขึ้นอย่างหนักเกินไปและต้องการให้คุณเปลี่ยนโครงสร้างโปรแกรมของคุณ

โซลูชันนี้จะหยุดการโทร fs.readFile หรือ fs.writeFile ใด ๆ เพื่อไม่ให้เกินจำนวนที่กำหนดไว้ในเที่ยวบินในเวลาใดก็ตาม

// Queuing reads and writes, so your nodejs script doesn't overwhelm system limits catastrophically
global.maxFilesInFlight = 100; // Set this value to some number safeish for your system
var origRead = fs.readFile;
var origWrite = fs.writeFile;

var activeCount = 0;
var pending = [];

var wrapCallback = function(cb){
    return function(){
        activeCount--;
        cb.apply(this,Array.prototype.slice.call(arguments));
        if (activeCount < global.maxFilesInFlight && pending.length){
            console.log("Processing Pending read/write");
            pending.shift()();
        }
    };
};
fs.readFile = function(){
    var args = Array.prototype.slice.call(arguments);
    if (activeCount < global.maxFilesInFlight){
        if (args[1] instanceof Function){
            args[1] = wrapCallback(args[1]);
        } else if (args[2] instanceof Function) {
            args[2] = wrapCallback(args[2]);
        }
        activeCount++;
        origRead.apply(fs,args);
    } else {
        console.log("Delaying read:",args[0]);
        pending.push(function(){
            fs.readFile.apply(fs,args);
        });
    }
};

fs.writeFile = function(){
    var args = Array.prototype.slice.call(arguments);
    if (activeCount < global.maxFilesInFlight){
        if (args[1] instanceof Function){
            args[1] = wrapCallback(args[1]);
        } else if (args[2] instanceof Function) {
            args[2] = wrapCallback(args[2]);
        }
        activeCount++;
        origWrite.apply(fs,args);
    } else {
        console.log("Delaying write:",args[0]);
        pending.push(function(){
            fs.writeFile.apply(fs,args);
        });
    }
};

ฉันทำทุกสิ่งข้างต้นที่กล่าวถึงปัญหาเดียวกัน แต่ไม่มีอะไรทำงาน ฉันลองด้านล่างแล้วใช้งานได้ 100% เปลี่ยนการตั้งค่าง่าย ๆ

ตัวเลือก 1 ชุดขีด จำกัด (มันจะไม่ทำงานส่วนใหญ่)

user@ubuntu:~$ ulimit -n 65535

ตรวจสอบขีด จำกัด ที่มี

user@ubuntu:~$ ulimit -n
1024

ตัวเลือก 2 เพื่อเพิ่มขีด จำกัด ที่มีให้พูด 65535

user@ubuntu:~$ sudo nano /etc/sysctl.conf

เพิ่มบรรทัดต่อไปนี้

fs.file-max = 65535

รันสิ่งนี้เพื่อรีเฟรชด้วย config ใหม่

user@ubuntu:~$ sudo sysctl -p

แก้ไขไฟล์ต่อไปนี้

user@ubuntu:~$ sudo vim /etc/security/limits.conf

เพิ่มบรรทัดต่อไปนี้

root soft     nproc          65535    
root hard     nproc          65535   
root soft     nofile         65535   
root hard     nofile         65535

แก้ไขไฟล์ต่อไปนี้

user@ubuntu:~$ sudo vim /etc/pam.d/common-session

เพิ่มบรรทัดนี้

session required pam_limits.so

ออกจากระบบและเข้าสู่ระบบและลองคำสั่งต่อไปนี้

user@ubuntu:~$ ulimit -n
65535

ตัวเลือก 3 เพียงเพิ่มบรรทัดด้านล่างใน

DefaultLimitNOFILE=65535

ถึง /etc/systemd/system.conf และ /etc/systemd/user.conf

ด้วยปี่สก็อตคุณเพียงแค่ต้องเปลี่ยน

FS.readFile(filename, onRealRead);

=>

var bagpipe = new Bagpipe(10);

bagpipe.push(FS.readFile, filename, onRealRead))

ปี่สก็อตช่วยคุณ จำกัด การขนาน รายละเอียดเพิ่มเติม: https://github.com/JacksonTian/bagpipe

มีปัญหาเดียวกันเมื่อรันคำสั่งnodemonดังนั้นฉันจึงลดชื่อของไฟล์ที่เปิดในข้อความประเสริฐและข้อผิดพลาดหายไป

สร้างคำตอบของ @ blak3r ต่อไปนี้เป็นข้อมูลย่อเล็กน้อยที่ฉันใช้ในกรณีที่ช่วยวินิจฉัยอื่น ๆ :

หากคุณกำลังพยายามที่จะดีบักสคริปต์ Node.js ที่ไม่มีตัวอธิบายไฟล์ที่นี่เป็นบรรทัดที่จะให้ผลลัพธ์ของlsofกระบวนการโหนดที่คุณใช้:

openFiles = child_process.execSync(`lsof -p ${process.pid}`);

สิ่งนี้จะเรียกใช้การlsofกรองแบบซิงโครนัสโดยกระบวนการ Node.js ที่รันอยู่ในปัจจุบันและส่งคืนผลลัพธ์ผ่านบัฟเฟอร์

จากนั้นใช้console.log(openFiles.toString())เพื่อแปลงบัฟเฟอร์เป็นสตริงและบันทึกผลลัพธ์

cwaitเป็นโซลูชันทั่วไปสำหรับ จำกัด การประมวลผลฟังก์ชันที่ส่งคืนสัญญา

ในกรณีของคุณรหัสอาจเป็นดังนี้:

var Promise = require('bluebird');
var cwait = require('cwait');

// Allow max. 10 concurrent file reads.
var queue = new cwait.TaskQueue(Promise, 10);
var read = queue.wrap(Promise.promisify(batchingReadFile));

Promise.map(files, function(filename) {
    console.log(filename);
    return(read(filename));
})

สำหรับnodemonผู้ใช้: เพียงแค่ใช้ละเลยธงในการแก้ปัญหา

ตัวอย่าง:

nodemon app.js --ignore node_modules/ --ignore data/

fs-extraใช้ล่าสุด

ฉันมีปัญหานั้นในUbuntu(16 และ 18) ที่มีพื้นที่ไฟล์ / ซ็อกเก็ต - อธิบายมาก (นับด้วยlsof |wc -l) มือสองรุ่นfs-extra 8.1.0หลังจากอัปเดต9.0.0เป็น "ข้อผิดพลาด: EMFILE ไฟล์ที่เปิดมากเกินไป" หายไป

ฉันประสบปัญหาที่หลากหลายเกี่ยวกับระบบปฏิบัติการที่หลากหลายด้วยระบบการจัดการโหนด เห็นได้ชัดว่าระบบไฟล์ไม่น่ารำคาญ

ฉันมีปัญหานี้และฉันแก้ไขได้ด้วยการวิ่งnpm updateและใช้งานได้

ในบางกรณีคุณอาจต้องลบ node_modules rm -rf node_modules/

ฉันติดตั้ง watchman เปลี่ยนขีด จำกัด เป็นต้นและมันไม่ทำงานใน Gulp

การรีสตาร์ท iterm2 ช่วยได้จริง