High Load average no CPU utilization
steve at bluehost.com
Wed Mar 28 16:49:08 MDT 2007
If the other boxes are working fine with nfs, it probably isn't the
number of nfsd processes running (though you can change that in
/etc/sysconfig/nfs with the RPCNFSDCOUNT setting, default is 8).
Again, I would make sure it can actually get cat the files from the
fedora box during the higher load times, make sure the mount isn't
stale, that the network is performing correctly (forced NIC and
switchport rather than auto, check with netstat -in for interface
errors), and even make sure to force the nfs mount rather than assume
the defaults (BSD may default to a larger window, etc, etc).
None of these are certain, but places worth checking.
adam fisher wrote:
> This is the mount statement for our BSD boxes and the fedora box.
> 10.11.1.91:/data/online /mnt/online nfs rw,port=2049,intr 0 0
> We then have a /online ->/mnt/online
> Fedora says the default is v2.
> I am not sure what the 0 0 are doing at the end of the mount but they were on the freebsd boxes so I just left them.
> Is there away to make sure that we are allowing enough connections on the NFS server?
> let me know what you see.
> ----- Steve Alligood <steve at bluehost.com> wrote:
>> it may be HOW you are mounting it, and how fedora versus BSD defaults
>> mount it.
>> nfs v2 will be really quick, but not as reliable for data writes (aka,
>> nfs v3 will be more reliable (tcp) but slower
>> nfs v4 will be reliable (tcp) and secure (encrypted) but a lot slower
>> Fedora may default to v4 while your BSD does v3 or v2.
>> I have some mounts I use nfs v2 because I am not as worried about
>> and I need the speed. I also change the read and write window sizes,
>> and turn off atime checking:
>> Of course, the server must support the v2 nfs as well (obvious, but
>> worth mentioning)
>> adam fisher wrote:
>>> I appreciate everybody's thoughts on this.
>>> I agree that the NFS looks to be the bottle neck however we have 5
>> other load balanced web servers that are pulling the web data from our
>> NFS server. We mount the partition and then created sym links to
>> those mounts. The other 5 web boxes are up and running fine. It is
>> the sixth alone that is having this issue.
>>> The first 5 are BSD this is a Fedora installation as we want to get
>> away from BSD.
>>> Any other ideas?
>>> ----- Ryan Simpkins <plug at ryansimpkins.com> wrote:
>>>> On Wed, March 28, 2007 11:44, adam fisher wrote:
>>>>> apache 17268 0.7 0.6 29552 12868 ? D 04:27 0:04
>>>>> apache 17456 1.1 0.6 29728 13168 ? S 04:27 0:06
>>>>> apache 17890 0.5 0.6 29928 12588 ? D 04:28 0:02
>>>>> apache 17893 0.0 0.5 29032 11548 ? D 04:28 0:00
>>>>> apache 17895 0.0 0.5 29184 11716 ? D 04:28 0:00
>>>>> apache 17896 0.0 0.5 28740 11256 ? D 04:28 0:00
>>>>> apache 17897 0.0 0.5 28912 11452 ? D 04:28 0:00
>>>>> apache 17904 0.3 0.5 29288 11876 ? D 04:28 0:01
>>>>> apache 17913 0.5 0.5 29316 11892 ? D 04:29 0:02
>>>>> apache 17923 0.1 0.5 29364 12052 ? D 04:29 0:00
>>>>> Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s
>>>> avgrq-sz avgqu-sz
>>>>> await svctm %util
>>>>> sda 0.00 11.00 0.00 6.00 0.00 136.00
>>>> 22.67 0.00
>>>>> 0.50 0.17 0.10
>>>>> The web root is located on an NFS share. I restarted NFS on this
>>>> box just to make
>>>>> sure. When I restart httpd and the load average drops to around
>>>> or 11 I can
>>>>> browse the webpage just fine. It is when it gets to around 150
>>>> I can't.
>>>> Bingo. Your web root is running over NFS. NFS is pure evil for
>>>> type of work.
>>>> You may be able to improve performance playing around with the
>>>> NFS mount
>>>> PLUG: http://plug.org, #utah on irc.freenode.net
>>>> Unsubscribe: http://plug.org/mailman/options/plug
>>>> Don't fear the penguin.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
Url : http://plug.org/pipermail/plug/attachments/20070328/86919116/attachment.bin
More information about the PLUG