HealthServiceStore.edb file growth

A while back i got an alert that system drive on one of our monitored servers was full. When examining what was consuming disk space I noticed that HealthServiceStore.edb, located in the agent’s Health Service State folder was way to large.

HealthServiceStore.edb is where the result of every workflow that runs on this agent is stored and sent to your Management Server(s). An agent running a lot of performance counters (Exchange, SQL etc) will probably have a larger database file than your average file server.

At first, i tried to flush the agents cache wich did not work. The next thing i tried was to run the “online store maintenance” task from OpsMgr console, this task will run a de-fragmentation of the database file.
onli

You can follow the result in the event log, HealthService (7404) Health Service Store: Online defragmentation is beginning a full pass on database ‘<C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store\HealthServiceStore.edb>’.

Did this work? No, my database file was still huge.
The next thing to do, is to perform a “Dirty Defrag” on the DB file. To do this,

  • open your favorite shell and navigate to C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store
  • Stop Healthservice.exe (Microsoft Monitoring Agent)
  • Run esentutl /r edb (recovery mode)
  • Start defragmentation by running esentutl /d HealthServiceStore.edb

esentutl

Your healthservicestore.edb should now have a normal size.

Do you have anything to include, please comment.

Martin Ehrnst

Martin Ehrnst

Systems Engineer at Intility AS
Working as a systems engineer in one of Norway's leading enterprise cloud providers. Mainly working with System Center, Azure and Windows server products

*All post are personal
Martin Ehrnst

2 comments for “HealthServiceStore.edb file growth

  1. Christopher Walker
    27/07/2015 at 15:37

    We have actually run into the same problem. It happened to several of our servers in a 2-3 day period. Do you happen to know the root cause of the issue? We think it may be an AV scan causing the file to corrupt, but we aren’t sure yet. We are on SCOM 2012 R2 UR6, i’m assuming you are on a similar version?

    Also thanks for the post, it was helpful in solving the issue when it arose.

    • Martin Ehrnst
      07/08/2015 at 11:02

      Hi Christopher,

      I am sorry for my delay in response. Your comment was lost in a pile of spam – The beauty of internet. Anyway, first thing to do, is check that you have activated all AV exclusions stated by Microsoft. They should be a good starting point. Have you had any other problems to these servers, network outage etc? The amount of workflow will also be a key part in how large this file grow. One of our servers was a domain controller, which will collect a lot of performance data etc. This server also had a problem sending all it’s data to our MS’s, hence more growth.

      When this problem occured, i believe we were running UR3 or 4. We are at 6 now.

      Let me know if you experience this frequently, sorry i could not help you further.

Engage by commenting