JVM、运维大佬过来看看这个问题

[cs3230524]

普通的 java web 项目，在一个多核心的服务器上部署多个实例有意义吗？

假如环境： 服务器：32c64g 容器：tomcat

在这样的情况下： 1 个 tomcat1 个应用 1 个 tomcat10 个相同应用 10 个 tomcat1 个应用

这 3 个效果是差不多的吗？运维层面需要针对这种多核部署多个应用有意义吗？

[night98]

1 个 tomcat1 个应用
1 个 tomcat10 个相同应用
10 个 tomcat1 个应用

非要选的话，最后一个吧
第一种其实还行，最简单，无非是如果要求最佳性能的情况下，需要对 tomcat 默认参数进行调整
第二个，没啥意义，徒增复杂度
第三种，理解了半天，应该意思是部署 10 个 tomcat ，里面部署相同的应用吧
这种冗余程度最高，只要主机不挂基本能保持对外服务，但是你 32C64G 应该用不到部署这么多实例吧

没啥高可用的要求的情况下，选第一种就行了，大概率你们服务也不会有太高的并发，调下 jvm 最大堆大小基本上就没啥要调整的了，实在要调整的话改下 tomcat 默认线程数基本上就完事了

[rrfeng]

单机多实例也就平滑升级有点用。jvm 又不是只能用单核的。

[wangritian]

如果 web 程序是多线程或线程+协程混合工作，启动 1 个进程即可
如果是纯协程或全异步事件驱动工作，启动多个进程可以提高性能，数字以压测为准

[xuanbg]

一般情况下，在同一台物理主机上部署多个相同应用的实例没什么意义。因为 tomcat 又不是单线程的，有并发的请求进来，tomcat 也会并发处理。

如果是为了充分利用机器的性能，可以部署多个不同的应用。如果是为了容灾，那就多部署几台物理主机。

[Jiajin]

应用不中断升级角度来说有用，其他基本无用

[lmshl]

理论上来说应该是“ 1 个 tomcat1 个应用”性能最好，线程池会探查操作系统核数的，如果应用是协程开发的话更应该这样了。

实际上部署 2-3 个都是可以接受的，但更多属实没必要

[DonaldY]

了解到，是在一个大的物理机上划分虚拟机，然后分配给开发。

[paranoiagu]

第二种方案绝对不可以。

[ledkk]

一、1 个 tomcat1 个应用
二、1 个 tomcat10 个相同应用
三、10 个 tomcat1 个应用
======================
方案三比较合适，但具体是 10 个 tomcat 还是 8 个 tomcat 需要实际数据验证。 运维层面考虑后续的升级、部署上都需要对业务无感。性能层面一、二、三需要做对比验证，这个和程序业务实现、tomcat 的运行参数有很大的关系。同一个 JVM 虽然能共享一些数据，减少性能开销，但更多的线程也会带来更剧烈的资源争抢。多个 JVM ，内存会存在一定的浪费，高版本的 JDK ，这块可以尝试 ACDS 。

[bthulu]

我选择 1 个 tomcat10 个不同应用, 省钱啊, 要问挂掉了怎么办, 重启啊, 几秒钟到十几秒钟的不可用时间也等不了么?

[Aresxue]

说一下他们的差别好了, 有没有意义自己见仁见智吧
1.服务器上只有一个 jvm ，code cache 什么的只有一份，内存回收的效率比较依赖 gc ，g1 和 zgc 对大内存比较友好，如果是比较老的 jvm 可能会比较拉胯，值得注意的是超过 32G 以后 jvm 的指针压缩会失效导致内存利用率下降；
2.1 个 tomcat 启动 10 个 jvm 进程，这种我认为和第三种区别不大，唯一的区别是所以应用的配置比较容易保持一致，但你本身暴露端口之类的配置还是要在启动一个实例后修改（不然会端口冲突），个人角度认为没必要；
3.这种算是目前比较主流的方式，优点就是可以滚动升级服务没有不可用时间，同时如果代码有内存泄露等问题，能够先局部重启保证服务可用再保留部分应用慢慢排查问题，很多问题的影响范围可以被缩小，它的缺点是同样的 code cache 会有重复的多份比较浪费内存，一些内存级的缓存也都会被缓存多份，还有就是一些单 jvm 没有问题的代码可能会出现一些问题（这个属于代码的问题可以避免和修复）
题外话：一般的 java web 都是 io 型项目，其实 cpu 都是利用不充分的，32c 和 64g 基本上两者的利用率是对不齐的，可以再多请求一些内存资源