在Linux系统中，查看socket被占用情况通常意味着检查网络端口的使用情况。你可以使用多种命令来完成这个任务。以下是一些常用的命令：

1. netstat 命令 netstat 是一个非常强大的工具，它可以显示网络连接、路由表、接口统计等信息。

   查看所有端口：

   netstat -tulnap
   

   参数说明：

   • -t 仅显示TCP连接
   • -u 仅显示UDP连接
   • -l 仅显示监听状态的套接字
   • -n 显示IP地址而不是解析的主机名
   • -a 显示所有套接字（默认和监听）
   • -p 显示进程ID和程序名称

2. ss 命令 ss 是一个类似于netstat的工具，但更快速且更详细一些。

   同样查看所有端口：

   ss -tulnap
   

   参数与netstat相同。

3. lsof 命令 lsof 可以列出打开的文件，由于在Unix和Linux中一切皆文件，网络连接也被视为文件。

   查看特定端口（例如80端口）：

   lsof -i :80
   

4. fuser 命令 fuser 可以显示使用某个文件或套接字的所有进程。

   查看特定端口（例如80端口）：

   fuser 80/tcp
   

请注意，某些命令可能需要以root用户权限运行才能显示详细信息。如果上述命令不可用，你可能需要先安装它们或者使用sudo来提升权限。

如果您想要统计监听状态的socket数量，可以结合使用前面提到的命令和wc (word count) 命令来实现。wc 可以用来统计行数、单词数或字节数。

例如，使用netstat命令：

netstat -tuln | grep '^tcp' | wc -l

这个命令会显示所有处于监听状态 (-l) 的TCP端口 (-t) 的数量。grep '^tcp' 用于筛选出所有以“tcp”开头的行，代表TCP协议的监听端口，然后wc -l 统计这些行的数量。

同样的，你可以使用ss命令：

ss -tuln | grep 'LISTEN' | wc -l

这里，ss -tuln 显示所有TCP (-t) 和UDP (-u) 处于监听状态的端口，grep 'LISTEN' 过滤出处于监听状态的端口，最后通过wc -l 统计数量。

请注意，具体参数可能因Linux发行版及其版本而异。另外，由于LISTEN 是一个具体的状态描述，所以它在grep中是区分大小写的。如果你不确定，可以使用grep -i 'listen' 进行不区分大小写的搜索。

如果你想查看所有已建立连接的socket数量，可以稍微修改上述命令，使用不同的过滤条件。

对于UDP连接，由于它们是无连接的，通常你只能统计监听状态的UDP端口数量，而不是已经建立连接的数量。

lsof -i :80 | wc -l 命令显示监听在端口80上的所有连接的数量（包括TCP和UDP，但是对于HTTP服务来说几乎都是TCP）。这个数字包括了所有处于不同状态的连接，包括正在监听、已经建立的连接以及可能处于等待关闭状态的连接。

是否认为“876”这个数字多取决于几个因素：

1. 服务器的规模和用途：如果您的服务器是一个大型公共Web服务器，那么同时存在876个连接可能是正常的。对于高流量网站，这个数字甚至可能更高。

2. 预期的流量量：如果你的网站通常访问量不大，那么突然出现876个连接可能意味着非正常流量，比如被网络爬虫大量访问或者遭受到了某种形式的拒绝服务攻击(DoS)。

3. 资源的限制：如果你的服务器资源有限（如CPU、内存、带宽），那么876个连接可能会对服务器性能产生影响。

4. 服务器配置和优化：有些应用程序和服务被配置为可以处理成千上万的并发连接，而有的则没有做这样的优化。

5. 连接的持续时间：如果这些连接是短暂的，那么可能只是正常的流量高峰。如果这些连接长时间不关闭，可能表明有问题，例如慢速攻击。

6. 时间点：高峰时段（例如促销活动或新闻事件）可能导致流量增加，并且相应地增加了连接数。

总之，“多”或者“少”需要根据您的特定情况来判断。如果你觉得这个数字异常高，你可能需要进一步分析这些连接的来源和性质，以及他们对服务器的影响。如果这些连接影响了服务器的性能或者可用性，那么就需要采取措施来管理这些连接，比如通过防火墙规则、反向代理服务器、负载均衡器等技术手段。

Nginx 报告 "Too many open files" 错误表明 Nginx 已达到其允许打开的文件描述符的最大数量。在 Linux 系统中，网络连接、打开的文件和套接字都是使用文件描述符来管理的。当达到系统限制或用户进程限制时，你将无法创建新的连接或打开新的文件。

