ArangoDB 无法连接答案

【问题标题】：ArangoDB Could not connectArangoDB 无法连接
【发布时间】：2015-09-13 13:39:34
【问题描述】：

arangod 运行了一段时间没有任何问题，但在某些时候无法建立更多连接。然后 aranogsh 显示以下错误消息：

错误消息'Could not connect to 'tcp://127.0.0.1:8529''connect() failed with #99 - Cannot assign requested address''

在日志文件中arangod还是写了更多的trace信息。

重新启动araogd后，它再次运行没有问题，直到问题突然再次出现。

为什么会这样？

【问题讨论】：

您能否提供更多上下文，例如您在哪个平台上使用哪个版本的 ArangoDB，以及有关当时无法建立进一步连接的工作负载的一些信息。此外，在无法建立连接后，arangod 会在日志文件中记录哪些跟踪信息？当无法建立进一步的连接时，您能否确认 arangod 进程仍在运行？
我做了一些分析，发现站立时arangod总是在FIN_WAIT2（netstat）上挂一个端口。目前运行的系统版本为 2.6.7 关于 Node.js 和 Java 客户端的观点。
当时系统是否有可能耗尽了临时端口？例如，当您为每个请求建立新连接时，操作系统将为每个连接分配一个新的临时端口。如果您在短时间内建立大量新连接，系统可能会耗尽临时端口。如果是这种情况，问题应该会在一段时间后自动消失，具体取决于 TCP 堆栈配置。你能检查一下你是否总是在建立新的连接，或者你是否使用了某种可以重用现有连接的连接池？
您能否检查一下您是否使用 HTTP/1.1 和 Keep-Alive 进行连接？使用 HTTP/1.1 和 Keep-Alive 将是有益的，至少与 HTTP 1.0 和不使用 Keep-Alive 相比是这样。当然，在客户端重用连接以从 Keep-Alive 中受益是有意义的。
连接使用 Keep-Alive 1000 毫秒。我计算了 netstat 上的开放端口，当挂起时，它在 20 到 100 之间。操作系统是 debian。

标签： arangodb

【解决方案1】：

由于这个问题在某种程度上得到了时间的回答，因此我将使用这个答案来详细说明如何深入研究这种情况，并对要查看的操作系统参数进行有价值的分析。我将基于 linux 目标。

首先，我们需要了解当前以 root 用户身份使用 netstat 工具的情况（我们只关心 tcp 端口）：

netstat -alnpt
Proto Recv-Q Send-Q Local Address     Foreign Address    State       PID/Program name
...
tcp        0      0 0.0.0.0:8529      0.0.0.0:*          LISTEN      3478/arangod
tcp        0      0 127.0.0.1:45218   127.0.0.1:8529     ESTABLISHED 6902/arangosh
tcp        1      0 127.0.0.1:46985   127.0.0.1:8529     CLOSE_WAIT  485/arangosh

我们看到了 3 个可能的价值组的概览：

LISTEN：这些是为远程端提供 tcp 服务的守护进程，在本例中是 arangod 进程及其服务器套接字。它在系统的所有可用 ipv4 地址 (0.0.0.0) 上绑定端口 8529，并接受来自任何远程位置的连接 (0.0.0.0:*)
ESTABLISHED：这是arangosh和arangod之间的活动tcp连接； Arangosh 的客户端端口 (45218) 在更高范围内连接 arangod 端口 8529。
CLOSE_WAIT：这是一个处于终止状态的连接。拥有它们是正常的。操作系统的 TCP 堆栈将它们保留一段时间，以便知道在哪里对可能已发送但未按时到达的杂散 TCP 包进行分类。

如您所见，TCP 端口是 16 位无符号整数，范围从 0 到 65535。服务器套接字从低端开始，大多数操作系统要求进程以 root 身份运行以绑定低于 1024 的端口。客户端套接字从高端开始，范围一直到客户端的指定限制。由于多个客户端可以连接一台服务器，而服务器端口范围似乎很窄，通常是客户端端口磨损。如果客户端频繁关闭并重新打开连接，您可能会看到许多处于CLOSE_WAIT 状态的套接字，正如网络上的许多讨论所暗示的那样，这些是您的系统最终耗尽资源的症状。一般来说，这个问题的解决方案是通过keepalive功能重用现有的连接。

正如the solaris ndd command 详细解释了它可以修改哪些参数并在solaris 内核中产生哪些后果，其中解释的术语对tcp 套接字相当通用，并且可能以其他方式在许多其他操作系统上找到；在 linux 中——我们在这里关注——通过/proc/sys/net-filesystem。

一些有价值的开关有：

ipv4/ip_local_port_range 这是本地套接字的范围。您可以尝试缩小范围，并使用arangob --keep-alive false 来探索如果您的系统用完这些会发生什么。
time wait（通常缩写为tw）是控制TCP-Stack 应该如何处理处于CLOSE_WAIT 状态的已关闭套接字的部分。 Linux 内核可以在这里发挥作用——它可以立即将处于该状态的连接重新用于新连接。文森特·伯纳特explains very nicely which screws to turn and what the differnt parameters in the kernel mean.

因此，一旦您决定更改 /proc 中的一些值以便您的主机更好地适应给定的情况，您需要让它们重新启动持久 - 因为 /proc 是易变的，并且不会在重新启动时记住值。

因此，大多数 linux 系统都提供/etc/sysctl.[d|conf] 文件；它将 proc 文件系统中的斜线映射到点，因此/proc/sys/net/ipv4/tcp_tw_reuse 将转换为net.ipv4.tcp_tw_reuse。

【讨论】：