There are two kinds of memory on the Steelhead appliance: Real and virtual. Real memory comes from the DIMM memory sticks inside the appliance and is fast, virtual memory comes from an allocated slice on the hard disks and is slow. The process of moving memory from the real memory to the virtual and vice versa is called paging.
If paging is happening, it means that the processes needing its memory will have to wait before it is served and that other processes will start to page too. Thus: Active paging is a bad thing and a source of slowness.
Under normal circumstances, there should be no virtual memory in active use. The following exceptions will be there:
On the 3RU xx50 series models like the 5050 and 6050 models, a part of the virtual memory allocated for the copy of the USB flash memory. However, it will not be actively used: No paging in and paging out should be happening except during times when there are write operations to the USB flash disk.
On the 50, 100, 200 and 300 models the memory is very tight, under normal operations there is only 2-3 Mb of memory free. When logging in to the Steelhead appliance it will start to swap to rearrange the memory and this will cause paging.
The memory on the Steelhead appliance is used in several ways:
Used by the optimization service.
Used by the operating system.
Used by the non-optimization processes.
Used by the RSP service.
The optimization service takes up most of the memory on a Steelhead appliance. For example on a 1050L model with 2 Gb of memory, the optimization service aka the process sport will use 1.3 Gb of it.
When monitoring the memory usage on the Steelhead appliance via SNMP, you will see that the the memory usage on the Steelhead appliance is very high, often above 80%: This is normal.
During the startup of the optimization service, it will allocate a pool of memory which it will use to allocate internal memory structures used by the optimized TCP sessions. For example these structures are for the general TCP optimization, the CIFS read-ahead buffers and the objects for the HTTP optimization. The memory allocated by the optimization service is marked as "non-paging", which means that it will never be paged out to disk.
If coded properly, every object allocated will be released later. If not, a piece of memory will be lost. If this happens too often, this pool of memory will be exhausted and the optimization service will be entering memory based admission control. When this happens, please open a case with Riverbed TAC to investigate.
The only way out is to restart the optimization service, but don't do this until Riverbed TAC has the data required.
The memory usage by the operating system is not directly identifiable but there are two usages which can be observed: The network buffers and the disk buffers.
If the operating system runs out of network buffers, the optimization service will enter TCP based admission control. This scenario is described in the Admission Control section.
If the operating system runs out of disk buffers, it will become slow at reading from and writing to disk. This can happen when a large amount of brand new, compressed or encrypted data comes through: The data store has to be searched for matching references, but they cannot be found. Furthermore the data store will be written to the whole time. This constant reading and writing will exhaust the disk buffers and cause slowness on the system.
The non-optimization processes use the rest of the memory. Unless there is a memory related issue and paging is happening, they should all run inside the real memory. If however for some reason the Steelhead appliance is running out of memory and paging start happening, these are the processes which will be paged to disk.