On Thu, Nov 13, 2008 at 4:10 PM, Ron Foster at Baldor-IS <[EMAIL PROTECTED]> wrote:
> I have an NFS server that is serving up files to all of our Linux > systems running under z/VM. This is about 40 systems in all. This > system was upgraded to SLES10 Service Pack 2 last weekend. > > All has been going well this week until this morning. Our FDR/Upstream > backup of this system did not complete last night. This NFS server runs > in it's own LPAR. When I looked at top, it appeared that between the > backup program and a process called lockd, all CPU was consumed. I > killed the FDR/Upstream backup. It still appears that large amounts of > CPU time are still being used by lockd according to top. Without monitor data, I have to do more guessing than I normally do. But anyway... You probably have defined the virtual machines and LPAR with more than one virtual / logical CPU. As far as I recall, NFS uses the BKL and may be a bit rude in that aspect. So it's not unlikely your CPU cycles are spent spinning for the lock. Linux on z/VM implemented a trick to provide some relief in that aspect, but I have no idea whether that was also done in PR/SM. And if it was done, it will not cross the z/VM-LPAR boundary. The defaults for recent kernels also favor reduced latency over CPU efficiency, making Linux spin longer before giving up the CPU. This means that you have no external metrics when the Linux application is having lock contention and does not scale well. I would suggest trying to vary some of the CPU's offline in the system where lockd is using a lot. I suspect you will see the CPU consumption go away and the throughput go up (or at least not decrease). And I can't tell how you allocated your CPU resources between z/VM and the LPAR. When the utilization of the LPAR Linux is high enough to justify its own LPAR (imho the only reason to use LPAR) then you probably must not share all IFLs among the two LPARs. Rob PS As always we're happy to look at your monitor data to validate some of the assumptions and help you understand the issues. We can discuss that off-line since it is of little interest for the folks on the list. -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
