Skip to Content

Wiki source code of How to Determine Needed Memory

Last modified by Erik Bakker on 2024/09/05 14:26
Show last authors
1 {{container}}{{container layoutStyle="columns"}}(((
2 In this microlearning, we will explore the key concepts involved in determining the memory requirements for your complete integration landscape. Understanding the different types of memory needed to efficiently run your Java Virtual Machine (JVM) and managing the integration of data across systems are essential for maintaining a stable eMagiz solution. We’ll guide you through the process of calculating memory needs, explain the factors influencing these requirements, and show you how eMagiz helps optimize memory allocation within your integration environment.
3
4 Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5
6 == 1. Prerequisites ==
7
8 * Advanced knowledge of the eMagiz platform
9
10 == 2. Key concepts ==
11
12 This microlearning centers around determining the memory that is needed to run your complete integration landscape.
13 With memory, we mean: A collection of memory types (heap, native and direct) that are needed to properly run a runtime (Java Virtual Machine)
14 With integration landscape we mean: A overview of all data integrations that are used to exchange data between systems
15
16 * eMagiz will help to determine the needed memory via the Design Architecture page.
17 * eMagiz works with pre-determined sizes that are represented via an S, M, L, XL structure. Every size has a certain amount of memory available
18 * When you exceed such a threshold you should upgrade (or downgrade) your memory in consultation with your partner manager
19 * Overhead for OS and support functionality (auto-healing, alerting, monitoring) needs to be taken into account
20 * The calculations and logic described below are applicable for the Messaging, API Gateway and Event Streaming pattern
21
22
23
24 == 3. Determining Needed Memory ==
25
26 One of the key aspects of running a stable eMagiz solution is proper management of the needed memory to run all your integrations within your integration landscape.
27 To determine what is needed you get help from eMagiz in Design Architecture.
28 In the Design Architecture eMagiz tells you based on our calculations what the recommended sizing of a **machine** should be.
29 If this deviates from what is configured you should take a closer look at whether you indeed need more memory.
30
31 === 3.1 The calculation of eMagiz ===
32
33 In this section, we will delve into that recommendation to explain to you how you should interpret this recommendation so you can make the correct determination of how much memory is needed.
34
35 To calculate the memory eMagiz has determined that the flows that are running on the runtimes make up most of the memory.
36 To calculate how much memory a single flow uses on average eMagiz uses several assumptions. These assumptions are the foundation of the recommended memory size by eMagiz.
37
38 * Limited use of 'non-standard' flows. So, are the number of components within a flow comparable to the 'standard' setup (i.e. an autogenerated onramp).
39 * Average message size of less than 100KbSize van de berichten
40 * Standard number of consumers
41 * Use of Java extensions such as Groovy Scripts
42 * Limited use of complex transformations
43 * Limited use of Xpath and SpEL expression related to large messages
44
45 As long as you do not deviate from the above assumptions at all or not too much the recommended sizing of eMagiz should work for you.
46
47 Based on the above assumption we made thresholds for the number of flows.
48 If you pass a threshold (i.e. 50 flows) the recommended size of that runtime and therefore the machine the runtime is running on will increase.
49
50 All thresholds that are used by eMagiz can be found in the help text of eMagiz when checking the size status.
51
52 On top of the calculation of needed memory based on the number of flows eMagiz also accounts for the following 'overhead'
53
54 * OS
55 * Support functionality (auto-healing, alerting on infrastructure, monitoring on infrastructure)
56 * Buffer
57
58 For JMS processes the default is 500MB heap and 152MB non-heap.
59 In most cases, there is no reason to deviate from this number until you reach a lot of throughput on a lot of flows.
60
61 === 3.2 Check size status ===
62
63 Now that we know how eMagiz calculates the needed memory based on the number of flows and certain categories of overhead we can turn our attention to the eMagiz tooling itself.
64 In eMagiz, in Design Architecture you can check the recommended size status given by eMagiz.
65
66 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--check-size-status.png]]
67
68 Selecting this option will lead you to the following pop-up
69
70 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--check-size-status-pop-up.png]]
71
72 In this pop-up you see the calculation split up into three categories:
73
74 * Required heap memory
75 * Required non-heap (native) memory
76 * Required overhead
77
78 ==== 3.2.1 Required overhead ====
79
80 The first segment we are going to take a look at is the required overhead. Under this category fall the following characteristics:
81
82 * OS
83 * Support functionality (auto-healing, alerting on infrastructure, monitoring on infrastructure)
84 * Buffer
85
86 Each of these characteristics has a pre-determined setting that we recommend for the proper working of eMagiz.
87 We reserve 712MB for the OS, 50MB for the Support functionality, and a Buffer of 100MB **per** active runtime on a machine.
88 If we tally this up for our example we end up with 962MB of overhead. Just as you can see in the pop-up:
89
90 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--check-size-status-pop-up-required-overhead.png]]
91
92 ==== 3.2.2 Required heap memory ====
93
94 As explained before the amount of memory needed is determined by the number of flows that are designed within your integration landscape.
95 In eMagiz the memory allocation is divided into two parts:
96
97 * Heap memory
98 * Native (non-heap) memory
99
100 The heap memory is used to process messages and can be cleaned up via the garbage collection process.
101 The native memory is used to start up your flows and keep them running. This part of the memory is allocated and not released in the same way as with heap memory.
102
103 To make it clear for you how much of which type of memory is needed we have split up the calculation into two portions.
104 One for the required heap memory and the other for the required non-heap (native) memory.
105
106 Both are derived from the number of flows that are designed in your integration landscape. In our example, we have one JMS and one process container, and a total of 29 flows.
107 This leads to the following calculation on heap memory:
108
109 500 (JMS) + 580 (Process Container) = 1080MB. This is once again the same as what is calculated under check size status
110
111 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--check-size-status-pop-up-required-heap-memory.png]]
112
113 ==== 3.2.3 Required non-heap memory ====
114
115 The third part of the equation is the amount of non-heap memory that is required to run your eMagiz solution. Once again the starting point is the number of flows. In this case 29 flows.
116 This leads to the following calculation on non-heap memory:
117
118 152 (JMS) + 792 (Process Container = 944MB. This is the same as what is calculated under check size status
119
120 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--check-size-status-pop-up-required-non-heap-memory.png]]
121
122 ==== 3.2.4 Total recommended memory ====
123
124 When you sum up these three values you arrive at the recommended size based on the current state of your Design.
125 So when your Design is not representative of the truth the calculation will neither be a correct representation of the truth.
126
127 In this case the total recommended memory will be:
128
129 962 + 1080 + 944 = 2986MB
130
131 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--check-size-status-pop-up-recommended-sizing.png]]
132
133 === 3.3 Comparison ===
134
135 Now that we know the recommended sizing of eMagiz we can compare this to the sizing that is allocated based on the contractual agreements between eMagiz and you.
136 This is the last segment of the check Size Status information in Design. In this segment you see:
137
138 * The recommended size
139 * The allocated size
140 * The difference between recommended and allocated
141
142 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--check-size-status-pop-up-comparison.png]]
143
144 So in this example, we still have 1110MB left on our machine. If the number at the bottom would indicate that you need more size than is allocated at the moment you should take action.
145
146 === 3.4 Taking Action ===
147
148 Based on this information it is time to take action. Taking action is foremost validating the calculation as given by eMagiz.
149 As said before we assume certain things and based on whether part of those assumptions, all of them or none of them are met the result could differ.
150
151 In this section, we will discuss some combinations and the appropriate action based on these combinations.
152
153 ==== 3.4.1 Valid Assumptions + Correct nr. of flows ====
154
155 The first combination is the easiest of them all. This combination states that all assumptions that eMagiz has done hold truth.
156 If so, trust the calculations of eMagiz and ensure that there is enough allocated room based on the recommended size by eMagiz.
157
158 ==== 3.4.2 Valid Assumptions + Incorrect nr. of flows ====
159
160 We see a growing number of projects that have a myriad of process containers with the consequence that the assumption that all process containers run the same flows does not hold anymore.
161 In these cases, you should adjust the calculations for the heap and non-heap memory allocation yourself based on the actual number of flows.
162
163 If the result of that calculation still says that there is not enough room please allocate more room based on that altered calculation.
164 To help you perform that calculation yourself we have devised two tables that you can use to come up with the correct values for both heap and non-heap.
165
166 The table shown below is relevant for process containers on the CORE machines.
167
168 | Nr. Flows | Heap | Non-heap |
169 | 0-10 | 500 | 472 |
170 | 11-20 | 500 | 552 |
171 | 21-50 | 580 | 792 |
172 | 51-75 | 820 | 992 |
173 | 76-100 | 820 | 1192 |
174 | 101-150 | 1220 | 1592 |
175
176 The table shown below is relevant for connectors on the CONNECTOR machines.
177
178 | Nr. Flows | Heap | Non-heap |
179 | 0-5 | 500 | 152 |
180 | 6-10 | 500 | 192 |
181 | 11-15 | 500 | 232 |
182 | 16-20 | 500 | 272 |
183 | 21-25 | 580 | 312 |
184 | 26-30 | 580 | 352 |
185 | 31-35 | 580 | 392 |
186 | 36-40 | 580 | 432 |
187 | 41-45 | 580 | 472 |
188 | 46-50 | 580 | 512 |
189 | 51-55 | 820 | 552 |
190 | 56-60 | 820 | 592 |
191 | 61-65 | 820 | 632 |
192 | 66-70 | 820 | 672 |
193 | 71-75 | 820 | 712 |
194 | 76-100 | 820 | 912 |
195
196 ==== 3.4.3 Incorrect Assumptions ====
197
198 When you deviate from the assumptions made by eMagiz to determine the sizing
199 you should start from scratch and determine how much you roughly deviate from the standard assumptions.
200
201 Based on that estimate you should increase the heap and non-heap memory accordingly.
202 This won't have any effect on the calculations for the overhead so they will stand.
203 For example, when you deviate from the assumptions in a little way you could think of selecting the memory settings that are determined for one level higher.
204
205 If you deviate a lot from the assumptions you should increase more drastically and test your solutions on the performance based on the expected throughput.
206
207 === 3.5 Configure the size ===
208
209 Now that we know what the size should be, either by following the eMagiz calculation
210 or by calculating the correct numbers ourselves with the help of components of the eMagiz calculation we can configure the size.
211
212 To configure the size you enter Start Editing Mode in Design Architecture
213
214 [[image:Main.Images.Microlearning.WebHome@expert-solution-architecture-determining-needed-memory--design-architecture-start-editing-mode.png]]
215
216 While you are in Start Editing Mode you can alter the configured size of your eMagiz cloud machines to ensure that enough memory is available for the processes running on that machine.
217 You can easily do so by switching around between S, M, L, XL, and XXL on machine level with the help of the arrows.
218 After you have altered the size you can verify whether the change was enough by comparing
219 it to the recommended size which is shown beside the configured size, by opening the Check Size Status pop-up for conformation or by comparing your calculation to the newly allocated memory.
220
221 In case there is room left you have scaled accordingly. If there still is extra room required you should move another level up until you reach the desired level.
222
223 == 4. Key takeaways ==
224
225 * eMagiz will help to determine the needed memory via the Design Architecture page.
226 * eMagiz works with pre-determined sizes that are represented via an S, M, L, XL structure. Every size has a certain amount of memory available
227 * When you exceed such a threshold you should upgrade (or downgrade) your memory in consultation with your partner manager
228 * Overhead for OS and support functionality (auto-healing, alerting, monitoring) needs to be taken into account
229 * Calculating memory can be challenging. Always confer with others before taking action
230 * You can compare your calculations with the calculations of eMagiz
231 * The calculations and logic described below are applicable for the Messaging, API Gateway and Event Streaming pattern
232
233 == 5. Suggested Additional Readings ==
234
235 * [[Crash Courses (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]
236 ** [[Crash Course Platform (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.WebHome||target="blank"]]
237 *** [[Understanding Design Architecture - Basic (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-design-understanding-design-architecture-basic||target="blank"]]
238 * [[Intermediate (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]]
239 ** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Solution Architecture.WebHome||target="blank"]]
240 *** [[Understanding Design Architecture (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Solution Architecture.intermediate-solution-architecture-understanding-design-architecture||target="blank"]]
241 ** [[eMagiz Runtime Management (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.eMagiz Runtime Management.WebHome||target="blank"]]
242 *** [[Configure Needed Memory (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.eMagiz Runtime Management.intermediate-emagiz-runtime-management-configure-needed-memory.WebHome||target="blank"]]
243 * [[Expert (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.WebHome||target="blank"]]
244 ** [[Solution Architecture (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.WebHome||target="blank"]]
245 *** [[Configure needed runtime memory (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Expert Level.Solution Architecture.expert-solution-architecture-configure-needed-memory.WebHome||target="blank"]]
246 * [[RCA Knowledge Base (Menu)>>doc:Main.eMagiz Support.RCA Knowledge Base.WebHome||target="blank"]]
247 ** [[Runtime Issues (Navigation)>>doc:Main.eMagiz Support.RCA Knowledge Base.rca-knowledgebase-runtime-issues.WebHome||target="blank"]]
248 *** [[Out of memory - Machine (Explanation)>>doc:Main.eMagiz Support.RCA Knowledge Base.rca-knowledgebase-runtime-issues.rca-knowledgebase-out-of-memory||target="blank"]]
249 * [[Determine needed memory (Search Result)>>url:https://docs.emagiz.com/bin/view/Main/Search?text=determine%20memory&f_type=DOCUMENT&f_space_facet=0%2FMain.&f_locale=en&f_locale=&f_locale=en&r=1||target="blank"]]
250
251
252 )))((({{toc/}}))){{/container}}{{/container}}