Intel ASC memory consumption

[JPokl]

Hello,

after installation of Intel Active System Console on serverboard S2600CP and Windows Server 2012 R2 (only Hyper-V role installed), these processes start to consume lots of memory:

platform_handler.exe

policyservice.exe

around 2GB each, platform_handler in 2 or 3 instances, so around 6GB of memory together. After restart, everything is ok, but these processes are slowly growing up to 2GB.

I have tried ASC 6.1.14 and 7.0.20, both with the same result. After uninstall of ASC everything is ok.

Is there any solution? I would like to use ASC, but 6GB of memory in unacceptable.

Thanks.

[David_A_Intel]

I have noticed in the past that these two processes will increase their memory usage during time. I would need to check how much memory consumes after all.

How long does it take for these two processes to reach 2GB of usage?

[JPokl]

Thank you for your reply David,

As far as I can say now, these processes grow in this manner:

platform_handler.exe aprox 2 MB/min,

policyservice.exe aprox 1 MB/min,

I restarted IASC service and processes one hour ago, so I can give you more accurate numbers later.

[David_A_Intel]

Thank you for the update. Could you please confirm if there is a 3rd process doing the same? It might be listed as "CGI /FastCGI".

[JPokl]

After 24 hours, I can confirm this grow rates:

platform_handler.exe 2.1 MB/minute

policyservice.exe 1.2 MB/minute.

It`s quite constant up to 2 GB of memory (private working set). Now I have only one platform_handler instance, I do not know why there were 3 instances last time.

And there is php-cgi.exe process named as "CGI /FastCGI", but with only small memory footprint - about 5 MB.

Here is screenshot 24hours after restart:

[David_A_Intel]

I am still investigating to see if there is a workaround for this. I will post again as soon as I have an update.

[JPokl]

Hello, any update?

[David_A_Intel]

This issue has been escalated to the appropriate product support engineer for further investigation. Due to the nature of this escalation, we do not expect an immediate resolution. We apologize for this inconvenience and encourage the community to keep sharing any findings and comments that may lead to a workaround.