跳转至

排查网页打不开问题

第一步

1,通过终端ping网页域名，是否能通，如果不通，检查域名地址是否正确，否则检查DNS

第二步

2,浏览器打开开发者模式，查看网页返回的http状态码，根据不同的HTTP状态进行排查

HTTP状态码是服务器用来响应客户端请求的标准数字代码。

不同的状态码表示不同的情况，可以大致分为五个类别：

1xx - 信息性状态码 (Informational)：表示接收的请求正在处理。

这类状态码通常是正常的，不需要特别的排查。

  • 100 Continue (继续)
  • 101 Switching Protocols (切换协议)

2xx - 成功状态码 (Successful)：表示请求已成功被服务器接收、理解、并接受。

成功状态码通常意味着请求已成功处理。不需要特别排查。

  • 200 OK (成功)
  • 201 Created (已创建)
  • 202 Accepted (已接受)
  • 204 No Content (无内容)

3xx - 重定向状态码 (Redirection)：表示需要进一步操作以完成请求。

  • 301 Moved Permanently (永久移动) 检查服务器端的重定向设置。如果是意料之外的重定向，确认服务器配置或代码中的重定向逻辑。
  • 302 Found (找到) 检查服务器端的重定向设置。如果是意料之外的重定向，确认服务器配置或代码中的重定向逻辑。
  • 303 See Other (查看其他位置)
  • 304 Not Modified (未修改) 这通常是正常的，表示资源自上次请求以来未修改。检查缓存设置。
  • 307 Temporary Redirect (临时重定向)
  • 308 Permanent Redirect (永久重定向)

4xx - 客户端错误状态码 (Client Error)：表示请求包含语法错误或无法完成。

  • 400 Bad Request (错误请求) 检查请求是否正确。通常是请求格式错误。
  • 401 Unauthorized (未授权) 检查认证信息是否正确。
  • 403 Forbidden (禁止) 确认服务器端权限设置。
  • 404 Not Found (未找到) 检查请求的资源是否存在。
  • 405 Method Not Allowed (方法不允许) 确认是否使用了服务器不支持的HTTP方法。
  • 408 Request Timeout (请求超时) 检查网络问题或服务器性能问题。
  • 429 Too Many Requests (请求过多) 检查是否触发了服务器的限流措施，如有需要调整请求频率。

5xx - 服务器错误状态码 (Server Error)：表示服务器在处理请求的时候发生了错误。

  • 500 Internal Server Error (服务器内部错误) 检查服务器日志，确认代码、数据库、或配置中的问题。
  • 501 Not Implemented (未实现) 服务器不支持请求的功能。
  • 502 Bad Gateway (错误网关) 检查服务器与上游服务器的连接。
  • 503 Service Unavailable (服务不可用) 服务器可能超载或进行维护。检查服务器性能和配置。
  • 504 Gateway Timeout (网关超时) 类似于502，检查服务器与上游服务器的连接问题。

这些状态码是Web开发和网络诊断中的重要部分。

第三步

3,检查网页服务器状态，例如Nginx，Apache等

例如检查Nginx服务器是否正常运行，可以通过以下步骤进行：

检查Nginx服务状态：

在命令行输入 `sudo systemctl status nginx` 或 `service nginx status`
（取决于你的操作系统和服务管理器）。这会显示Nginx的运行状态。

检查端口监听：

使用 `netstat -tulpn | grep nginx` 或 `ss -tulpn | grep nginx` 
来确认Nginx是否正在监听正确的端口（通常是80和443端口）。

访问网站：

尝试在nginx服务器中输入你的服务器IP或绑定的域名，看是否能成功加载网页。
或者在nginx服务器上curl命令访问127.0.0.1+端口，看是否能成功加载网页

查看Nginx错误日志：

Nginx的错误日志通常位于 `/var/log/nginx/error.log`。
查看该文件可能会给出一些为什么Nginx无法正常运行的线索。

检查Nginx配置文件：

使用 `nginx -t` 命令来测试Nginx配置文件是否有语法错误。

或者使用 ps auxww | grep [进程号] 查看Nginx启动命令是否指定了配置文件