要解决这个问题，你可以采取以下步骤：

1. 检查当前的文件描述符限制： 使用 ulimit -n 命令可以查看当前 shell 会话的文件描述符限制。

2. 增加文件描述符限制： 可以临时或永久性地提高文件描述符的限制。

   • 临时提升： 在当前 shell 会话中执行 ulimit -n <新的限制>，例如 ulimit -n 2048。

   • 永久提升： 对于永久更改，需要编辑 /etc/security/limits.conf 文件，并添加如下行：

     * soft nofile 4096
     * hard nofile 10000
     

     上面这两行分别设置了所有用户的软限制 (软限制是内核强制的最大值) 和硬限制 (用户可以为自己设置的最高值)。

3. 为 Nginx 配置特定的文件描述符限制： 如果只想对 Nginx 进程调整文件描述符限制，可以在 Nginx 启动脚本中设置 worker_rlimit_nofile 参数。在 Nginx 的配置文件（通常是 /etc/nginx/nginx.conf）中，你可以设置：

   worker_processes auto;
   worker_rlimit_nofile 10000;
   

   这样会为每个 worker 进程设置一个更高的文件描述符限制。

4. 优化 Nginx 配置： 有时候错误可能是由于 Nginx 配置不当导致的。比如过多的 keep-alive 连接可以通过减少 keepalive_timeout 来优化。

5. 检查并优化服务器代码： 如果你的应用程序或后端服务没有正确关闭不再需要的连接，这也会导致文件描述符耗尽。确保你的应用逻辑包括适当的清理步骤。

6. 重启 Nginx： 在进行以上更改后，需要重启 Nginx 使配置生效：

   sudo systemctl restart nginx
   

   或者如果你不使用 systemd：

   sudo service nginx restart
   

7. 监控和调试： 持续监控 Nginx 的日志和性能，以及使用 lsof 和 netstat 等工具定期检查打开的文件描述符。这有助于防止将来发生类似问题。

请注意，增加文件描述符限制可能会影响系统资源和安全性，因此请根据服务器的规格和需求谨慎操作。如果你不确定，请咨询系统管理员或专业人士。

如果您的系统上 ulimit -n 的输出是 370000，这意味着单个用户可以打开的文件描述符数量限制已经设置到了一个非常高的值。因此，对于大多数应用程序来说，这个限制应该是足够的。

既然 Nginx 还是报告 "Too many open files" 错误，这可能表明实际运行中的 Nginx 进程没有使用到这个提高后的限制。在多数情况下，服务和守护进程（例如 Nginx）不会从 shell 会话继承这些限制，特别是当它们作为服务启动时。

接下来的步骤可能有：

1. 检查 Nginx 使用的文件描述符限制： 可以通过查看 /proc/<nginx_pid>/limits 来检查正在运行的 Nginx 主进程的实际文件描述符限制，其中 <nginx_pid> 是 Nginx 主进程的 PID。例如：

   cat /proc/$(pgrep -u root nginx | head -n 1)/limits
   

2. 调整 Nginx 配置： 在 Nginx 配置文件中设置 worker_rlimit_nofile 参数来确保每个工作进程的限制被提高。这需要在 Nginx 主配置文件的 events 块外面进行设置。

3. 检查所有相关的服务： 如果 Nginx 是以反向代理的方式运行，并将请求传递给其他服务（如某个后端服务器或应用程序），那么也可能需要检查并提升这些服务的文件描述符限制。

4. 审查操作系统级别的限制： 尽管 ulimit -n 显示了很高的限制，但还应检查是否有其他系统级别限制影响 Nginx。这包括 /etc/security/limits.conf 中的设置，以及系统对 PID 的限制等。

5. 重启 Nginx： 每次更改 ulimit 或者其他相关配置之后，确保重新启动 Nginx 以应用新的设置。

6. 检查日志文件： 持续监控 Nginx 的错误日志文件，并分析产生大量打开文件需求的原因，比如无法关闭的连接，或者日志文件本身就占据了太多的文件描述符。

7. 使用专业工具进行分析： 可能需要使用一些更高级的工具来分析文件描述符的使用情况，比如 lsof 和 strace 等。

8. 咨询专家： 如果问题依旧无法解决，考虑寻求专业技术人员的帮助。可能需要对你的系统架构、Nginx 配置以及应用程序逻辑进行详细的分析。

请记住，处理此类问题通常需要系统级别的调试和优化。如果你不熟悉 Linux 系统管理，建议在系统管理员的指导下进行这些更改。

