> -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Monday, June 28, 2021 8:54 AM > To: users@tomcat.apache.org > Subject: Re: 500 instances of tomcat on the same server > > Eric, > > 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. >
There are two load-balanced servers, each with adequate power to support the whole load. When we want to maintain Server A, we drain it at the load balancer and wait for the last active connection to complete. Then we reboot/maintain the server and add it back into the rotation gracefully. > 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. > We considered doing it that way. Performance is top priority, so we ultimately decided to run the instances on metal rather than introducing a few trillion lines of OS code into the mix. We might consider containerizing. > 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. > That makes sense until you know the environment better. It's a canned application and we're not the publisher. Breaking it out this way gives us the ability to present each customer and a unique entity to the publisher for support purposes. When their techs connect, the sandbox allows them to troubleshoot and support our mutual customer independently, which puts them in an environment their techs are comfortable with, and removed the risk of them doing something that impacts everybody on the server (or in the VM, if we used those). All I can tell you is we've been running it this way for 15 years and we've never looked back and wished we were doing it differently. > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
