I upgraded BNA to 12.4.1 last year (from v11.something) and since then it's using A LOT more disk space. We're managing ~650 devices and running on a Windows 2008 R2 VM.
I've turned down the event storage to keep only 7 days but can't find anywhere else to manage the disk space.
We have a 160GB disk that's running at around 155GB at the moment.
Are there any other ways I can keep the disk usage down or is it simply that this is how it is and I need to request some more storage?
You should provide enough (or more than enough...) disk space to insure the functionality that you require. Compared to having a problem that you can't properly troubleshoot because you 'went cheap' on the logging/retention, the cost of even a TB of disk is fairly trivial these days.
I will ask though: do you have a lot of 'noise' in the logs that perhaps you should be looking to eliminate? As an anecdote, after upgrading FOS I started getting a ton of messages related to NTP across a bunch of switches. I knew that everything was working fine and ignored these for a while, but the truth was that some of the switches weren't properly configured for time services, and in a couple of hours of digging and fixing I eliminated thousands of events a day.
Check out the backups - are you storing BNA backups on the same system? That may account for part of the disk usage.
As above though, disk is cheap these days. At some point it's not worth spending too much time on a few 10s of GB, if it means you lose useful data.
My side facing such issue as well for BNA12.4.1.
Within a day, BNA had used over 100GB of disk space.
The solution was to upgrade it to BNA 14 or above.
Hope this helps.
thanks for the reply. we're still on 12.4.1 but I have been looking to upgrade it. I ended up increasing the disk to 200GB, but we can't store many days worth of logs still.
maybe when things get quiet towards Christmas I look at upgrading it!
in most case, root cause is jboss due wrong setting on memory allocations
go to :\Network Advisor folder\jboss\standalone\tmp\
in folder \vfs point with you Mouse right key and Properties
tell me Size: and Size on disk: or post a screen please.
I have upgraded to BNA14 and the issue was resolved.
It no longer consume large memory after that.
So I no longer have the screenshot, because I have uninstalled BNA12.4
ours is currently:
Size: 1.85 GB (1,994,808,470 bytes)
Size on disk: 1.90 GB (2,046,185,472 bytes)
the size - is a bit high - however depend of many Device are managed with BNA but show absolutely ok.
I know that this is an old post, but I've finally upgraded to 14.0.3 (if you've seen my other posts) but if anything the disk usage is worse.
DB size is currently 182GB and growing. I've cut the event retention down to 3 days but that doesn't seem to have stabalised it either. I've currently got a large disk (700GB) as a result of the migration/upgrade but I'm going to be moving the install to a Win 2012R2 box soon and don't want/can't have the same size disk (they're VMs).
Is this expected disk usage? we've got around 600+ IP devices, a mixture of FastIron, NetIron, ServerIron and VDX. Is there anyway to tune it or see what's eating all of the disk space?
I've looked back at the DB sizes from our old installs (as I've kept the partial uninstall files) and when we were running on v11 the DB size was less than 10GB with around 2 weeks event retention and the size of our estate hasn't really changed much - apart from the addition of the VDXs and maybe 30-50 switches.
I really want to be able to get this under control so that we can increase the event rentention and make BNA useful for operational logs.
My other thought is that there's something corrupted and I should start afresh. If so, is there a way to export/import just the config (IP devices, reports, deployments etc) and not the events?
Just as an update on this for anyone interested. I've finally got to the bottom of the disk space usage - which I think someone did point me at during my upgrade but for reasons I'll explain in a minute it didn't resolve the issues straight away.
Basically the disk was being used by the Performance data collection - which, currently, we don't use as we have other tools that do this. So I've disabled all the historical data collection and run the clear-performance-data script to delete all the old data.
Now, the first time I ran this - during my migration - it cleared out 10GB, not a lot - but it did error. At the time I didn't think much of it and just assumed it had worked on the whole.
I have since run some scripts on the SQL through PGAdmin to report on the table sizes and all the main culprits were the 'time series data' tables - which if I'm honest I didn't know what they were for.
anyway, in a last ditch effort I ran the clear-performance-data script again this morning and it cleared out 80GB (and errored again), bringing my DB down to 100GB. However, looking at the table sizes again there were still a lot of 'time series data' tables with a lot of info in them. So I've run the script again and now my DB is 4.25GB! much more managable!!
So now I can increase my event rentention and once I've got my head around what - if any - performance data we require we can switch it on and tune it to what we need.
mystery solved, in the end by a lot of poking around and a bit of guess work.