vlambda博客
学习文章列表

执行以下步骤进行故障排除：

前面的屏幕截图显示了服务器正常工作的 ping 响应。这意味着在系统和网络方面没有来自用户端的问题。

一旦我们知道用户端没有问题，我们将进入应用程序的下一个级别，即 Web 服务器。现在，我们必须深入服务器以检查是否有任何问题。

Web 服务器问题通常与服务器负载、用户线程或安装问题有关。让我们看看如何解决这个问题。

如果我们在前面提到的组件中没有发现任何错误，那么我们可以断定 Web 服务器没有问题。

在基于 Java 的应用程序中，由于许多问题导致缓慢。其中一些是由于 JVM 内存、不正确的应用程序部署、不正确的 DB 配置等造成的。让我们讨论 Tomcat 7 的一些基本故障排除步骤：

如果telnet成功，那么可以验证以下流程：

有一些机会在应用程序中过度使用 JVM。要查看 JVM 实例的内存分配，您可以使用命令行实用程序 jmap。此命令随 JDK 1.6 提供。它是一个 Java 实用程序，它决定了 Tomcat 实例的整个内存分配。

[root@localhost logs]# jmap -heap "TOMCAT INSTANCE PID "

让我们讨论前面的命令是如何执行的。 jmap 命令在内部收集 JVM 内存详细信息， -heap 是告诉 jmap 收集并显示堆内存占用， TOMCAT INSTANCE PID 是进程所在的Tomcat实例的进程ID jmap< /code> 必须获取内存详细信息。

[root@localhost logs]# jmap -heap 10638

以下屏幕截图显示了前一个进程 ID 的 jmap 命令的输出：

ps -ef |grep "tomcat instance name " |awk -F" " '{print $2}'|head -1

jmap 命令存在于 JAVA_HOME/bin 中，如果您设置 JAVA _HOME/bin 在路径中，然后您可以从任何地方执行命令。

前面的实用程序提供了 JVM 内存的整个占用空间及其对 Tomcat 实例的分配。 JVM 内存由以下组件组成：

内存不足问题，例如 perm generation 和 max heap 是生产环境中非常常见的问题。检查内存以查看以前的任何组件是否使用超过 95%。如果是这样，那么我们必须增加相应的参数。

现在到了我们可以确定哪个 JVM 组件正在为 Tomcat 实例创建问题的地方。如果内存工作正常，那么是时候生成线程转储来钻取应用程序级问题了。

在企业环境中，由于应用程序的高内存需求，经常会遇到内存不足的问题，管理员必须调整 JVM。失败会导致 Tomcat 实例出现内存不足异常。

例外：

SEVERE: Servlet.service() for servlet jsp threw exception
java.lang.OutOfMemoryError: Java heap space

原因：

运行应用程序时可能经常出现此错误，这需要大量内存密集型资源。因此，它会导致服务器上的内存不足异常并导致服务中断。

解决方案：

您必须增加 Tomcat 系统的最大堆大小。需要注意的是，您只能分配 70% 的物理内存作为 JVM 内存，而 30% 是为操作系统保留的。使用命令 jmap检查JVM配置，然后在配置中增加。

需要在Tomcat的启动脚本中添加如下Java参数，可以在 TOMCAT_HOME/bin中找到，根据内存需求增加JVM分配，回收Tomcat实例。

JAVA_OPTS="-Xms512m Xmx1048m

Tomcat 管理员经常面临应用程序永久对象生成的问题，因为每个应用程序对对象生成的要求不同。因此，应用程序缓慢也会导致在 catalina.out中产生 OutOfMemoryError: PermGen space异常。

例外：

MemoryError: PermGen space
java.lang.OutOfMemoryError: PermGen space

原因：

永久代是独一无二的，因为它包含描述用户类的元数据。具有大型代码库的应用程序可以快速填满导致 java.lang.OutOfMemoryError: PermGen 的这部分堆，无论您的 多高-Xmx 以及你在机器上有多少内存。

解决方案：

在Tomcat 7的启动脚本中需要添加以下参数，该参数会在Tomcat 7启动时增加永久代空间。

-XX:MaxPermSize=(MemoryValue)m

例如：

-XX:MaxPermSize=128m

我们在许多应用程序中都遇到过这个问题。这个异常主要是由于递归类加载（编码不当）引起的。此问题还会导致应用程序的性能下降：我们观察到应用程序在一小时前运行良好，但随后变得无响应。这是堆栈溢出异常的关键指示。以下屏幕截图显示了日志中的错误：

例外：

at java.lang.Thread.run(Thread.java:534)
----- Root Cause -----
java.lang.StackOverflowError

Copy

原因：

执行堆栈溢出时抛出的异常是因为它包含了太多的嵌套方法调用。

解决方案：

需要增加Tomcat启动文件中 -xss参数的值。

-Xss=(memory value in k)

例如：

-Xss=128k

默认情况下，堆栈溢出异常带有 64 k 的值，后跟循环。

管道损坏异常是生产环境中报告的最常见问题之一。这个例外是什么意思？这意味着来自 J2EE 容器的数据库连接被终止。此问题的可能原因是频繁的网络断开连接、数据库上的以太网故障或 J2EE 服务器级容器。

以下屏幕截图显示了日志中的错误：

例外：

at java.lang.Thread.run(Thread.java:619)
Caused by: ClientAbortException: java.net.SocketException: Broken pipe

Copy

原因：

此问题是由于 Tomcat 7 和数据库之间的连接丢失造成的。

解决方案：

回收 Tomcat 实例以恢复连接。

很多时候，当我们点击应用程序进行任何交易时，应用程序会在一段时间后显示一个空白页面。看起来应用程序服务器没有响应，但事实可能不同。在许多情况下，真正的罪魁祸首是数据库。发生的情况是应用服务器向数据库发送请求并等待响应，但连接在服务器处异常终止，导致连接超时异常。以下屏幕截图显示了日志中的错误：

例外：

at org.apache.commons.dbcp.PoolingDataSource.getConnection (PoolingDataSource.java:104)
Caused by: java.util.NoSuchElementException: Timeout waiting for idle object

原因：

此问题是由 Tomcat 的连接池引起的。

解决方案：

更改Tomcat的连接空闲值，这些设置在 server.xml，后面跟着recycle。

此类问题通常在企业环境中报告，其中正在安装新应用程序或正在迁移应用程序。这是 Tomcat 7 中 JNDI 配置不正确的问题。

例外：

java.lang.RuntimeException: Error initializing application. Error Unable to load any specified brand or the default brand: net.project.persistence.PersistenceException: Unable to load brand from database.

前面的错误往往表示无法访问数据库。

Please check your database configuration or contact your system administrator: java.sql.SQLException: Error looking up data source for name: jdbc/abc

原因：

由于 JNDI 名称不正确或 JNDI 名称不存在，Tomcat 7 无法连接到数据库。

解决方案：

与数据库管理员一起获取正确的 JNDI 名称并正确配置，然后进行回收。