检查系统资源：

使用 `top` 或 `htop` 等命令来检查服务器的
CPU和内存使用情况，确保系统资源没有被耗尽。

一样的道理可以检查Apache。

第四步

4,检查开发环境状态，例如Java，Python，PHP等

例如检查Java：

jstat -gc [pid] 命令提供了Java堆内存中对象的垃圾收集和堆使用情况的信息。输出的每列数据代表不同的内存区域或统计信息。以下是典型输出的列和它们的含义：

1. S0C: Survivor space 0 capacity (KB) - 幸存区0的容量。
2. S1C: Survivor space 1 capacity (KB) - 幸存区1的容量。
3. S0U: Survivor space 0 utilization (KB) - 幸存区0的使用量。
4. S1U: Survivor space 1 utilization (KB) - 幸存区1的使用量。
5. EC: Eden space capacity (KB) - 伊甸园区的容量。
6. EU: Eden space utilization (KB) - 伊甸园区的使用量。
7. OC: Old space capacity (KB) - 老年代区的容量。
8. OU: Old space utilization (KB) - 老年代区的使用量。
9. MC: Metaspace capacity (KB) - 元空间的容量。
10. MU: Metaspace utilization (KB) - 元空间的使用量。
11. CCSC: Compressed Class Space Capacity (KB) - 压缩类空间的容量。
12. CCSU: Compressed Class Space Used (KB) - 压缩类空间的使用量。
13. YGC: Number of young generation GC events - 年轻代垃圾收集发生的次数。
14. YGCT: Young generation garbage collection time - 年轻代垃圾收集所用的时间。
15. FGC: Number of full GC events - 完全垃圾收集发生的次数。
16. FGCT: Full garbage collection time - 完全垃圾收集所用的时间。
17. GCT: Total garbage collection time - 垃圾收集所用的总时间。

通过分析这些数据，你可以获得JVM堆内存使用情况和垃圾收集活动的详细视图。这对于性能调优和诊断内存问题是非常有帮助的。

有一些通用的指标可以指示潜在的问题：

频繁的年轻代垃圾收集 (YGC)：

Note

如果YGC数值不断快速增加，可能表明年轻代空间太小或者程序在短时间内生成了大量的临时对象。

长时间的年轻代垃圾收集 (YGCT)：

Note

如果单次YGCT值较高，说明年轻代垃圾收集花费了太多时间，可能是由于堆大小不足或垃圾收集器设置不合理。

频繁的完全垃圾收集 (FGC)：

Note

FGC频繁增加可能表明老年代或永久代/元空间（取决于Java版本）容量不足，或者有大量对象长期存活。

长时间的完全垃圾收集 (FGCT)：

Note

高FGCT值表示完全垃圾收集占用了太多时间，可能是由于老年代空间太小、存在大量长生命周期的对象，或垃圾收集器设置不当。

高老年代使用量 (OU)：

Note

如果OU值持续接近OC值，表明老年代空间接近满载，可能导致频繁的完全垃圾收集。

高元空间使用量 (MU)：

Note

MU接近MC表明元空间使用量高，可能由于加载了大量类或内存泄漏。

总垃圾收集时间 (GCT)：

Note

如果GCT相对于应用运行时间过高，表明应用花费了大量时间在垃圾收集上。

识别这些异常情况后，可能需要对JVM的堆大小、垃圾收集器类型、垃圾收集策略等进行调整，或者检查应用代码以查找内存泄漏或不必要的对象创建。对于具体的调优策略，需要根据应用程序的具体情况和需求来定。

jstat -gcutil <pid> <interval> <count> 命令用于显示目标Java进程的垃圾收集（GC）统计信息，并按照设定的时间间隔重复显示指定次数。下面是该命令各部分的解释：

Note

  1. jstat：Java的统计监控工具。
  2. -gcutil：这是jstat的一个选项，用于显示目标Java进程的垃圾收集统计信息，包括堆区域的使用百分比等。
  3. <pid>：目标Java进程的进程ID。您需要替换为您想监控的Java进程的实际进程ID。
  4. <interval>：显示信息的时间间隔，单位为毫秒。这个参数是可选的，默认情况下只显示一次数据。
  5. <count>：该命令要重复执行的次数。这个参数也是可选的，如果未指定，jstat 将持续显示数据，直到被中断。

