Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/linux/27.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Java Tomcat Linux服务器出现故障问题_Java_Linux_Tomcat_Centos - Fatal编程技术网

Java Tomcat Linux服务器出现故障问题

Java Tomcat Linux服务器出现故障问题,java,linux,tomcat,centos,Java,Linux,Tomcat,Centos,周五下午很晚,我的web应用程序已停止响应请求。服务器仍然可以访问,Apache Tomcat进程没有运行——日志中没有错误。你想回家,但在修好之前你不能。你是做什么的 重新启动服务器后,站点将运行 服务器管理员告诉我“经进一步调查,我们了解到Tomcat应用程序无法处理在您网站的高峰营业时间或网站流量高时进入服务器的大量请求。这就是Tomcat服务挂起或崩溃的原因,然后唯一的解决方案是重新启动它,使Tomcat服务运行。所以其他时间说堆大小问题“ 但我的网站每天最多只能产生250人 请告诉我该

周五下午很晚,我的web应用程序已停止响应请求。服务器仍然可以访问,Apache Tomcat进程没有运行——日志中没有错误。你想回家,但在修好之前你不能。你是做什么的

重新启动服务器后,站点将运行

服务器管理员告诉我“经进一步调查,我们了解到Tomcat应用程序无法处理在您网站的高峰营业时间或网站流量高时进入服务器的大量请求。这就是Tomcat服务挂起或崩溃的原因,然后唯一的解决方案是重新启动它,使Tomcat服务运行。所以其他时间说堆大小问题“

但我的网站每天最多只能产生250人


请告诉我该怎么做。

您需要加载测试您的代码,由于提供的信息有限,任何人(即stackoverflow)给出的答案都非常有限

它是否启用了jmx? 如果是这样的话,那么通过jconsole连接到您的tomcat服务器并观察发生了什么,在我看来,这是堆转储,可能是内存限制,然后崩溃

您可以先在setenv.sh中添加类似的内容

-详细说明:gc-Xloggc:/var/log/tomcatXX/gc.log-XX:+PrintGCDetails-XX:+PrintGCDateStamps

然后,您可以查看gc日志,查看它执行完整gc的频率,以及它当前的配置是否确实存在问题

问题是,您可能会对其进行不同的配置,但仍然会因为代码中的内存泄漏而面临崩溃。这就是为什么通过jconsole进行负载测试和监视jvm很重要的原因——通常在完全gc之后,如果内存使用量不断增加,那么内存使用量应该下降到默认可用级别,直到后面的可用内存减少为止呃,每个完整的gc您都可以确保代码中存在内存泄漏

查看tomcat进程上的Xms amd XMx设置如果此设置较低,请尝试增加此设置,通常这是应用程序(tomcat)的总体内存配置。这是在内存泄漏的帮助下达到其容量时,它将崩溃

如果Xmx和Xms设置得很低,比如512M,那么一定要尝试将其加倍,如果更好,内存更多,那么可以选择2gigs等等

所以增加这个值会增加它的运行时间,但这也仅限于硬件的实际可用内存

增加您的Xmx和Xms内存配置意味着在达到完整GC之前它有多少内存。假设您的解决方案是高可用性的,并且您有坚固的盒子,那么您可以使用40Gigs的Xmx Xms设置进行堆栈,在对预期流量进行负载测试和测试之后,实际应用程序的内存将=14小时,没有完全gc之后,它将进入完全gc-这将提供14小时不间断的应用程序使用-在此之后,您将无法堆栈b,而让堆栈a执行完全gc

定义的内存越多=gc实际发生的时间越长=
由于内存配置越高,gc运行时间越长=gc运行时实际停机时间越长

例如:

它就像一个大的跳过-较小的跳过肯定会比较大的跳过花费更少的时间来填充或清空。因此,较大的内存配置=较小的gc需要更多的时间,到达完整的gc需要更长的时间,但当到达完整的gc时,清空所需的时间会更长,在此期间应用程序不会响应请求

正确的解决方案是运行多个tomcat服务器,备用或循环,并让它们共享流量——如果您有一个apache前端,或者没有配置F5来实现负载平衡和标记节点等


这应该会给你一些想法,看看应该找什么,看看如何修改

根据背后的代码,即使每天一个人也可能使它崩溃。但奇怪的是,日志文件中什么都没有,我觉得很难相信。