# Migrate Ignition Server to Azure - High CPU on VM from Java(TM) Platform SE Binary Processes **URL:** \ **Category:** Ignition\ **Created:** [July 16, 2019, 7:44pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594 "2019-07-16T19:44:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 16, 2019, 7:44pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/1 "2019-07-16T19:44:37Z")
I moved a production Ignition server and projects over to a VM on Azure using a gateway backup. The Azure VM is the same size as the on-prem VM, which Ignition previously resided on (16GB RAM, 2 core, 128GB). The gateway CPU and memory allocation looks fine (see below). I am running Windows 10, Ignition 7.9.10 and Java Version 8 Update 221. However, I have the clock drift issue which seems to be causing issues at the client level (8 open clients), that have reported slow and laggy updates on power tables. This was not an issue with the on-prem VM. Open further investigation, I see through the task manager that the CPU of VM is at 100% caused by several instances of Java™ Platform SE Binary processes. I don’t want to upsize the VM yet without first understanding this issue. I changed the initial and max heap sizes in the ignition.config file to 2048 and 4096, respectively, with not change in performance. Any help would be appreciated. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/d/dcc7e02518a47143a2e791b11c497d248e2933b1.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/a/a24da0afb9981abd43519878806b74edadd48115.png) Also was reading this article: [https://support.inductiveautomation.com/index.php?/Knowledgebase/Article/View/92/2/clockdriftdetector-warnings-in-the-gateway-console](https://support.inductiveautomation.com/index.php?/Knowledgebase/Article/View/92/2/clockdriftdetector-warnings-in-the-gateway-console) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [July 16, 2019, 7:46pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/2 "2019-07-16T19:46:58Z")
Are we looking at the same screenshot? More than half the cpu usage is your MySQL database… ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 16, 2019, 7:47pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/3 "2019-07-16T19:47:53Z")
Yes I realize that, which is separate issue I am working on understanding, but the other 50% is from (1) of the Java binaries. Does this correspond to one the clients being the issue? ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/4/481156341cc9a5c4ee034c35876c94efa11b3c09.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [July 16, 2019, 7:50pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/4 "2019-07-16T19:50:39Z")
> [@jlopez](#): > > Does this correspond to one the clients being the issue? Are the clients remote or running on the same VM? ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 16, 2019, 7:51pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/5 "2019-07-16T19:51:02Z")
They are remote: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/1/12289e2b2236c27cabecf09ea4e81b34b1328356.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [July 16, 2019, 7:52pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/6 "2019-07-16T19:52:17Z")
Then that JVM instance might be the Ignition Gateway, I don’t know how to get more details from Task Manager. If the load is spiky like you’re seeing it might correspond with large history queries, which could also explain the DB load. You might be able to catch some CPU usage on the threads page of the Ignition gateway. ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 16, 2019, 8:01pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/7 "2019-07-16T20:01:03Z")
The problem instance is listed under Background Processes, the instance under Apps shows 0%. Would the instance under Apps be the Gateway or not necessarily? ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/5/582e2896838d68f7972148d6ff94fa8bf9440309.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [July 16, 2019, 8:03pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/8 "2019-07-16T20:03:56Z")
I’d imagine the gateway is the one under “Background process” since it runs as a service but I don’t know for sure. ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 16, 2019, 8:07pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/9 "2019-07-16T20:07:53Z")
Thanks, under threads doesn’t appear to be any at the order of magnitude to be causing an issue: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/4/4e1f88e532b167b514a93549f6ac6fa49c4b43c3.png) ---
**Author:** ![bpreston](https://avatars.discourse-cdn.com/v4/letter/b/4af34b/32.png) [@bpreston](https://forum.inductiveautomation.com/u/bpreston)\ **Post date:** [July 16, 2019, 8:22pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/10 "2019-07-16T20:22:40Z")
I’m sure its something you’ve thought of but if it worked fine with a server on-prem but is giving issues after moving it to a cloud server. How is your internet connection? If you have any issues with your connection or anything slowing your connection down, could that be your issue? If your facility is using a lot of bandwidth over your connection could that be causing lag on your connection to Azure? If everything worked fine on a local server but is giving issues on a cloud server that’s set up the same way, I would think it may be related to your connection to that server but that’s just an initial thought not knowing anything about your connection. Even without that though I’d get the MySQL moved to a separate machine, even if temporarily for troubleshooting, so you can take that load out of the equation to see how your CPU usage responds. With it being at 100% I would expect to see clock drifts even if your not doing much with the gateway. ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 16, 2019, 8:44pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/11 "2019-07-16T20:44:44Z")
Didn’t think about that, but not sure about the best way of measuring this. VZ speed test from my local machine: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/e/e17bea399e2a2ca8dbc529dfeefd48fcc9599e79.jpeg) Ping Azure server: Avg round trip 18ms Ping On-prem server: Avg round trip 0ms ---
**Author:** ![jpark](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@jpark](https://forum.inductiveautomation.com/u/jpark)\ **Post date:** [July 17, 2019, 2:32am UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/12 "2019-07-17T02:32:14Z")
What is the innodbbufferpoolsize on the mysql? Did you change it from the default? ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 17, 2019, 2:15pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/13 "2019-07-17T14:15:39Z")
It is currently set to 268435456. I am running MySQL 5.7.24. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/0/05bece0b48fee5ad4a432a9832ac6ea163cc4ea7.png) I changed it to 7GB following this: [https://dba.stackexchange.com/questions/27328/how-large-should-be-mysql-innodb-buffer-pool-size](https://dba.stackexchange.com/questions/27328/how-large-should-be-mysql-innodb-buffer-pool-size) I restarted the MySQL service after updating the innodb\_buffer\_pool\_size, which reduced the buffer usage but it did not change the CPU consumption of the VM ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/e/e1e75c22c4b54d010fb4401687e97fb3fe372397.png) So I stopped the MySQL service but the JVM is still very spikey ranging from 6% to 60% ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/f/fc33c06d1dab60da11ded3dafbe5266266aec22e.png) ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 17, 2019, 7:13pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/14 "2019-07-17T19:13:49Z")
Just got off of the phone with support, looks like it is a provisioning issue with the number of cores allocated to the VM (host is 2 core while guest is only 1). Put in a request to bump it up to 4 cores. Hoping this resolves the issue, will post back when the change is made. ---
**Author:** ![francois.morin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/francois.morin/32/15064_2.png) [@francois.morin](https://forum.inductiveautomation.com/u/francois.morin)\ **Post date:** [July 18, 2019, 11:54am UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/15 "2019-07-18T11:54:58Z")
You might want to compare the ignition.conf from your on-prem setup. The Garbage Collector and Memory usage config is probably different. look for something like this # Java Additional Parameters wrapper.java.additional.3=-XX:+UseConcMarkSweepGC # Initial Java Heap Size (in MB) wrapper.java.initmemory=1024 # Maximum Java Heap Size (in MB) wrapper.java.maxmemory=3072" ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 18, 2019, 1:50pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/16 "2019-07-18T13:50:32Z")
They were initially the same, but I increased the initial and max heap sizes on the azure instance On-prem: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/6/6ded5c2e02fc7e288cb852b5fa12c7d0a6b57f64.jpeg) Azure cloud: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/a/afe7d13a3542487e3b4b8824ee08ce92b8445de1.png) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 19, 2019, 2:17am UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/17 "2019-07-19T02:17:26Z")
You really – _ **really** _ – don’t want to be using the Concurrent Mark and Sweep Garbage Collector. Ancient algorithm with poor performance. Search this forum for “G1GC” and follow the recommendations. ---
**Author:** ![jlopez](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@jlopez](https://forum.inductiveautomation.com/u/jlopez)\ **Post date:** [July 19, 2019, 6:56pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/18 "2019-07-19T18:56:50Z")
Thanks, I switched to the G1GC parameters for the ignition.conf file, but not quite sure I understand the changes that need to be made on the client side. I can either limit the allowed JREs to 8+ in the gateway settings as shown here? ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/b/b78fe805b4c33990103988a142beb2b6fb4ece92.png) Or add an argument to the native client launcher, where can this be done? And does this need to be done on a client by client basis? I have new clients go to the gateway homepage, launch the project then open the file that creates desktop shortcut (i.e. I have native client launcher disabled). ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [July 19, 2019, 7:13pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/19 "2019-07-19T19:13:15Z")
There’s almost never a reason to go through the hassle of enabling G1GC on clients - they don’t run for long enough, or with enough memory dedicated, to run into significant problems. ---
**Author:** ![witman](https://avatars.discourse-cdn.com/v4/letter/w/d2c977/32.png) [@witman](https://forum.inductiveautomation.com/u/witman)\ **Post date:** [July 19, 2019, 7:20pm UTC](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594/20 "2019-07-19T19:20:43Z")
> [@jlopez](#): > > limit the allowed JREs to 8+ in the gateway settings as shown here? Yes, but you'd need to limit it to 9+ if you wanted to force G1GC on clients (doesn't affect gateway) **EDIT:** this applies to forcing G1GC _without_ using the jvm argument (you _don't_ need Java 9 to use the jvm argument). > [@jlopez](#): > > Or add an argument to the native client launcher, where can this be done? Yes, add ` jvm-args="-XX:+UseG1GC"` to the end of the shortcut target like this: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/2X/2/2af0a64efcec8e5c29772329e2d9f5e45a6d0d5c.png) > [@jlopez](#): > > does this need to be done on a client by client basis? Yes. But I agree with @paul-griffith that it's usually not needed. I only add it for auto-launched clients on machines within minimal available memory or when I happen to be setting up a link for someone. [Next page](https://forum.inductiveautomation.com/t/migrate-ignition-server-to-azure-high-cpu-on-vm-from-java-tm-platform-se-binary-processes/26594.md?page=2)