BAC tool is occupying more disk space of C drive
I am new to BAC tool.
We are facing disk space issue in C drive of BAC server. BAC tool is occupying more space in C drive.
Could anyone please help us in removing unwanted log files or folders from HPBSM folder so that we can free up some space.
Also please let me know the purpose of pubsub.odb file of folder: C:\HPBSM\Sonic\runtime\MsgBroker\SonicMQStore\pubsub
As this file is consuming 7.97GB space
This is the cache file for the Sonic MQ bus. It can grow if there are comms issues between servers, but allocated space won't automatically be freed up. You can take these steps to clear it though (note: these steps are good for BSM 9.1x up to 9.25, but Sonic is with Hornet MQ in 9.26):
1. Stop the Message Broker process via Nanny jmx console http://servername:11021 nanny manager
2. Run this command from a command prompt:
3. Start the Message Broker process via Nanny
If you're not sure about stopping/starting via the console, then stop the BSM service instead.
You can delete old logs, but they will return unless you configure the logging to retain fewer, and/or smaller logs.
Also check for and delete .hprof files in HPBSM\bin directory.
Thanks for the inputs provided.
I have deleted hprof file as well as after running the below command:
which had resized pubsub.odb file. Now the file size is 64KB only.
Just wanted to know whether the resize of pubsub.odb file will have any future impact on tool.
This won't have any future impact on BSM.
It's worth keeping an eye on the size of pubsub.odb. It will definitely increase from 64KB, and that is normal. If it gets above 1GB, then it indicates that there are problems. If that happens, I would recommend opening a support case with HP to investigate why. It could be caused by communication problems between the BSM servers (DPs and GWs), and/or if the bus is getting overloaded This could happen in very large environments, or if data collectors are caching lots of samples (e.g. while BSM is down for patching/maintenance) and then trying to send them too quickly once the first Gateway is up again.