LSO AND SYSTEM MEMORY
Several problems with LSO have been attributed to low system memory. LSO has been given the ability to deal with low memory situations through the configuration mechanism. Four system parameters will have an affect on LSO in a tight memory situation.
System parameters have been used due to the way the operating system handles memory use. Currently it is difficult to predict from within LSO where performance will degrade significantly. Due to high performance demands, LSO cannot spend the large amount of time it would take to analyze the current memory situation since it can change within milliseconds.
Exhausting system memory can be caused by transferring data at a rate beyond currently supported data rates, or by other processes consuming memory. LSO has several protective mechanisms built in to prevent low memory from being a problem.
Prior to allowing a low memory situation, LSO will attempt to slow the rate of data transfer to allow recovery. If this does not work, LSO reacts to low memory in one of two ways. If a memory request cannot be met, LSO will reset all the channels, and clear all the queues. This should free enough memory to run, but is not guaranteed to do so. If the request still cannot be met then LSO will return all its memory to the operating system by terminating itself and starting a new session from scratch.
The total amount of memory available to LSO is dependent on how much virtual memory, not physical memory, is available. In low memory situations the operating system will swap memory to disk to make room for current requests. If large amounts of memory are swapped to disk this will cause severeperformance problems while the operating system attempts to use memory that is not currently available in RAM. You can affect how LSO reacts to low memory situations using the following parameters.
The largest consumption of memory by LSO is for packet buffers used to store incoming and outgoing packets. This parameter will specify how large the memory units are that LSO requests from the operating system to store these packets. If you specify QUEUEBLOCK=1 then LSO will be able to request approximately 500K of memory from the operating system before running out. Each increment of 1 increases this by approximately 500k. The amount of memory is variable since other applications could consume memory and make the figure lower.
The MAXQSIZE parameter can also affect the way LSO will react to low memory situations. The lower this number is set the sooner LSO will enter into low memory operations and reset its channels. You normally do not want this to happen, so this number should be set high enough to absorb peak traffic loads. This number indicates the maximum number of packets allowable in each packet queue.
The SETPOINT parameter determines when LSO attempts to take corrective action if the rate of incoming or outgoing data packets is higher than LSO can support. LSO can react to bursts of activity and recover but cannot absorb excess traffic beyond what current memory reserves allow. The more reserve memory you have, the higher this parameter can be set. The parameter measures the amount of packets allowed to be queued for processing prior to taking action to recover. If it is set lower, LSO will slow itself down sooner in an effort to prevent overload. The acceptable range would be 1 to 8000 which is the maximum number of packets allowed in the queue. Suggested values would range from 40 to 500.
The SUSPENDSET time is used when the SETPOINT is reached. This parameter replaces the cyclesuspend time during high load situations. The higher this value is set the slower LSO will run. It should be set higher if the amount of points changing is very high. Suggested values would range from 1000 to 8000. Both the SETPOINT and the SUSPENDSET value affect memory use in that they prevent the packet queues from overflowing and consuming memory. It is preferable to control LSO in this fashion since LSO must reset itself if a low memory situation occurs.