Gitlab 超过 numtcpsock beancounter 限制(OpenVZ)
Gitlab exceeds numtcpsock beancounter limit (OpenVZ)
找出 Gitlab 问题出在哪里的最佳方法是什么(仅在 Ubuntu Plesk Onyx 服务器上使用的应用程序),每次我查找 /proc/user_beancounters
时 numtcpsock 值都打开正常状态(< 100) 有时某些 Gitlab 进程似乎超过 numtcpsock 限制 (3000) 超过 2300 次,因此虚拟服务器 (OpenVZ) 崩溃?
我已经在 /etc/gitlab/gitlab.rb
:
上限制了 redis 和 postgresql 连接
postgresql['shared_buffers'] = "30MB"
postgresql['max_connections'] = 100
redis['maxclients'] = "500"
redis['tcp_timeout'] = "20"
redis['tcp_keepalive'] = "10"
sudo gitlab-ctl reconfigure && sudo gitlab-ctl restart
但这似乎并不能防止服务器崩溃。我需要一种方法来解决这个问题。你有什么想法吗?
编辑:
服务器仅被大约 3-5 人使用 netstat -pnt | wc -l
return 大约 49 个 tcp 连接。 cat /proc/user_beancounters
numtcpsock
目前33人。除了我在本地 ip 上侦听的 ssh 连接外,所有这些都是。
这里有一些例子:
tcp 0 0 127.0.0.1:47280 127.0.0.1:9168 TIME_WAIT -
tcp 0 0 127.0.0.1:9229 127.0.0.1:34810 TIME_WAIT -
tcp 0 0 127.0.0.1:9100 127.0.0.1:45758 TIME_WAIT -
tcp 0 0 127.0.0.1:56264 127.0.0.1:8082 TIME_WAIT -
tcp 0 0 127.0.0.1:9090 127.0.0.1:43670 TIME_WAIT -
tcp 0 0 127.0.0.1:9121 127.0.0.1:41636 TIME_WAIT -
tcp 0 0 127.0.0.1:9236 127.0.0.1:42842 TIME_WAIT -
tcp 0 0 127.0.0.1:9090 127.0.0.1:43926 TIME_WAIT -
tcp 0 0 127.0.0.1:9090 127.0.0.1:44538 TIME_WAIT -
防火墙和带有许多监狱(ssh 等)的 fail2ban 在服务器上也处于活动状态。
numtcpsock 值是到您的 openvz 虚拟服务器的 TCP 连接数。超过该值不会使您的服务器崩溃,但会阻止创建任何新的 TCP 套接字,如果您只能远程访问虚拟服务器,您将被有效地锁定。
我不确定 gitlab 如何达到 3000 的最大 numtcpsock 限制,除非你有几百个并发用户。如果是这种情况,您只需要升级您的 numtcpsock 最大限制。
如果您有 public IP 地址,更可能导致您的 numtcpsock 问题的原因是与 SSH、HTTP 或黑客喜欢探测的其他一些流行的 TCP 服务的过度连接。
当您遇到 numtcpsock 问题时,您需要检查 netstat -pnt
的输出以查看您的服务器上打开了哪些 TCP 连接。该输出将显示谁已连接以及连接到哪个端口。
首先要防止过多的 TCP 连接,如果问题确实出在 gitlab 上,请确保它的配置方式不会占用所有可用连接。如果问题是由您不希望的外部连接引起的,请确保您有一些合理的防火墙规则或像 fail2ban 这样的工具来为您完成。
编辑:答案中使用的 netstat 标志的说明(摘自 Ubuntu 16.04 中的 netstat 手册页)
-p, --program: 显示每个套接字所属的PID和程序
-l, --listening: 只显示监听套接字
-n, --numeric: 显示数字地址而不是试图确定符号主机、端口或用户名
-t, --tcp
找出 Gitlab 问题出在哪里的最佳方法是什么(仅在 Ubuntu Plesk Onyx 服务器上使用的应用程序),每次我查找 /proc/user_beancounters
时 numtcpsock 值都打开正常状态(< 100) 有时某些 Gitlab 进程似乎超过 numtcpsock 限制 (3000) 超过 2300 次,因此虚拟服务器 (OpenVZ) 崩溃?
我已经在 /etc/gitlab/gitlab.rb
:
postgresql['shared_buffers'] = "30MB"
postgresql['max_connections'] = 100
redis['maxclients'] = "500"
redis['tcp_timeout'] = "20"
redis['tcp_keepalive'] = "10"
sudo gitlab-ctl reconfigure && sudo gitlab-ctl restart
但这似乎并不能防止服务器崩溃。我需要一种方法来解决这个问题。你有什么想法吗?
编辑:
服务器仅被大约 3-5 人使用 netstat -pnt | wc -l
return 大约 49 个 tcp 连接。 cat /proc/user_beancounters
numtcpsock
目前33人。除了我在本地 ip 上侦听的 ssh 连接外,所有这些都是。
这里有一些例子:
tcp 0 0 127.0.0.1:47280 127.0.0.1:9168 TIME_WAIT -
tcp 0 0 127.0.0.1:9229 127.0.0.1:34810 TIME_WAIT -
tcp 0 0 127.0.0.1:9100 127.0.0.1:45758 TIME_WAIT -
tcp 0 0 127.0.0.1:56264 127.0.0.1:8082 TIME_WAIT -
tcp 0 0 127.0.0.1:9090 127.0.0.1:43670 TIME_WAIT -
tcp 0 0 127.0.0.1:9121 127.0.0.1:41636 TIME_WAIT -
tcp 0 0 127.0.0.1:9236 127.0.0.1:42842 TIME_WAIT -
tcp 0 0 127.0.0.1:9090 127.0.0.1:43926 TIME_WAIT -
tcp 0 0 127.0.0.1:9090 127.0.0.1:44538 TIME_WAIT -
防火墙和带有许多监狱(ssh 等)的 fail2ban 在服务器上也处于活动状态。
numtcpsock 值是到您的 openvz 虚拟服务器的 TCP 连接数。超过该值不会使您的服务器崩溃,但会阻止创建任何新的 TCP 套接字,如果您只能远程访问虚拟服务器,您将被有效地锁定。
我不确定 gitlab 如何达到 3000 的最大 numtcpsock 限制,除非你有几百个并发用户。如果是这种情况,您只需要升级您的 numtcpsock 最大限制。
如果您有 public IP 地址,更可能导致您的 numtcpsock 问题的原因是与 SSH、HTTP 或黑客喜欢探测的其他一些流行的 TCP 服务的过度连接。
当您遇到 numtcpsock 问题时,您需要检查 netstat -pnt
的输出以查看您的服务器上打开了哪些 TCP 连接。该输出将显示谁已连接以及连接到哪个端口。
首先要防止过多的 TCP 连接,如果问题确实出在 gitlab 上,请确保它的配置方式不会占用所有可用连接。如果问题是由您不希望的外部连接引起的,请确保您有一些合理的防火墙规则或像 fail2ban 这样的工具来为您完成。
编辑:答案中使用的 netstat 标志的说明(摘自 Ubuntu 16.04 中的 netstat 手册页)
-p, --program: 显示每个套接字所属的PID和程序
-l, --listening: 只显示监听套接字
-n, --numeric: 显示数字地址而不是试图确定符号主机、端口或用户名
-t, --tcp