Airwave 1.5

[Mohammed Huberty]

Im currently using airwave to monitor 95 devices including visualRF and RAPIDS. Airwave is running in a virutal environment and we originally assigned it 4 gig of memory. I have noticed that it has become sluggish and it was consuming all 4 gig of memory.. We have now assigned airwave 6 gig of memory based on the AWMS sizing guide, however, it is now consuming all 6 gig of memory. It is incredibly slow and some pages won't load. Has anyone else experienced this or have any suggestions on what may be going on?

How does swap usage look? AirWave and Linux try to take advantage of all of the available RAM in order to cache things in memory, so as long as you're not dipping into swap space too much, you should be fine.

1. On the AMP Setup -> General page, you can configure the number of monitoring processes. Each of these processes will use a decent amount of memory, so it's important not to have too many when you're bumping up against a RAM limitation. For your size of deployment, I recommend setting that to 1.

I had this problem just today. Airwave GIU was very slow and client information was not accutate. The RAM and swap were both pegged. I called support and they found a process was hung and was holding onto over 80% of my memory. The process was Daemin::TupleScheduler. The support engineer made some adjustments and the problem seems to be solved. I'm not sure what adjustments he maid. It looked like just stopping and restarting the sevices and database. I had rebooted the server prior to calling support but that did not fix the issue.

Several days ago the client count in Airwave and the client count on the controllers stopped syncing up properly. I can't think of a change I did other than trying to implement AMON as a preferred method but have since went back to snmp. I'm still getting client information just not all of it. There's maybe a 2000 user difference. I think the snmp polling was timing out from Airwave (7.7.4) to the Controller but was wondering if anyone else has experienced something like this. I currently have a TAC case open but haven't gotten a resolution. I am using 6.3.0.0 on the controller and 7.7.4 on airwave and I upgraded to 7.7.4 on October 2nd.

We too are experiencing descrepancies between what AMP displays & what the controllers list, not just in client count, but also in a client's association table; the controller will say that a client has been connected for a few hours, where as AMP only lists an hour or less.

I just got off a 3.5 hour phone call w/ TAC looking at a number of AMP issues, mainly a slowness where it used to take 2-3 minutes for pages to refresh. We were able to solve that by restarting AMP services. The initial issue was that certain APs weren't graphing client count. We added a new 7240 controller to our beta group & migrated some 7 APs onto it. I noticed that no graphs were being displayed for the SSIDs. After a few hours on the phone w/ TAC we removed & re-added the devices (after restarting services, which did improve performance).

The devices are listed as up, however none of the SSIDs are listed in the graphs both for the newly re-added controller & for the APs associated w/ that controller. AMP does contain old data from the APs PRIOR to moving them to the new controller, however (thus far) any attempt to gather graph data from the APs & the newly re-added controller fail. Furthermore, none of the SSIDs in production are displaying in the pull down menus of the newly re-added controller & its APs.

I just wanted to update on our client count differences. As of right now, things look better - I worked with TAC to look into it a bit more and we changed the prefer AMON over SNMP values to No, that seemed to fix it.

I wasn't as lucky. I've been working with TAC since I posted the message. I have turned off AMON everywhere adjusted the polling times and even put the controller in the same network as airwave. This morning I disabled rogue detection on the controller group but I'm still missing 2000 or so clients on Airwave.

I found several triggers that were added and once removed the problem was resovled but not with the amon preferred to snmp option enabled. I was told that shouldn't cause the problem so TAC is going to be taking a deeper look.

Once disabling "prefer Amon vs SNMP Polling" the issue seems to have disappeared. It was not instantaneous however, it wasn't until probably 12 hours after changing this setting that things started to normalize.

I have 60 clients on AMP while 4 on the controller and the client location never worked when clients are actually connected to the wireless, it would look like every AP has it's clients on top of the AP regardless of where they are physically.

I actually thought that AMON is aruba "proprietary" to increase location accuracy?? wounder whey it isn't working with Aruba wireless. I should mention that when I installed AMP, I have it configured using Aruba best practices for configuring Airwave server(downloaded for the support site).

For what it's worth, the last response we received from TAC was that the user count in Airwave with AMON enabled was including unauthenticated users in the station table and that is why the numbers were skewed.

As far as I can see we're well within the hardware sizing guide for our AP deployment. However AMP is struggling. It's using all the available ram most of the time and then hitting swap so there are times the system starts to thrash.

In addition to the already suggested system performance values, how much RAM is allocated specifically to VisualRF (see VisualRF -> Setup -> Memory Allocation)? This is RAM set aside for VisualRF use only.

Do you have any large memory consuming features in use? AppRF, UCC, IGC (instant gui config), large report runs (monthly/yearly - if you do run such reports, it's best to run them at times when the network is not at peak)

Today we've disabled UCC and AppRF to see what happens. Currently it's looking OK, having forced restart httpd RAM use is at 20GB and slowly climbing. I'll give it a couple of hours and see what happens.

Current thoughts are a presumption that the switch to 6.4 on the controllers has thrown a lot more data at airwave. Of course this could still be a bug as we wouldn't expect everything to completely max out, especially as we appear to be within the sizing guide.

So far the only change we can think of that was made between healthy Ram usage in December and the problems starting in January was the adding of more VisualRF floor plans. But we don't have all that many to be honest, and VisualRF has 10GB assigned to it so it should be using more than 40GB.

I used the 8.0.7.1 version and yesterday updated to 8.0.9.1 also used the best pratices of version 8.0 which mattered. Yesterday here the behavior is normal and will observe anything will do as Joseph recommended. I appreciate the comments

I have since upgraded by AOS 8 environment to 8.5.0.9 - since this Airwave no longer displays and shows connected clients even though I can see them on the MM and the MDs. The controllers are showing as up in Airwave so I am not sure why it isn't able to see or display the clients. Has anyone else experienced this and know how to fix?

You should re-enter the snmp read string on Airwave for the controller. That is the main way Airwave determines if a device is up and how many clients it has on it. If you have double-checked that, I would open a TAC case.

We can first check under Configuration --> System --> Airwave section on the Controller whether Airwave is defined(mostly this should create and map the AMON profile to Airwave IP). Also, make sure the default amp profile is mapped to Airwave IP on the controller.

Ah found it under the show mgmt-servers and it confirms that it is mapped correctly to the IP of airwave server.

Strange thing is I am getting some clients updating and have been. But it sitll says there are 4 clients on my controller whenever there is in fact 18.

3a8082e126