Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

fs.writeFile hangs on high load (no error on v.0.6.6) #fs #2529

Closed
mrutid opened this issue Jan 13, 2012 · 5 comments
Closed

fs.writeFile hangs on high load (no error on v.0.6.6) #fs #2529

mrutid opened this issue Jan 13, 2012 · 5 comments
Labels

Comments

@mrutid
Copy link

mrutid commented Jan 13, 2012

We are trying to serve as much requests as possible, and write one file per request. With small payload works fine, but on high payload scenarios while the synchronous version still working fine, the asynchronous version (fs.writeFile) hangs. Node stops serving requests and leave most of the files with 0-size (most of them neither get created).

There is no error in v0.6.6

In v.0.4.7 we got:

{ stack: [Getter/Setter], arguments: undefined, type: undefined, message: 'EMFILE, Too many open files \'aw_1031\'', errno: 24, code: 'EMFILE', path: 'aw_1031' }

Same behaviour in Ubuntu(VM) and Mac Osx.

This is the example script we are currently running with:

ab -n 30000 -c 500 http://HOST:8000/

var http = require('http');
var fs = require('fs');
var util = require ('util');
var i=0;

function writeALot(req, res){
    fs.writeFile("filetest"+i, "Just a try: "+i,
        function(err){
            if(err)    console.log(util.inspect(err));
        });
    i++;
    res.writeHead(200);
    res.end();
}
http.createServer(writeALot).listen(8000);

How can we manage the max number of concurrent fd? Any advice?

Thanks in advance.

@bnoordhuis
Copy link
Member

Confirmed. It's a libuv bug and we're possibly also exhausting the libeio task queue.

You can avoid the worst of it by rewriting the request logic:

function writeALot(req, res){
    res.writeHead(200);
    fs.writeFile("filetest"+i, "Just a try: "+i,
        function(err){
            res.end();
            if(err)    console.log(util.inspect(err));
        });
    i++;
}

@mrutid
Copy link
Author

mrutid commented Jan 13, 2012

Thanks!

The problem with the server logic is that is should work that way. Answering before processing (if it is possible), it's some kind of oneway relaying. If it is not possible we will slow down things a little bit.

Is it an already reported bug? any ticket to follow?

Thanks again : )

@bnoordhuis
Copy link
Member

Is it an already reported bug?

It is now. :)

Set ulimit -n to some high number until this issue is resolved, that should mitigate it.

@mrutid
Copy link
Author

mrutid commented Jan 13, 2012

I will try with https://github.com/isaacs/node-graceful-fs

If don't we will manage it "by hand".

+1 to node community

@bnoordhuis
Copy link
Member

Continues in joyent/libuv#315.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants