SAP SMP 3.0 On Premise SMP3.0 MBO Java virtual Machine setting.
The SMP 3.0 ODATA server as well as the SMP 3.0 MBO server uses the Java Virtual Machine JVM. Far too often customer will run in to error JVM ran out of memory or the JVM is very slow and causes transaction to process slowly. Either over allocation or under allocation 99% of the time is the root cause. In this article I will outline some details for the starting point customer should consider when setting up the SMP servers.
Purpose:
Recommend starting values for the Java Virtual Machine. Because no two environments are the same there is always variables there for in those cases the administrators would need to implement and test until they find the correct setting for their environment.
Required Software:
SMP 3.0 MBO server runtime.
SMP 3.0 On Premise ODATA.
Thou the two SMP 3.0 servers are completely different from each other they each use a Java runtime environment. The do not share the JVM with each other as they have their own JVM pool. Issue: After running the SAP SMP 3.0 server for a few week the administrator is reporting the SMP server stops responding users are not able to register or sync there device. They are also are seeing the SMP server stopping and no longer up and running forcing the administrator to start the SMP 3.0 server.
Again this can and does happen with either server type MBO or ODATA server.
Cause: In most not all but most incidents this is caused by an incorrect configuration of the Java Virtual machine. Either the SMP server is using the default configuration values or the administrators’ unknowingly have over allocated the Min and Max JVM pool size.
Analyzing the error: More often than not the JVM will throw an out of memory error, when in fact the JVM and the machine has plenty of memory. The question is why is the JVM throwing an out of memory when we set the Max to 24gig or 64gig it does not make any scene.
In this scenario the Java Virtual machine is over allocated. What is happening is the garbage collector is responsible for reclaiming memory and it can’t NOT keep up because the memory segments to fill up once that happen it over loads the JVM allocation pool.
Resolution: For the SMP 3.0 MBO server here are some recommendations :
Figure 1.
Here are the default setting from the SMP 3.0 MBO SAP Control Center for a product server this would be considered under allocation. The recommended starting values for a production server would be
Maximum heap size 12288M
Minimum heap size 4096M
If you scroll lest on the line for User options you will see the MaxPermSize=256M
This should also be change the recommend value should be 512
MaxPermSize=512M
You screen should look like this.
Figure 2.
NOTE: Be very care full when making changed to the user Options line if you make typo fix and don’t add spaces otherwise the SMP server will Not stay up running as it will not be able to create the JVM pool needed.
Each time you change the Java Virtual server you will need to save the values and restart the nodes.
What would be the maximum values for a JVM I would recommend?
Maximum heap size 16384m Minimum heap size 8192M MaxPermSize=1024M
We do see customer on the high end however once you get past the 12gig mark you could start running in the JVM garbage collector error for running out of memory so customer really would need to test to see how a high values would impact thee overall system.
From working with customer and seeing a history of JVM issue I don’t recommend going over 16gig for max
Other considerations:
When adjusting the JVM memory you also need to consider the total amount of memory that the operating system has.
For example
Windows to work correctly should be allocated 8gig so if you allocate 12 gig for the JVM plus the 8 gig for the operating system at a min the hardware need to have 20gig a minimum. The operating system recommendation would be around 32 gig this would insure enough memory
SMP 3.0 On premise ODATA server JVM settings.
Login to the SAP Managed cockpit and o to the Java setting.
Figure 3.
NOTE: Be very care full when making changed to the user Options line if you make typo fix and don’t add spaces otherwise the SMP server will Not stay up running as it will not be able to create the JVM pool needed.
Each time you change the Java Virtual server you will need to save the values and restart the nodes.
What would be the maximum values for a JVM I would recommend?
Maximum heap size 16384m Minimum heap size 8192M MaxPermSize=1024M
We do see customer on the high end however once you get past the 12gig mark you could start running in the JVM garbage collector error for running out of memory so customer really would need to test to see how a high values would impact thee overall system.
From working with customer and seeing a history of JVM issue I don’t recommend going over 16gig for max
Other considerations:
When adjusting the JVM memory you also need to consider the total amount of memory that the operating system has.
For example Windows to work correctly should be allocated 8gig so if you allocate 12 gig for the JVM plus the 8 gig for the operating system at a min the hardware need to have 20gig a minimum. The operating system recommendation would be around 32 gig this would insure enough memory
SMP 3.0 On premise ODATA server JVM settings.
Login to the SAP Managed cockpit and og to the Java setting.
Figure 4.
Note once changed the SMP nodes will need to be restarted in order for the changes to take place.
Cluster consideration:
When making changes for the SMP 3.0 MBO server you have to make the change on the primary node fist. The change then will be replication over to the secondary nodes. Once again in order for the change to take place the SMP server need to be restarted
First shut down the secondary nodes, once all the secondary nodes are shut down then shut down the primary node.
Once all the nodes are shut down start the Primary node once the primary node is up and running and back on line and you can log in to the SMP 3.0 MBO server then start the secondary node
For the SMP 3.0 on premise ODATA servers even thou they are in a cluster they do not have the concept of primary or secondary status. In this case you can update any one of the nodes. Once the node is updated the update will be sent to the other SMP 3.0 ODATA server in the cluster this is automatic. Once all the nodes have the JVM change then you will need to stop and start each node in any order for the update to be implemented.
Summary
Performance and tuning is always a challenge to IT and administrator. With this write we can only hope to have a good starting point. It is very important to understand the impact of allocation of resource for any application and how that impacts the overall performance with the combination and adjustment for the JVM should help the SMP 3.0 ODATA on premise and SMP 3.0 MBO server work more efficient.
The SMP 3.0 ODATA server as well as the SMP 3.0 MBO server uses the Java Virtual Machine JVM. Far too often customer will run in to error JVM ran out of memory or the JVM is very slow and causes transaction to process slowly. Either over allocation or under allocation 99% of the time is the root cause. In this article I will outline some details for the starting point customer should consider when setting up the SMP servers.
Purpose:
Recommend starting values for the Java Virtual Machine. Because no two environments are the same there is always variables there for in those cases the administrators would need to implement and test until they find the correct setting for their environment.
Required Software:
SMP 3.0 MBO server runtime.
SMP 3.0 On Premise ODATA.
Thou the two SMP 3.0 servers are completely different from each other they each use a Java runtime environment. The do not share the JVM with each other as they have their own JVM pool. Issue: After running the SAP SMP 3.0 server for a few week the administrator is reporting the SMP server stops responding users are not able to register or sync there device. They are also are seeing the SMP server stopping and no longer up and running forcing the administrator to start the SMP 3.0 server.
Again this can and does happen with either server type MBO or ODATA server.
Cause: In most not all but most incidents this is caused by an incorrect configuration of the Java Virtual machine. Either the SMP server is using the default configuration values or the administrators’ unknowingly have over allocated the Min and Max JVM pool size.
Analyzing the error: More often than not the JVM will throw an out of memory error, when in fact the JVM and the machine has plenty of memory. The question is why is the JVM throwing an out of memory when we set the Max to 24gig or 64gig it does not make any scene.
In this scenario the Java Virtual machine is over allocated. What is happening is the garbage collector is responsible for reclaiming memory and it can’t NOT keep up because the memory segments to fill up once that happen it over loads the JVM allocation pool.
Resolution: For the SMP 3.0 MBO server here are some recommendations :
Figure 1.
Here are the default setting from the SMP 3.0 MBO SAP Control Center for a product server this would be considered under allocation. The recommended starting values for a production server would be
Maximum heap size 12288M
Minimum heap size 4096M
If you scroll lest on the line for User options you will see the MaxPermSize=256M
This should also be change the recommend value should be 512
MaxPermSize=512M
You screen should look like this.
Figure 2.
NOTE: Be very care full when making changed to the user Options line if you make typo fix and don’t add spaces otherwise the SMP server will Not stay up running as it will not be able to create the JVM pool needed.
Each time you change the Java Virtual server you will need to save the values and restart the nodes.
What would be the maximum values for a JVM I would recommend?
Maximum heap size 16384m Minimum heap size 8192M MaxPermSize=1024M
We do see customer on the high end however once you get past the 12gig mark you could start running in the JVM garbage collector error for running out of memory so customer really would need to test to see how a high values would impact thee overall system.
From working with customer and seeing a history of JVM issue I don’t recommend going over 16gig for max
Other considerations:
When adjusting the JVM memory you also need to consider the total amount of memory that the operating system has.
For example
Windows to work correctly should be allocated 8gig so if you allocate 12 gig for the JVM plus the 8 gig for the operating system at a min the hardware need to have 20gig a minimum. The operating system recommendation would be around 32 gig this would insure enough memory
SMP 3.0 On premise ODATA server JVM settings.
Login to the SAP Managed cockpit and o to the Java setting.
Figure 3.
NOTE: Be very care full when making changed to the user Options line if you make typo fix and don’t add spaces otherwise the SMP server will Not stay up running as it will not be able to create the JVM pool needed.
Each time you change the Java Virtual server you will need to save the values and restart the nodes.
What would be the maximum values for a JVM I would recommend?
Maximum heap size 16384m Minimum heap size 8192M MaxPermSize=1024M
We do see customer on the high end however once you get past the 12gig mark you could start running in the JVM garbage collector error for running out of memory so customer really would need to test to see how a high values would impact thee overall system.
From working with customer and seeing a history of JVM issue I don’t recommend going over 16gig for max
Other considerations:
When adjusting the JVM memory you also need to consider the total amount of memory that the operating system has.
For example Windows to work correctly should be allocated 8gig so if you allocate 12 gig for the JVM plus the 8 gig for the operating system at a min the hardware need to have 20gig a minimum. The operating system recommendation would be around 32 gig this would insure enough memory
SMP 3.0 On premise ODATA server JVM settings.
Login to the SAP Managed cockpit and og to the Java setting.
Figure 4.
Note once changed the SMP nodes will need to be restarted in order for the changes to take place.
Cluster consideration:
When making changes for the SMP 3.0 MBO server you have to make the change on the primary node fist. The change then will be replication over to the secondary nodes. Once again in order for the change to take place the SMP server need to be restarted
First shut down the secondary nodes, once all the secondary nodes are shut down then shut down the primary node.
Once all the nodes are shut down start the Primary node once the primary node is up and running and back on line and you can log in to the SMP 3.0 MBO server then start the secondary node
For the SMP 3.0 on premise ODATA servers even thou they are in a cluster they do not have the concept of primary or secondary status. In this case you can update any one of the nodes. Once the node is updated the update will be sent to the other SMP 3.0 ODATA server in the cluster this is automatic. Once all the nodes have the JVM change then you will need to stop and start each node in any order for the update to be implemented.
Summary
Performance and tuning is always a challenge to IT and administrator. With this write we can only hope to have a good starting point. It is very important to understand the impact of allocation of resource for any application and how that impacts the overall performance with the combination and adjustment for the JVM should help the SMP 3.0 ODATA on premise and SMP 3.0 MBO server work more efficient.
- SAP Managed Tags:
