On 6/28/21 10:04, Mark Thomas wrote:
On 28/06/2021 14:53, Christopher Schultz wrote:

On 6/25/21 22:58, Eric Robinson wrote:
We can run 75 to 125 instances of tomcat on a single Linux server with 12 cores and 128GB RAM. It works great. CPU is around 25%, our
JVMs are not throwing OOMEs, iowait is minimal, and network traffic
is about 30Mbps. We're happy with the results.

Now we're upping the ante. We have a 48-core server with 1TB RAM, and
we're planning to run 600+ tomcat instances on it simultaneously.
What caveats or pitfalls should we watch out for? Are there any hard
limits that would prevent this from working as expected?
If you have the resources, I see no reason why this would present any problems.

On the other hand, what happens when you need to upgrade the OS on this beast? You are now talking about disturbing not 72-125 clients, but 600 of them.

If I had a beast like this, I'd run VMWare (or similar) on it, carve it up into virtual machines, and run fewer clients on each.... just for the sheer flexibility of it.
That just moves the goal posts. You'll have the same issue when the hypervisor needs updating (which admittedly may need a reboot less often than the OS).

Agreed. My assertion is that the hypervisor should require updates far less frequently. My AWS EC2 instances can stay up for months without being forcibly rebooted, for example. (I tend to restart them, anyway, for e.g. OS updates, but the point is the same.)

If this is already a virtualized/cloud environment, then I think you're doing it wrong: don't provision one huge instance and use it for multiple clients. Instead, provision lots of small instances and use them for fewer (or even 1) at a time.

But it adds the overhead of an OS for each instance. And costs if you have to pay for that OS instance.

As always there are trade-offs to be made and the "right" answer will vary based on circumstances and what you are trying to optimize for. I do agree that, generally, more smaller instances will be a closer fit to more use cases but that is only a general answer.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to