例如，如果您想查看进程ID为1234的Java进程的垃圾收集统计信息，每隔5000毫秒（即5秒）更新一次，总共更新10次，您可以使用以下命令：

jstat -gcutil 1234 5000 10

这个命令将每5秒显示一次进程ID为1234的Java进程的垃圾收集统计信息，共显示10次。

jstat -gcutil 1234 5000 10 这个命令的输出将展示进程ID为1234的Java应用的垃圾收集（GC）相关的信息，每5秒刷新一次，共刷新10次。每次刷新将展示类似以下的数据（具体数值会根据应用状态有所不同）：

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00  76.85  40.07  97.69  95.83   118    1.472    2      0.234    1.706
  0.00   0.00  80.37  41.07  97.69  95.83   118    1.472    2      0.234    1.706
  ...

这里是各列数据的意义：

  • S0 和 S1：幸存区（Survivor spaces）0和1的使用百分比。
  • E：伊甸园区（Eden space）的使用百分比。
  • O：老年代（Old generation）的使用百分比。
  • M：元数据区（Metaspace）的使用百分比。
  • CCS：压缩类空间（Compressed Class Space）的使用百分比。
  • YGC：年轻代垃圾收集（Young Generation Garbage Collection）发生的次数。
  • YGCT：年轻代垃圾收集所花费的时间（秒）。
  • FGC：完全垃圾收集（Full Garbage Collection）发生的次数。
  • FGCT：完全垃圾收集所花费的时间（秒）。
  • GCT：总垃圾收集时间（秒）。

这些数据对于理解和调优Java应用的内存和垃圾收集行为非常有帮助。

如果Java应用出现异常，jstat -gcutil 命令输出的数据可能会展示一些异常模式，比如：

频繁的年轻代垃圾收集（YGC）:

  • 说明：如果YGC发生的频率非常高，可能意味着伊甸园区（Eden space）太小或者应用产生了大量的短生命周期对象。
  • 举例：如果每几秒钟就有一次YGC，且YGCT（年轻代垃圾收集时间）相对较高，可能说明存在问题。

老年代（Old Generation）使用率持续增高:

  • 说明：如果老年代的使用率不断攀升且不下降，可能表明内存泄漏或老年代大小不足。
  • 举例：如果老年代的使用率（O列）逐渐接近100%且不见下降，可能是内存泄漏的迹象。

频繁的完全垃圾收集（FGC）:

  • 说明：频繁的FGC可能会导致系统停顿，影响性能。可能是由于老年代空间不足或内存泄漏造成的。
  • 举例：如果FGC的次数（FGC列）在短时间内迅速增加，且FGCT（完全垃圾收集时间）也在增加，可能会出现性能问题。

垃圾收集时间过长 :

  • 说明：如果垃圾收集所需的时间过长，可能会导致应用响应缓慢或停顿。
  • 举例：如果YGCT或FGCT的值异常高，意味着垃圾收集占用了大量时间，可能导致应用性能下降。

总之，通过监控jstat -gcutil命令的输出，可以识别出潜在的内存管理问题，如内存泄漏、不恰当的垃圾收集策略或内存分配不足等。然后可以根据这些信息进行调优或进一步调查。

第五步

5,检查操作系统

检查防火墙设置：

  • 确保防火墙没有阻止Nginx使用的端口，特别是HTTP (80) 和 HTTPS (443) 端口。 s 2.检查SELinux状态（如果适用）：

  • 在某些Linux发行版上，SELinux可能会限制Nginx的操作。可以通过 getenforce 查看其状态，并根据需要进行调整。

检查Nginx的访问日志：

  • 访问日志通常位于 /var/log/nginx/access.log。它可以提供访问者请求的详细信息，有助于识别潜在问题。

查看系统日志：

  • 有时系统日志（如 /var/log/syslog 或 /var/log/messages）也能提供服务器问题的线索。

后面遇到具体场景再具体补充