Wireless Access

We work with airwave 7.5.5 on a vmware server 24g 4cores (dell r710) and about 3000 ap twelve m3

When airwave running for some months the CPU and mem go very high and airwave gets slower and the visualrf engine goes down regulary.

after the reboot visualRF works a lot faster.

what can be the problem

A few things to check:

1. What's the memory allocation set to on VisualRF -> Setup?

2. How many floor plans?

3. What's the typical load of APs per floor plan?

4. How many clients are usually on a floor plan?

5. Are all resources of the VMware server allocated to AMP? (If not, what's the priority of the AMP VM?)

6. How's performance looking on System -> Performance tab?

This is a good start.  I also suggest opening a support case, and provide the /var/log/visualrf/visualrf.log so that they can parse through and search for errors.

Hello,

De anwser for the question are:

1. 512

2. about 200 floorplans (42 buildings)  growing in the next year to 135 building that same 1person to 3000 persons

3. how can i see this?

4. now about 5 to 30 growing to 5 100persons

5. yes

6. 

CPU hist

amp max 81% average 56%

VisualRF max 15 average 9.5%

Web Server max max 41,9 average 489.7m % ?

Mem

amp max 14GB ave 12GB

Kernel Buffer 612MB ave 500GB

Kernel Cache 15,7GB ave 3GB

Free 17.86 ave 1,6GB

Swap

user swap max 1GB av (40MB

Free swap 4Gb 3,0GB

When i see this reply i see that  the memory allocation not much is 512mb i think this must be a lot more, but how many.

Thanks for the fast response

Looks to me like you'd benefit by increasing memory allocation to VisualRF.  I'd suggest trying at least 3GB, and if you still see VisualRF going down, increase the memory more.  The amount of memory is more dependant on movement by clients, if your clients more more often, that requires more calculations.  The same applies to number of floor plans, with the number of floor plans you have being directly related to an increase in memory needed.  If your clients are fairly static, then you can get away with less memory.

As far as average numbers per floor, you can usual get that number by eyeballing the floor plan table on VisualRF -> Floor Plans (table below the map).

Rob Gin,

Thanks for your response.

I change the mem settings to 3gB en it works faster, i think this was the problem.

Thanks

Peter Otten

Rob Gin,

It now working fine for weeks. So i think the memory was the problem.

Thank for your advice

Thanks for the update, glad to have been of some help.  As your network grows, you can expect that you may need to raise the allocated memory for VisualRF again in the future.

Keep in mind that these numbers determine how much to allocate to VisualRF:

- number of buildings

- floor plans per building

- APs per floor plan

- clients per floor plan

- rogues / interferers per floor plan

There's currently no set guidance, but I'm looking into ways to possibly benchmark this in the future.

I have a question on this as well, and figure I'll extend the thread rather than open a new one:

When I set up Airwave, I set memory and all for each component which had guidance and gave the rest to VisualRF - figuring that it was the most variable nad likely the most needy.

Whenever I've had TAC help me with (what's always turned out to be a bug in VisualRF, and not my configuration) they've had me turn down the resourced I give to VisualRF. They never had good reasoning, always just "it doesn't need that much" or "it seems too high"

Is there a problem with giving VisualRF more than it needs? Sounds spurrious to me.

The answer depends on current thread settings on AMP Setup -> General tab -> Performance tuning box.  If you increase the numbers of Monitoring Processes, Config Processes, Audit Processes, and SNMP Fetchers - then you may or may not be able to have VisualRF at max allocation.  The reason is because memory marked for VisualRF is locked in java process.  Memory locked up in java is not available if the AMP process max out their threads, and in some cases reduces the allowed processing throughput.

This is the only case where I would expect a reduction of VisualRF to be the solution to a problem.  Typically, if you have your thread settings at default values, then you should be able to max out VisualRF allocation.  But if you tune your AMP to do more inbound processing, then you're going to want to make sure there's enough memory space for those processes to run.