High CPU Memory Usage with GEP input connector

JamesDo · ‎12-18-2014

We are using GeoEvent Processor for Server 10.2.2 and are experiencing very high CPU memory usage when we use the (Receive text from TCP Socket) input connector and using the "mode=CLIENT" option.

On a 64bit, 16GB RAM, 4 processors machine running Windows Server 2008 R2 with one (1) of these input connectors we hit above 30% CPU usage, with four (4) of these input connectors we hit 100% CPU usage. We need to configure a geoEvent service that has eight(8) of these input connectors plus other services.

Unfortunately we are not able to upgrade to 10.3. Is there anyway to configure the GEP to use less CPU? Has anyone else experience this issue and how did you manage to resolve it?

RJSunderman · ‎04-07-2015

Erick -

Sorry, no. Unfortunately there is nothing a GeoEvent administrator can do to work around the issue. It's not a resource leak that can be addressed with a server / service restart for example. The implementation of the TCP transport when running as "mode=CLIENT" is simply pinging the server hosting the socket connection too frequently - which is why the CPU resource is spiking.

The fix was implemented for the 10.3.1 product release which should be publically available mid-May 2015. We did back-port a product hot-fix for for the 10.3 product release. I would encourage you to upgrade to 10.3.1 as soon as it's available, but if that's not an option for you, please contact your customer service representative and request the hot-fix. (Hot fixes may be specific to a customer's environment which is why they are not distributed more generally as, say, a product patch would be.)

- RJ

View solution in original post

RJSunderman · ‎01-15-2015

James -

We've investigated and found that this is an issue with the 10.2.2 and 10.3 product releases. We've submitted a bug and will work to address this for the 10.3.1 product release.

Thank you for bringing it to our attention.

- RJ

ErickLobao · ‎03-30-2015

Are there any potential workarounds in the meantime? Should we restart GeoEvent services periodically? I'm working in a scenario with a development, staging, and production servers and GeoEvent will sporadically hit 100%. After hitting 100%, other map / feature services become erratic. With three servers we're seeing the issue happen at different times.

RJSunderman · ‎04-07-2015

Erick -

Sorry, no. Unfortunately there is nothing a GeoEvent administrator can do to work around the issue. It's not a resource leak that can be addressed with a server / service restart for example. The implementation of the TCP transport when running as "mode=CLIENT" is simply pinging the server hosting the socket connection too frequently - which is why the CPU resource is spiking.

The fix was implemented for the 10.3.1 product release which should be publically available mid-May 2015. We did back-port a product hot-fix for for the 10.3 product release. I would encourage you to upgrade to 10.3.1 as soon as it's available, but if that's not an option for you, please contact your customer service representative and request the hot-fix. (Hot fixes may be specific to a customer's environment which is why they are not distributed more generally as, say, a product patch would be.)

- RJ

ErickLobao · ‎04-07-2015

Thanks for the quick response! I'll investigate the hot-fix option on our development / test server.