线程池肯定是偏小的。 你的服务器如果没做集群，那么8G内存，目前就只有了1G，一般一个服务节点，最多也就1.5G 。 多了没用，但是你现在的问题是线程挂起 和 内存关系不大。主要先修改WAS的线程池配置，  加到 150-300 看看。 然后数据库连接池： 80-200 ，在哪里看，就得看你的...

个人认为WAS太重了，不太适合未来的主要发展方向，未来不再是“大而全”，讲究“小而美”，高并发、高压力的场景是微服务、PaaS的天下，WAS的未来可能无法再现往日辉煌。但是换个角度考虑，不管未来怎么变化，现有的技术、应用的更新不是一蹴而就的，未来一段时间内，传统应用还会继续存活...

理解这个故障总是在某个特定时间点发生 ？wierd;通常问题定位都是从最底层开始，一层一层向上排查。1. 先排除是否是硬件故障；观察780上各项资源利用率，是否有资源不足；收集硬件告警信息，是否有告警信息，例如 CPU ，内存，磁盘，网络；2. 排除是否是AIX操作系统层面问题，收集操作系统...

用户名是空的 ？

按CPU的架构、型号与数量进行计算。

这个链接里有，写的很详细。可以参考链接：https://wenku.baidu.com/view/0d025bea5ef7ba0d4a733b93.html

不太明白你要恢复那部分代码，如果要恢复原来的版本，那么找到原来版本的war并部署不就可以了，如果想恢复到更新后的版本，那么使用修改的类再做一次更新。另外，使用更新类的方式做应用更更新，为什么会造成应用版本回滚？不过不建议使用更新类的方式升级应用，这样不知道的人会搞不清...

用 supervisor 做进程管理

打开位于Inetsrv 中的 metabase.XML, 并修改 AspMaxRequestEntityAllowed为你需要的值

我看了一下你上传的javacore，发现你的JVM堆最大值设置有点小，你可以设置到3G来缓解该问题，如果资源够用可以设置到6G；应用程序方面，你可以看一下heapdump中什么对象占用了大部分，被什么类方法调用，然后去优化程序。像这种问题建议你下次传数据时把heapdump的占用大的堆栈的详细...