dogboy

上面列出的线程都是GC线程，说明JVM出现问题了，可能的原因：1、JVM的最大值设置偏小，无法满足高峰期的应用需求。解决办法是调大JVM大小2、应用程序存在内存泄露，堆积到一定程度引起JVM不足。解决办法是收集heapdump或coredu

查看plugin和was的虚拟主机里面，是否配置了8080的主机别名

是的，严格来讲，是serverindex中配置的主机名。只要可以解析该主机名就可以，至于是配置在本机hosts还是dnsseever都无所谓，或者配置为localhost都可以

1、软件安装部分，WAS提供了静默安装方式。如果是WAS8或WAS9，还可以利用PU搭建网络存储库，只需要手工传输IM介质即可。2、profile的创建，WAS也提供了命令行方式3、DM环境的搭建，这部分WAS也有相关的命令。注意dmgr节点要配

个人认为WAS太重了，不太适合未来的主要发展方向，未来不再是“大而全”，讲究“小而美”，高并发、高压力的场景是微服务、PaaS的天下，WAS的未来可能无法再现往日辉煌。 但是换个角度考虑，不管未来怎么变化，现有的技术、应用的

1、打开GC日志，看看CPU高的时间段，GC是否频繁2、如果频繁基本可以定位是GC导致的，可能的原因是存在JVM泄露、JVM申请频繁、JVM设置偏小等，需要具体看3、如果不频繁，GC正常，则应该是应用线程占用的CPU高。可以使用微软的 Pro

9443是WAS自带的SSL端口，使用的是WAS创建profile时生成的自签名证书，和控制台证书是一样的，默认有效期是1年，会在过期前四周的周六晚上进行自动更新（有时会更新失败，比如更新时间段没启动）我认为自己配置SSL和使用默认的9443

DM还是standalone？standalone的话默认SOAP端口是8880，看看具体的SOAP端口是什么另外，was必须处于启动状态

建议查找内存溢出的原因，经常出现的话，问题比较严重，重启只是规避，不是解决方案介绍下监控方案吧：1、使用java编写程序，建议采用mina框架，开放一个端口，比如8888，部署在可以访问邮件服务器的报警服务器上，接收到数据后关闭连接，

was线程池配置多大？当时连接到9080端口的有效连接有多少个？从你的描述看，1、怀疑是压力大时，线程池满了，后续连接排队从而引起plugin以为was宕机，把该服务器上的请求转发到其他server2、是否出现单次GC时间过长导致不响应pl