Wireless Access

I am running AMP 7.6 and have ran out of drive space. We allocated 100GB and are running in a VM. It looks like the /pgsql directory is taking up the bulk of the space. Is there any way to reduce the size this takes? When I realized we were close to capacity I lowered the data retention period by half for most most of the categories, but the /pgsql directory took up another 20gb in a matter of 2 days. At this point, I'm unable to log back in to the GUI or get the services restarted. We have about 600 devices. Any help would be appreciated.

[root@txhoutel12 /]# df -h Filesystem            Size  Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00                        95G   90G     0 100% / tmpfs                 3.9G     0  3.9G   0% /dev/shm /dev/sda1              97M   36M   57M  39% /boot

[root@txhoutel12 lib]# du -h --max-depth=1
4.0K    ./ntp
8.0K    ./postfix
28K     ./iscsi
4.0K    ./games
1.2G    ./airwave
8.0K    ./lldpad
5.0M    ./mlocate
208K    ./rabbitmq
4.6M    ./yum
4.0K    ./dav
4.0K    ./pound
8.0K    ./dhclient
72G     ./pgsql
24K     ./nfs
12K     ./stateless
8.0K    ./udev
8.0K    ./alternatives
40K     ./authconfig
8.0K    ./plymouth
4.0K    ./rsyslog
38M     ./rpm
4.0K    ./misc
73G     .

MIchael,

Can you articulate what kind of devices you are using Airwave for as well as the deployment type? Are you storing multiple versions of device firmware locally? Your data retention policies are an excellent start. 80GB thick provisioning is the default for the VM install - you can at your discretion increase this upto the capacity of the shared hard disk, or even add additional drive space to the physical server and then resize the volumes for AirWave usage.

The pgsql structure is where all the client, device, rogue tables etc are contained so not surprising that it is the largest consumer of your drive space. Airwave provides a horde of client & device granularity which is hugely beneficial when doing triage and troubleshooting. That said - to provide this - it stores all this information locally on the pgsql db structures.

You can also check to validate your reporting settings as well as your nightly backups. Several choose to FTP those (backups) offsite so that operationally, Airwave has more disk space to use.

Note that when you make retention changes, it won't reflect in the deployment until the next nightly backup.

If you're not familiar with how to resize the VM disk or add a new disk to the platform, I can post a recent MoP I wrote for a customer (client specifics removed) to achieve the same result.

Hope that helps, Adam

What Historical Data Retention values are you using?  Changes to HDR values won't be reflected until the next day (clean up scripts are run at nightly maintenance).

Also, is there anything you can tell me about the clients in your environment?  Like are they 1 time clients that never return (hotspot/airport/retail), or are they reoccurring clients (corp/education/office)?  Based on the behavior, the number of rows maintained in the database will be directly affected.

Additionally, although we know that the database is the main disk space hog, we can go deeper to figure out which table comprises of the most data.  From the CLI, run:

# dbsize

This will let you know which table(s) are taking up the most disk space.  Depending on the table, different HDR or other tunables need to be set.