Professional Documents
Culture Documents
Virtual Memory Management - Tuning Parameter: Lru - Poll - Interval AIX 5.3 ML1+ or AIX 5.2 ML4+
Virtual Memory Management - Tuning Parameter: Lru - Poll - Interval AIX 5.3 ML1+ or AIX 5.2 ML4+
Virtual Memory Management Tuning Parameter: lru_poll_interval AIX 5.3 ML1+ or AIX 5.2 ML4+
Barry J. Saad Harold R. Lee
6/1/2006
lrud starts with a request for memory and calculated goal and runs to completion before reenabling interrupts.
tio n
1-
Po pT im er
Handle the timer event: lrud stops working - polls and processes interrupts.
ll Po
s es 2 roc P n & ur et -R 3
6/1/2006
Advanced Technical Support - pSeries Virtual Memory Manager Tunable Parameter: lru_poll_interval
The lru_poll_interval parameter was introduced at ML4 of AIX5L 5.2 and ML1 of AIX5L 5.3. The parameter tells the page stealer lrud whether it should stop working and poll for interrupts or continue processing until the current request for free frames has been satisfied. The process starts when the VMM needs memory and the lrud process starts running to steal memory. During the process the VMM will determine how many pages it needs to steal, including enough pages to get above maxfree. Remember the lrud will run under the following conditions: 1. 2. 3. The number of frames on the free list drops below minfree. Hard limit on either maxperm and/or maxclient. The hard limit is set with strict_maxperm and strict_maxclient to 1. A Workload manager trigger is hit.
maxperm and strict_maxclient numperm minperm numclient maxclient and strict_maxclient lru_poll_interval
Tuning Options By setting lru_poll_interval = 0, youre telling lrud not to poll. By setting lru_poll_interval =10, youre telling lrud to poll every 10 msecs (default). By setting lru_poll_interval = x (1 60000), youre telling the lrud to stop working every x msecs and poll and process any interrupts.
6/1/2006
Advanced Technical Support - pSeries Virtual Memory Manager Tunable Parameter: lru_poll_interval
When does this value need to be tuned? The reason to change the default value is that youve decided and/or determined that the lrud is blocking interrupts, which is having a negative impact on system performance. So how can we make this determination? Monitoring with vmstat, if you have activity in the sr - scan and fr free columns, which indicates that lrud is running. Now, interrupts are not block during the entire time lrud is running the daemon starts and stop numerous times as individuals requests are made. Also, keep in mind that your system may have multiple lrud to manage each memory pool. lrud is a threaded application use the ps o THREAD p <lrud_pid> to determine how many threads are running. Monitoring with tprof, you notice that lrud is running. Monitoring with filemon, you notice that you have longer than normal read response times at the physical layer. Particularly true if you can correlate to lrud running Monitoring with trace, you notice a long time between the physical device start and the physical device iodone. Check the iodone hook, which will include a end timer, if available. If you dont get an end timer value the corresponding start event was most likely missed.
221 dd 221 dd 0.076764604 0.080413470 0.001664 0.001818 SCDISKDD iodone: rhdisk1 bp=F10001195007F400 B_READ B_AGE [13554 usec] SCDISKDD iodone: rhdisk1 bp=F10001195007AC00 B_READ B_AGE
When tuning increase and decrease the value in 2-5 msec increment and note the external performance impact. Finally, as with all tunable parameter changes, you should note the behavior of the system before and after the change- in this case I would use vmstat. If performance improves leave the parameter as set. If performance degrades return the parameter to the original value. Remember, it is not uncommon to pass the optimal point in the tuning process, when you do - dial back the last set of changes and take a baseline snapshot using the the vmo a or vmo -L command.
6/1/2006