|
Search Solutions & Best Practices
Browse Solutions & Best Practices
|
Capacity Planning - a voodoo or a simple math?Planning the number of machines your application will require is one of the most important tasks you need to do before moving into production and making your application available to your customers/users. Typically, this is a task you need to do in the early stages of the project in order to budget for hardware and relevant software products your system will use. At a minimum, this involves estimating the number of CPUs and cores plus the memory each machine must have. Another important deployment decision is calculating the maximum number of In-Memory-Data-Grid (IMDG) partitions the application will require. This deployment parameter determines how scalable your application IMDG will be. Once the application is deployed, the number of IMDG partitions will remain constant, but their physical location, their activation mode (primary or backup) and hosting containers will be dynamic. The IMDG instances could fail and relocate themselves to another machine automatically, relocate as a result of an SLA (Service-Level-Agreement) event (for example - CPU and memory utilization breach) or relocate based on manual intervention by an administrator. This IMDG "mobility" is a critical capability that, beyond providing the application the ability to scale dynamically and self-heal itself, can avoid over provisioning and unnecessary over budgeting of your hardware. You can start small and grow as needed with your hardware utilization. The capacity planning should take this fact as a consideration. This article will deal with the following capacity planning issues: Please note that there is no need to specify the maximum number of partitions for Services that are not collocated with IMDG instances. These can be scaled dynamically without the need to specify maximum instances. The Object Footprint within the IMDGThe object footprint within the IMDG is determined based on:
The best way to determine the exact footprint is via a simple test that will allow you to perform some extrapolation when running the application in production. Here is how you should calculate the footprint: This test will give you very good understanding for the object footprint within the IMDG. Don't forget that if you have a backup running the amount of memory you will need to accommodate your objects would be double. See below an example of an object footprint using 32 and 64 Bit JVM. The numbers below may vary based on the actual Object data and indexes values.
Active Clients vs. Cores vs. Heap SizeSince the IMDG kernel is highly multi-threaded process, it will have relatively large amount of active threads handling incoming requests. These requests could come from remote clients or collocated clients. Here are few examples:
A collocated client would not go through the network layer and will interact with the IMDG kernel very fast. This means the machine CPU core that has been assigned to deal with this thread activity will be very busy and will not wait for the operating system to handle IO operations. Taking this fact into consideration means we can have less concurrent clients served by the same core when compared to remote clients activity. The amount of active threads and machine cores is important also for the maximum heap size allocated for the JVM running the GSC. You should have some "headroom" for the JVM garbage collection activity to deal with cleaning allocated resources and reclaim unused memory. Large heap size means potentially large amount of temporary objects that might generate work for the garbage collection activity. So you should have some reasonable balance between the amount of cores the machine is running, the amount of GSCs/IMDG running and the amount of active clients/threads accessing the IMDG. A machine running 4 quad-core cores with fast CPUs (3GHz clock) will be able to handle 20-30 concurrent collocated clients without special delay and 100-150 concurrent remote clients without special delay. Such a JVM should have at least 2-3GB heap size to handle the IMDG data and additional resources utilizing memory. With the above we assume the application business logic is very simple and does not have any IO operations and the IMDG persistency mode is asynchronous. How should I Calculate the number of IMDG Partitions?The question is how to calculate the amount of IMDG partitions required by an application. The number of GSCs per machine you will need initially is calculated based on the machine's physical RAM and the amount of heap memory you would like to have for the JVM running the GSC. In many cases the heap size will be determined based on the operating system: for 32 bit OS you would go for 2G max heap size and for 64 bit OS you would go for 6-10 M max heap size (the JVM -Xmx argument). For performance optimization you should have the initial heap size the same as the maximum size. The next sections will demonstrate capacity planning using a simple real life example. Here are few basic formulas you can use: Amount of GSCs per Machine = Amount of Total Machine Cores/2 Total Amount of GSC = Amount of GSCs per Machine X Initial amount of Machines GSC max heap Size = min (6, (Machine RAM Size * 0.8) / Amount of GSCs per Machine)) Amount of Data-Grid Partitions = Total Amount of GSC X Scaling Growth Rate / 2
Example 1 - Basic Capacity PlanningWith our example we will initially have 2 machines used to run our IMDG application. 10 machines might be allocated for the project within the next 12 months. Each machine has 32 GB of RAM with 4 quad-core CPUs. This gives us a total of 64 GB of RAM. When all 10 machines are available we will have potentially 320 GB total memory. The memory will be used both by primary IMDG and backup IMDG instances (exact replica of the primary machines). The machines will run Linux 64 bit OS. Allocating 6 GB per JVM as the max heap size for the GSC results having 5 GSCs per machine - i.e. 10 GSCs initially across 2 machines. Once we will use all the machines our full budget allows us, we will have 50 GSCs.
Figure 1 - 2 Machines Topology - Five IMDG Instances per GSC, Total 64 G RAM Having maximum of 40 GSCs hosting the IMDG means you might want to have half of them (20 GSCs) running primary IMDG instances and the other half backup instances. This number will be used as the number of partitions the IMDG will be deployed with - this means that with the 2 machines we will have initially, 10 GSCs will host 40 IMDG instances. Later, as needed, these IMDG instances will be relocated to new GSCs that will be started on new machines. Each machine will start 4 GSCs that will join the GigaSpaces grid and will allow the administrator to manually or automatically expand the capacity of the IMDG while the application is running.
Figure 2 - 10 Machines Topology - One IMDG Instances per GSC, Total 320 G RAM This rebalancing of the IMDG instances can be done via the UI or via a simple program using the new Admin API released with XAP 7.0. Future version of XAP will have built-in re-balancing models you may use. Note that being able to determine the number of IMDG partitions prior the application deployment will allow you to have exact knowledge of how your routing field values should be distributed and how your data will be partitioned across the different JVMs that will be hosting your data in-memory. Example 2 - Capacity planning when running on the CloudIn a cloud environment you have access to essentially unlimited resources. You can spin up new virtual machines and have practically unlimited amounts of memory and CPU power. With such an environment, the calculation of the maximum number of IMDG partitions cannot be based on the maximum number of machines you might have allocated for your project. Theoretically you could have an unlimited number of machines started on the cloud to host your IMDG. Still, you must have some value for the maximum number of IMDG partitions when deploying your application. In such cases you should calculate the number of IMDG partitions based on the amount of memory your application might generate and store within the IMDG. Here is a simple example you might use:
The application will need to generate 1 million objects for each type of class during its life cycle:
When using a machine with 32 G RAM we will need 4 machines to run primary IMDG instances to store 111G data in memory and another 4 machines to run backups IMDG instances. For a 64 bit OS we will have 5 GSCs , each having 6 G max heap size - for a total of 40 GSCs (5 X 4 X 2). With 20 GSCs used to run primary instances we could pick 80 as the number of partitions we could have (each GSC will initially host 4 IMDG instances). This means that we will have 160 IMDG instances (half primary and half backups) hosted within 40 GSCs. Theoretically, this allows us to expand the IMDG to run across 160 machines (one GSC per machine). This means 160 X 10 G as the heap size = 1.6 T Byte IMDG memory capacity to host the IMDG objects! This is a huge capacity for the IMDG that is in fact ten times larger than the estimated size - we have lots of room in case our initial memory utilization was wrong. ConclusionCapacity planning is not voodoo. You can estimate the number of machines your application IMDG might need via a simple capacity planning process. To avoid over provisioning you should start small, and expand your IMDG capacity when needed. The maximum number of IMDG partitions can be calculated based on a simple estimation of the number of machines you will have available or based on the size and quantity of objects your application will generate. This will allow your application to scale while remaining resilient and robust. |
Capacity Planning
(None)




Add Comment