EADDRNOTAVAIL在Elasticsearch高负载下

Question

我正在使用es模块与elasticsearch服务器通信。

当我进行大量插入时，在大约10000个查询后出现错误：

Trace: { [Error: connect EADDRNOTAVAIL]
  code: 'EADDRNOTAVAIL',
  errno: 'EADDRNOTAVAIL',
  syscall: 'connect' }

更新：

OS X 10.9.3

❯ elasticsearch -v
Version: 1.2.0, Build: c82387f/2014-05-22T12:49:13Z, JVM: 1.7.0_45

❯ node -v
v0.10.26

更新2

根据Alex的建议：

❯ ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       709
-n: file descriptors                256

❯ sudo sysctl -w kern.maxfilesperproc=20000
Password:
kern.maxfilesperproc: 10240 -> 20000

但是结果相同：大约进行10000次操作后，它失败并显示相同的错误。

更新3

我运行命令netstat -an | grep -e tcp -e udp | wc -l netstat -an | grep -e tcp -e udp | wc -l netstat -an | grep -e tcp -e udp | wc -l在我的脚本执行期间持续约30秒：

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     109

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     110

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     110

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     110

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     114

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     114

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     114

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     114

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     114

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     113

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     111

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     110

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     110

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     112

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     110

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     110

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     108

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     108

[user@mac] ~  
❯  netstat -an | grep -e tcp -e udp | wc -l
     108

[user@mac] ~  
❯ 

Answer 1

我猜想node.js插入请求是在异步模式下处理的，因此它创建了更多连接，elasticsearch可以处理。 您能否使用一些延迟或连接池（不确定在node.js中是如何完成的）？

更新

也使用ulimit -a检查打开处理程序的最大数量，并找到一种方法来使用此帖子增加OSX在OSX上每个进程的最大打开文件处理数量（以及如何增加）

Answer 2

如果这些插入是从脚本和某些数据源运行的，那么我不建议对每个条目进行插入。 相反，我建议您使用批量上传API。 您正在使用的节点库对此提供支持，并在此处进行了说明 。