How many agents do you have? I'm not seeing this issue, but I have very few agents connected to my systems.
I have been going through some of the coverity output looking for things like memory leaks, but I can't remember if I adjusted anything in analysisd specifically.

There is approximately 40 active agents currently running. Though we have approximately 76 added, some have been retired.

One of the things I have been wondering about was in the /var/ossec/etc/internal_options.conf

The new internal_options.conf file has this:

Analysisd stats maximum diff.
analysisd.stats_maxdiff=999000

The one from 2.8.3 had this:

Analysisd stats maximum diff.
analysisd.stats_maxdiff=25000

Would changing this to a lower number cause any issues?

Thank you for your help so far.

You could try it, I don't think it would cause any issues. I can't remember why that was changed off hand, but see if it helps.

I apologize for a late response. I did change the setting to about a tenth of what it was. I am just waiting to see if the issue still occurs. I changed it on Monday, and the ossec-analysisd is currently at 76.2% memory usage. I will wait to see if the service does self terminate again. I will keep you updated. But thank you for all of your help so far.

Good Morning. Changing the analysisd.stats_maxdiff setting to a lower number has had no effect i'm afraid.

Well I didn't get the issue fixed i'm afraid. But I did get around it by just making a cron job to restart the OSSEC services every 24 hours.

Hi,

I got exactly the same problem, ossec-analysisd increase memory over time. Maybe you can help me if i give the configuration for server and agent. I don't use use fully the fonctionnality OSSEC, i use it just for the integrity of files. Hope you can help me.

Best regards
internal_options.conf.txt
ossec.conf.agent.txt
ossec.conf.txt

I on a new OSSEC server with version 3.0.0-5505.el6.art from the Atomic repository. Downgrading to version 2.9.3-2833.el6.art did not help.

I didn't have any previous versions available to try, so I cloned another OSSEC VM that had version 1:2.9.0-1700.el6.art installed and that did the trick. So it seems this issue started sometime after version 2.9.0 and on or before version 2.9.3.

Whoops, mangled that first sentence. Should read "I had this issue on a new OSSEC server..."

Can you retest on the 2.9.1 branch and see if it pops up there?

Is there a 2.9.1 RPM available for CentOS 6 (or similar)? Or would I need to compile 2.9.1 from source?

We're experiencing this unless we restart the service on a cron.

It's very easy to replicate on a small instance (t3.micro). Anything I can provide to help diagnose this please let me know.