根据您提供的输出，Nginx 主进程对于打开文件的软限制是 1024，硬限制是 4096。这意味着即使系统的全局设置允许每个用户打开多达 370000 个文件描述符，Nginx 进程在未经调整的情况下仍然受到较低限制的约束。

要解决这个问题，您需要增加 Nginx 进程的文件描述符限制。这可以通过以下几种方式来实现：

1. 直接修改 Nginx 配置： 在 /etc/nginx/nginx.conf 中为 Nginx 工作进程设置 worker_rlimit_nofile 参数。例如：

   worker_rlimit_nofile 8192;
   

   这会设置软限制和硬限制为相同的值（这里是 8192）。

2. 调整服务或系统启动脚本： 如果 Nginx 是通过系统服务管理器（如 systemd）启动的，您可能需要编辑其服务单元文件。例如，对于 systemd，您可以创建一个覆盖文件：

   systemctl edit nginx.service
   

   并添加以下内容：

   [Service]
   LimitNOFILE=8192
   

   确保替换 8192 为您希望设置的新限制值。

3. 修改系统限制文件： 对系统文件 /etc/security/limits.conf 进行修改可能不会影响以 root 用户身份作为服务启动的 Nginx 进程，因为这些限制通常适用于登录会话。然而，确认这一点也是一个好主意。

完成这些更改后，您需要重启 Nginx 以应用新的限制：

sudo systemctl restart nginx

或者如果您不使用 systemd，使用：

sudo service nginx restart

确保您选择的新文件描述符限制既足够高以避免 "Too many open files" 错误，又能确保系统稳定性和安全性。考虑到您之前设置了很高的系统级 ulimit -n 值，您可以将 Nginx 的 LimitNOFILE 或 worker_rlimit_nofile 设置得更高，但确保它在服务器资源允许的范围内。

在 Nginx 配置文件中设置 worker_rlimit_nofile 参数的正确位置是在全局配置区域，这通常位于配置文件的顶部。这个指令应该放在 events 块之外，但在 http 块之前。下面是一个例子：

打开 Nginx 的主配置文件，通常是 /etc/nginx/nginx.conf：

sudo nano /etc/nginx/nginx.conf

然后，在文件的顶部找到或添加 worker_rlimit_nofile 指令。您的配置可能看起来像这样：

# 用户与工作进程数。
user nginx;
worker_processes auto;

# 允许每个工作进程打开的最大文件描述符数量。
worker_rlimit_nofile 8192;

# 错误日志的路径和日志级别。
error_log /var/log/nginx/error.log warn;

# pid指令通常接着出现。
pid /var/run/nginx.pid;

# 事件块开始。
events {
    worker_connections 1024;
    # 其他事件相关的设置...
}

# HTTP 块开始。
http {
    # 各种 http 全局配置...
    # 包括 MIME 类型，日志格式等。

    # 服务器块定义...
    server {
        listen       80;
        server_name  localhost;

        # 路径、位置等配置项...
    }

    # 更多服务器块定义...
}

# 其他可能的邮件或流服务器配置...

确保 Nginx 配置文件语法没有错误，可以运行以下命令来检查 Nginx 配置文件的语法是否正确：

sudo nginx -t

如果输出表明“syntax is ok”并且“test is successful”，则可以安全地重启 Nginx：

sudo systemctl reload nginx

或者如果您不使用 systemd，使用：

sudo service nginx reload

请注意，使用 reload 代替 restart 以优雅地重新加载配置而无需完全停止服务。

根据您提供的 Nginx 配置文件摘录，要设置 worker_rlimit_nofile 参数，您只需要在 worker_processes 指令之后添加该指令。修改后的配置应该如下所示：

user nginx;
worker_processes 1;

# 设置每个 worker 进程允许打开的最大文件描述符数量
worker_rlimit_nofile 8192;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

# ... 其他配置（如 http 块） ...

这里我将 worker_rlimit_nofile 的值设置为 8192，但您可以根据实际需要选择合适的值。

一旦您更新了 Nginx 的配置文件，保存并退出编辑器。然后检查配置是否正确，使用以下命令：

sudo nginx -t

如果检查显示配置是正确的，那么您可以重新加载或重启 Nginx 使更改生效：

sudo systemctl reload nginx

或者，如果您不使用 systemd：

sudo service nginx reload

确保在进行任何生产环境的修改之前备份您的配置文件。这样做可以帮助您快速恢复原始状态，以防新的配置引发问题。