大约 110 个用户连续运行两天后,Java 服务器 cpu 使用率达到 100%

发布于 2024-08-07 03:11:51 字数 1507 浏览 13 评论 0原文

我有一个 tomcat 6.0.20、apr 1.2、jdk 1.6.0_15 和 mysql 5.1.38,在具有 4 GB 内存的 rhel 盒子上运行。其中有一个简单的 jsp/servlet 应用程序,有 5 个用户,一个 struts 1.2.0.9 应用程序,有 64 个用户,还有一个 struts 2.0 应用程序,有 35 个用户。 struts 2.0用户每秒产生一个条目,一天大约有900个条目。我还在最后两个应用程序中使用 toplink 进行持久化。我已将所有非引用对象声明为 null,在代码中,已应用来自 struts 2 站点和 tomcat 站点的配置文件的生产值。在mysql中应用了线程缓存,将wait_timeout和interactive_timeout减少到相当于tomcat的会话超时。在linux中增加了文件描述符。重新设计的查询。检查线程转储,观察 gc 统计信息,在此基础上应用上述更改,

但仍然面临“java.lang.OutOfMemoryError”错误。

在不同的时间它用于不同的事情,有时是 Servlet.service(),有时是 image.servlet,有时是 jasper 导致它。

非常令人沮丧,因为错误不是恒定的,而是随着时间的推移而不断变化

如有任何帮助,我们将不胜感激 赞赏!!!

JAVA_OPTS=-服务器 -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+CMSParallelRemarkEnabled (tomcat 管理器报告 34 mb 为空,因此未使用 permsize、mx 和 mn 等)

persistence.xml

 <property name="toplink.jdbc.url" value="jdbc:mysql://localhost:3306/dbname?autoReconnect=false"/>

server.xml

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="2000" redirectPort="8443" compression="on" compressableMimeType="application/octet-stream,text/html,text/xml,text/plain,application/x-javascript,image/gif,text/css,image/gif,application/vnd.ms-excel,application/pdf" enableLookups="false"/>

上下文.xml

<Context reloadable="false" delegate="false" privileged="false">

I have a tomcat 6.0.20, apr 1.2, jdk 1.6.0_15 with mysql 5.1.38 running on a rhel box with 4 GB ram. There is one simple jsp/servlet application on it with 5 users, one struts 1.2.0.9 with 64 users on it and one struts 2.0 application with 35 users on it. The struts 2.0 users make an entry every second, about 900 entries in a day. I am also using toplink for persistence in the last two applications. I have declared all non referenced objects to null, in the code, have applied production values for config files from the struts 2 site and from the tomcat site. Applied thread caching in mysql, reduce wait_timeout and interactive_timeout to be equivalent to session timeout of tomcat.Increased file descriptors in linux. Reworked queries. Examined the thread dump, watched gc stats, applied above changes on basis of this,

YET still facing "java.lang.OutOfMemoryError" error.

at different times its for different things, sometimes its Servlet.service(), sometimes its image.servlet, sometimes it jasper that causes it.

extremely frustrtating, as the errors are not constant but keep changing over time

Any help please would be greatly
appreciated!!!

JAVA_OPTS=-server -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+CMSParallelRemarkEnabled
(tomcat manager reports 34 mb empty so have not used permsize, mx and mn etc.)

persistence.xml

 <property name="toplink.jdbc.url" value="jdbc:mysql://localhost:3306/dbname?autoReconnect=false"/>

server.xml

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="2000" redirectPort="8443" compression="on" compressableMimeType="application/octet-stream,text/html,text/xml,text/plain,application/x-javascript,image/gif,text/css,image/gif,application/vnd.ms-excel,application/pdf" enableLookups="false"/>

context.xml

<Context reloadable="false" delegate="false" privileged="false">

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

压抑⊿情绪 2024-08-14 03:11:52

你的问题是你在代码中有这样的东西:

       new Thread(){
          public void run(){
             //something
          }
       }.start();

每次都会在Tomcat的缓存中创建新的类定义文件 - 这会占用空间,所以你有PermGenSpace异常...

重写一些关键类而不是创建自定义“动态”类,创建单独的内部类,事情将会改变......

      class MyJobDoer extends Thread{
          public void run(){
             //something
          }
       }

      MyJobDoer mjd=new MyJobDoer();
      mjd.start();

your problem is that you are having in code something like this:

       new Thread(){
          public void run(){
             //something
          }
       }.start();

which in turn creates each time new class definition file in Tomcat's cache - and that eats space, so you have PermGenSpace exception...

rewrite some of your critical classes not to create custom classes 'on the fly', make separate inner classes and things will change...

      class MyJobDoer extends Thread{
          public void run(){
             //something
          }
       }

      MyJobDoer mjd=new MyJobDoer();
      mjd.start();
记忆消瘦 2024-08-14 03:11:51

首先,您必须确定哪个进程正在占用所有 CPU。这真的是java程序吗?如果您还没有弄清楚的话,请尝试 top(1) 来解决这个问题。

如果您有并且确定它是 Java 程序,请启用远程调试 。下次CPU沸腾时,连接并确保没有线程处于无限循环中。

如果不是这种情况,则说明您内存不足(无论 tomcat 管理器怎么说)。启动 JMX 控制台 并检查各种内存空间。我的猜测是 permgen 已经满了(你的类路径上有很多大 JAR 吗?或者你在某个地方使用 cglib 吗?)当这种情况发生时(并且因为你启用了 perm gen GC),Java VM 将尝试释放内存始终是永久代空间。

除非您使用在运行时创建类文件的东西(例如,像 Groovy 这样的脚本语言),否则这是行不通的:在正常的 Java 程序中,类永远不会被 GC 回收。如果你仍然这样做,GC就会一直运行,除了消耗所有CPU功率之外什么也得不到。

First, you must make sure which process is eating all the CPU. Is it really the java program? Try top(1) to figure this out if you haven't already.

If you have and you're sure that it's the Java program, enable remote debugging. When the CPU boils over next time, connect and make sure that no thread is in an infinite loop.

If that's not the case, you're out of memory (no matter what the tomcat manager says). Start a JMX console and check the various memory spaces. My guess is that the permgen is pretty full (are there many big JARs on your classpath? Or are you using cglib somewhere?) When that happens (and since you have perm gen GC enabled), the Java VM will try to free memory in the perm gen space all the time.

Unless you are using something which creates class files at runtime (a scripting language like Groovy, for example), that will not work: In normal Java programs, classes can never be GC'd. If you still do it, the GC will run and run and achieve nothing but burn all CPU power.

流绪微梦 2024-08-14 03:11:51

也许这是 12。尝试只创建小交易。

Perhaps it's the same problem addressed by 1 and 2. Try to create only small transactions.

寄居者 2024-08-14 03:11:51

我建议使用 jstat 来监视 tomcat 的内存和垃圾收集模式。

您说您面临烫发错误,但没有增加烫发数量。重新加载 tomcat 应用程序可能会导致 perm gen 泄漏,但您可能会在打开所有页面之前观察您的使用情况,从而导致将更多类加载到 perm gen 中。

I'd recommend using jstat to monitor tomcat's memory and garbage collection patterns.

You say you're facing perm gen errors, but haven't increased the amount of perm gen. Reloading tomcat apps can cause perm gen leakage, but you're probably observing your usage before you open all your pages, resulting in loading more classes into perm gen.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文