Amit Kumar Gupta
Amit Kumar Gupta

Reputation: 7413

Node crashes on multiple requests at same time

I wrote a npm package StubbyDB which is not able to perform good in case of load tests.

In summary: When a HTTP requests come -> it reads relevant file -> process file content -> response back to client.

I read contents from file asynchronously. When I run load test StubbyDB crashes with following message on console.

node: ../src/tcp_wrap.cc:61: static v8::Local<v8::Object> node::TCPWrap::Instantiate(node::Environment*, node::AsyncWrap*): Assertion `(instance.IsEmpty()) == (false)' failed.
Aborted (core dumped)

Since this is not the proper use case of asynchronous file read, as suggested in this ans, I changed the code to read file synchronously. It improved the performance a bit. But now it was aborting with following reason

node: ../deps/uv/src/unix/async.c:130: uv__async_io: Assertion `n == sizeof(val)' failed.

Since I had removed all aync call, I was not expecting it. But somehow I found that if I disable logging (using winston npm package for that) then this issue doesn't arise. So I disabled logging.

It improves more. But now it is crashing with Segmentation fault (core dumped). I have tried to rebuild npm multiple times. But still same issue. What can be the reason now?

Sometimes it crashes with

*** Error in `node': corrupted double-linked list: 0x0000000002e994f0 ***
Aborted (core dumped)

Upvotes: 0

Views: 1641

Answers (1)

Amit Kumar Gupta
Amit Kumar Gupta

Reputation: 7413

I solved 1st problem with 2 changes

  1. I converted all asynchronous calls to synchronous. Because asynchronous calls give advantage only if there is some code in the application which can run in parallel. Otherwise for each callbacks memory usage increase.

  2. I was having a feature of latency where I was using a npm library: desync, to block the call for specified period. Since I was using it in starting, all the variables which are created before, can not be garbage collected for that time. So I shifted this call in last and used setTimeout() for this. At this point NVM can easily find out which variables are not in reference so they can be easily garbage collected as setTimeout doesn't interrupt the execution and let thread go ahead.

For the second problem, I have switched off the logging while running the load tests. Since it is a 3rd party library, I din't analyse much.

Last problem was occurring because of memory leak. Initial 2 fixes solved it significantly. In addition, this time I took care that;

  • I stopped passing variables with big data to any callback.
  • I free theses variables as soon as their work is completed instead of using them in end of the application. So they can be garbage collected.

Upvotes: 2

Related Questions