其实在线故障排除指南的问题并不复杂，但是又很多的朋友都不太了解，因此呢，今天小编就来为大家分享在线故障排除指南的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！
运行环境配置调优
用户资源限制检查
使用ulimit a 查看当前用户资源限制，如下：
当open files值很低时，会影响生产环境的并发。如果打开的文件值为默认值1024，则需要增加该值。方法：
使用root帐户登录，修改/etc/security/limits.conf文件，添加或修改（已经存在的）以下几行：
修改完成后，重新登录，使用ulimit a查看修改是否生效。
tomcat配置调优（应用程序服务器）
JVM参数配置
1、首先检查tomcat使用的JRE是否是64位的。步骤如下：
步骤1 检查tomcat/bin/catalina.sh，检查tomcat是否指定了JRE路径，如下：
如果JAVA_HOME项被注释掉（以“#”开头），则表示使用系统默认的JRE；如果没有注释，则表示指定了JRE。
Step2 检查tomcat使用的JRE是否是64位版本。使用java -version -d64命令检查，如下：
如上图，是64位的JRE；
如上所示，它是一个32位的JRE。
不同的JRE位有不同的可以分配的物理内存。 32位JRE可以管理的内存不能超过4GB。
需要确认现网应用服务器上可以分配多少内存给DACS应用系统。检查方法：
2. 停止tomcat并检查可用内存大小：
需要确认现网应用服务器上可以分配多少内存给DACS应用系统。检查方法：
停止tomcat并检查可用内存大小：
可用物理内存大小m1=free+cached，以截图为例：m1=3052MB+1181MB=4233MB。
JVM堆内存分配方案：
分配80%的可用物理内存给tomcat。如果现网有内存告警监控，则可以适当降低该比例。现在以80%为例：
分配给应用程序的内存m2=m1*80%=4233MB*80%=3386MB
那么tomcat中的jvm参数配置应该是：
Tomcat/bin/catalina.sh 中的JAVA_OPTS=’-server -Xms3386m Xmx3386m Xmn1270m’
阐明：
-server 指定JVM运行模式为server，生产环境必须指定为server模式；
-Xms JVM堆的初始大小，该值应等于m2，即3386MB；
-Xmx JVM堆的最大大小，该值应等于m2，即3386MB；
-Xmn JVM堆中年轻代的大小，该值应等于m2*3/8，即1270MB。
阐明：
如果JRE是32位，-Xmx的值不应超过4GB。建议配置为3GB，即配置如下：
JAVA_OPTS=’-服务器-Xms3072m -Xmx3072m -Xmn1152m’
tomcat HTTP连接器线程数配置
在tomcat/conf/server.xml中，HTTP连接器建议配置如下： Connector protocol=’HTTP/1.1’acceptCount=’200’connectionTimeout=’30000’disableUploadTimeout=’true’port=’8080’redirectPort=’8445′ maxThreads=’700′ minSpareThreads=’25’ maxSpareThreads=’75’ enableLookups=’false’ URIEncoding=’GBK’/注：tomcat连接器中maxThreads的值代表最大并发数，不应超过750。当并发要求很高时，应该使用tomcat集群。例如最大并发数为1000，则需要启动2个tomcat，每个tomcat的并发数为500。
OOM问题
在生产环境中，一旦出现OOM问题，一般会是非常严重的问题，服务可能会挂起。
然而OOM问题的情况有很多种，不同的情况产生问题的原因也不同。
堆内存OOM
服务器日志一般会打印以下内容：
java.lang.OutOfMemoryError: Java堆空间是最常见的OOM问题。
启动Java服务时，可以添加以下参数：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof 当发生OOM时，程序会自动转储当前内存使用情况，并保存到指定文件中。
然后使用MAT（内存分析器工具），或者使用JDK自带的Java VisualVM，分析dump文件，找出导致OOM的代码。
堆栈内存OOM
发生堆栈内存OOM问题时的异常信息如下：
java.lang.OutOfMemoryError: 无法创建新的本机线程如果在实际工作中出现这个问题，通常是由于创建的线程过多，或者设置的单个线程占用内存空间过多造成的。
这时候就需要检查服务中的线程数。
建议使用线程池，可以减少线程的创建，有效控制服务的线程数量。
堆栈内存溢出
堆栈内存溢出时的异常信息如下：
java.lang.StackOverflowError 这个问题一般是业务代码中写的一些递归调用导致的。递归的深度超过了JVM允许的最大深度，可能会出现栈内存溢出问题。
如果生产环境出现此问题，可以检查递归调用是否正常。可能存在无限递归。
GC OOM
发生GC OOM问题时的异常信息如下：
java.lang.OutOfMemoryError: GC 开销限制超出GC OOM 一般是由于GC 时JVM 中对象过多，导致内存溢出。建议调整GC策略。
老年代80%时开始GC，-XX:SurvivorRatio（-XX:SurvivorRatio=8）和-XX:NewRatio（-XX:NewRatio=4）设置比较合理。
元空间OOM
元空间OOM问题时的异常信息如下：
java.lang.OutOfMemoryError: Metaspace JDK8之后，使用Metaspace来代替永久代。 Metaspace是HotSpot中方法区的实现。
这个问题通常是由于加载到内存中的类太多，或者类的大小太大而引起的。
原创文章，作者：小su，如若转载，请注明出处：https://www.sudun.com/ask/124133.html
用户评论
一纸愁肠。
这太棒了！我一直卡在一些线上问题的排查上，这个指引简直就是我的救命稻草啊！现在看完了，感觉自己对问题排查有了更深刻的理解，以后遇到问题应该能更快解决啦！
有16位网友表示赞同！
毒舌妖后
这篇东西写的很详细，覆盖面也比较广，对于初学者来说非常实用。不过我觉得可以补充一些针对不同平台或软件的问题排查方法，这样会更加全面。
有9位网友表示赞同！
西瓜贩子
最近工作上碰到了好多线上问题，都不知道该从哪里入手？还好看到这篇文章，指引清晰易懂，果然专业人士写的东西不一樣！希望以后能看到更多关于故障维护和修复的相关指南！
有10位网友表示赞同！
搞搞嗎妹妹
文章的内容很实质性，排查流程也很详细。但是我看完后感觉缺少一些实例案例说明，如果能附上一些实际操作步骤，会更容易理解。
有12位网友表示赞同！
不识爱人心
线上问题确实让人头疼，这个指引很有帮助，让我知道如何理清思路进行排查，而不是乱来！
有9位网友表示赞同！
陌颜
我觉得这篇文章主要是面向开发人员吧，对我们普通用户来说可能有些难度。希望能出个更简单易懂的版本，针对一些常见的网络问题提供解决方案。
有11位网友表示赞同！
那伤。眞美
看到这些步骤我更加确定我的程序有问题了，以后碰到线上问题记得回头看看这个指引！
有8位网友表示赞同！
忘故
排查线上问题确实是个技术活，但这篇文章写的让人觉得其实是可以掌握的。最重要的是要有明确的思路和方法，感谢作者分享这种宝贵经验！
有7位网友表示赞同！
折木
我一直觉得排查线上问题是最耗费时间的环节啊，看来还是要学习一下这些技巧才能更高效地解决问题！这篇指引应该会帮助不少人!
有8位网友表示赞同！
你是梦遥不可及
对于新手来说，这个指引非常有用！可以清晰的了解到线上问题的常见类型和排查思路。希望以后能更新一些新的内容，覆盖更多类型的技术问题！
有19位网友表示赞同！
ˉ夨落旳尐孩。
我觉得这篇文章比较 trocken，少了些生动的案例或有趣的插图，这样会更吸引人阅读。当然内容还是很重要的。
有15位网友表示赞同！
素颜倾城
我对线上问题的理解还很浅显，这篇指引让我感觉像是打开了通往高级者的门啊！
有19位网友表示赞同！
最怕挣扎
文章写得好，能把复杂的问题整理成几个清晰的步骤，这对于我这种喜欢直白的学习方法来说真是太棒了！
有11位网友表示赞同！
人心叵测i
网上经常看到一些线上问题的讨论，但大多都是描述问题而没有给出可操作性的解决方案。这篇指引恰当的解决了这个问题，希望能有更多类似的文章分享!
有12位网友表示赞同！
三年约
排查线上问题真的让我头疼，总觉得自己像是在瞎摸！希望以后能多练习、多学习才能掌握那些技巧吧。
有15位网友表示赞同！
冷嘲热讽i
这篇文章太棒了！简直就是救星！我之前遇到网站报错的时候总是找不到原因，看了这篇指引终于明白该如何排查问题了！
有16位网友表示赞同！
抓不住i
这个线上问题排查指引真的很有用！以后遇到类似的问题，我可以参考这些步骤进行分析。希望文章能详细介绍一些常见问题的解决方法，那样会更实用！
有5位网友表示赞同！
咆哮
我很担心自己没有能力解决线上问题，但这篇文章给我带来了很多信心！相信只要按照指引一步一步来，就能慢慢学习到排查技巧！
有17位网友表示赞同！