Trying to determine memory usage in a vanilla web app run through tomcat.
I assume that a virtual hosts setup will use significantly less memory than host-per-instance. What is the minimum memory footprint of a single host tomcat 7 instance? For each instance added does the memory footprint grow linearly, or can we share common resources among instances?
I would prefer a multi-instance setup, so as to isolate client sites (i.e. not affect other sites on redeploy or restart), but memory usage is the key. If each instance requires 512mb ram (like grails, for example), then I may have to take the virtual host route as I was not intending to use the 16GB ram available on tomcat alone!
Suggestions appreciated. BTW, only a handful of sites will incur significant load; the majority are small and draw on a client CMS (perhaps I can virtual hosts these sites and only host-per-instance with the "important" client sites)
Related
What do I get by running multiple nodes on a single host? I am not getting availability, because if the host is down, the whole cluster goes with it. Does it make sense regarding performance? Doesn't one instance of ES take as many resources from the host as it needs?
Generally no, but if you have machines with ridiculous amounts of CPU and memory, you might want that to properly utilize the available resources. Avoiding big heaps with Elasticsearch is a good thing generally since garbage collection on bigger heaps can become a problem and in any case above 32 GB you lose the benefit of pointer compression. Mostly you should not need big heaps with ES. Most of the memory that ES uses is through memory mapped files, which relies on the OS cache. So just because you aren't assigning memory to the heap doesn't mean it is not being used: more memory available for caching means you'll be able to handle bigger shards or more shards.
So if you run more nodes, that advantage goes away and you waste memory on redundant heaps, and you'll have nodes competing for resources. Mostly, you should base these decisions on actual memory, cache, and cpu usage of course.
It depends on your host and how you configure your nodes.
For example, Elastic recommends allocating up to 32GB of RAM (because of how Java compresses pointers) to elasticsearch and have another 32GB for the operating system (mostly for disk caching).
Assuming you have more than 64GB of ram on your host, let's say 128, it makes sense to have two nodes running on the same machine, having both configured to 32GB ram each and leaving another 64 for the operating system.
Do we get efficiency in terms of load handling when the same container (in this case the container has a apache server and a php application) is deployed 5 or more times (i.e. 5 or more containers are deployed) on the same Host or VM?
Here efficiency would mean whether the application in such an architecture is able to serve more requests or serve requests faster?
As far as i am aware, each request launches a new apache-php thread and if we have 5 containers handling the requests then will it be inefficient since now the threads launched by apache will be contextually be switched out more often?
Scaling an application requires understanding why the application has reached it's limit. For this, you need to gather metrics from the application and host when it is fully loaded. Without testing and gathering metrics, you're only guessing why you've at capacity.
If the application is fully utilizing one or more cpu cores, but not all of them, then it is either not multi threaded, or is encountering locks preventing all the cores from being used. Adding more containers to the host in this scenario may help scale.
Typically, horizontal scaling is done because a single host is using all of some resource, like disk io, network bandwidth, memory, or cpu. If you find that the app is using all of one or more of these resources when under heavy load, then you need more hosts, not more containers running on the same host.
This all assumes you haven't configured docker to limit resources on the containers. If you reach your capacity with one container, and have resource limits configured, then the easiest way to get further performance is to remove or reduce those limits.
On this page the docker documentations shows an example of a cluster of 4 nodes and 8 web services. The deployment strategy deploys the containers evenly: I assume 2 per node. A load balancer service is also added.
If I understand correctly you will have 3 nodes with 2 web app containers and a fourth node with 2 web apps containers and a load balancer container.
Is there a real performance gain to load balancing on the same node?
Would the node with the load balancer ever load balance to itself while it's busy load balancing?
In my opinion, it depends on:
Your web application architecture,
The engine that runs it, and
Your server capacity (CPU, memory, IO bandwidth, etc.)
A Node web app, for example, is a single threaded application, and depending on how it's written, it may or may not perform optimally for the machine that it runs on. For instance, if you have a compute-heavy application, or if parts of your application perform blocking IO (file, http, etc.) operations, then you'll quickly hit the limits of a single threaded application running on a single core. If your CPU has additional cores, your Node app won't be using them, and that additional power will not be utilized.
In this case, yes, running multiple instances of the application ("load balancing" between them) can offer visible improvement, as long as your CPU and other resources are not already exhausted by any one instance. In other words, if a single instance of your application does not fully utilize the entire CPU capacity available on your host, then yes, running multiple instances of it will help.
If your web application and the engine that runs it, however, is capable of multi-threading and utilizing multiple CPU cores, then running multiple instances of it won't add any value, and may in fact adversely affect your server's performance.
Your ultimate goal in architecting your application and configuring your server should be to optimally utilize all resources available to you: CPU, memory, disk and network bandwidth. If a single instance of your application can exhaust any one of those resources, then there's no benefit in starting additional instances. But if a single instance is unable to use all resources (either naturally, like Node's single threaded nature, or by design, like when your application throttles itself from using too much memory or disk access, etc.) then you can utilize the remaining capacity by running multiple instances side-by-side.
I use rails for small applications, but I'm not at all an expert. I'm hosting them on a Digital Ocean server with 512MB ram, which seems to be insufficient.
I was wondering what are Ruby on Rails server requirements (in terms of RAM) for a single app.
Besides I can I measure if my server is able to support the number of application on my server?
Many thanks
It depends on how much traffic you think you need to handle. We have two machines (a 32GB RAM, usage see below) with 32 unicorn workers two serve one app with loads of traffic and we have one machine with loads of 2 worker apps that have very few traffic.
We also have to consider the database (which needs the most RAM by far in our case due to big caches we granted it). And on top of that all we have *nix which caches the filesystem in unused RAM.
Conclusion: It is very hard to tell without you telling us what sort of traffic you expect.
Our memory usage on one of the two servers for the big app: https://gist.github.com/2called-chaos/bc2710744374f6e4a8e9b2d8c45b91cf
The output is from a little ruby script I made called unistat: https://gist.github.com/2called-chaos/50fc5412b34aea335fe9
we have a solaris sparc 64 bit running the jboss. it has 24G mem. but because of JVM limitation, i can only set to JAVA_OPTS="-server -Xms256m -Xmx3600m -XX:MaxPermSize=3600m".
i don't know the exactly cap. but if i set to 4000m, java won't like it.
is there any way to use this 24G mem fully or more efficiently?
if i use cluster on one machine, is it stable? it need rewrite some part of code, i heard.
All 32-bit processes are limited to 4 gigabytes of addressable memory. 2^32 == 4 gibi.
If you can run jboss as a 64-bit process (usually just adding "-d64" to JAVA_OPTS), then you can tune jboss with increased thread and object pools to make use of that memory. As others have mentioned, you might have horrific garbage collection pauses, but you may be able to figure out how to avoid those with some load testing and the right choice of garbage collection algorithms.
If you have to run as a 32-bit process, then yes, you can at least run multiple instances of jboss on the same server. In your case, there's three options: zones, virtual interfaces, and port binding.
Solaris Zones
Since you're running solaris, it's relatively easy to create virtual servers ("non-global zones") and install jboss in each one just like you would the real server.
Multi-homing
Configure an extra IP address for each jboss instance you want to run (usually by adding virtual interfaces, but you could also install extra NICs) and bind each instance of jboss to its own IP address with the "-b" startup option.
Service Binding Manager
This is the most complicated / brittle option, but at least it requires no OS changes.
Whether or not to actually configure the jboss instances as a cluster depends on your application. One benefit is the ability to use http session failover. One downside is cluster merge issues if your application is unstable or tends to become unresponsive for periods of time.
You mention your application is slow; before you go too far down any of these paths, try to understand where your bottlenecks are. Use jvisualvm or jstat to observe if you're doing frequent garbage collections. If you're not, then adding heap memory or extra jboss instances may not resolve your performance woes.
you can't use the full physical memory, JVM requires max contined memory trunck, try use java -Xmxnnnnm -version to test the max available memory on your box.