Bug 218146
| Summary: | NFS throughput low, high NFS util locks screen updates for a few minutes | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Saikat Guha <sg266> |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | rawhide | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-03-31 09:39:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Saikat Guha
2006-12-02 01:06:14 UTC
hmm... [incorrect TCP checksum] is a bit worrisome.... I would guess thats the cause of the slow down... So this is between a FC6 (or rawhide) client and a FC5 server? Correct. Between a rawhide client and a FC5 server. Switching NFS from TCP to UDP results in the same symptoms -- low throughput, intermittent display lockups, lots of idle CPU etc. yeah on a congested network, UDP would be worse... True, however, I can achieve the full network bandwidth using SCP or TTCP/IPERF etc. NFS seems to be achieving a factor of 5 less. In addition, intense NFS activity completely locks up Xorg for tens of seconds, sometimes several minutes -- no mouse cursor update, no panel clock updates, no system monitor graph updates etc. On the system, /home is mounted from a _different_ NFS server than the server to which the "high"-bandwidth transfer is taking place. / -- local /home -- FC1 NFS server A <---- home directory /mnt/nfs2 -- FC5 NFS server B <---- destination of large file copy The large background file copy to B should cause Xorg/gnome etc to freeze for minutes. The freeze is not observed when the copy to B is performed using SCP. Also, as mentioned, SCP bandwidth is much higher. If there is any sort of diagnostics you'd like me to run please let me know. Thanks. > True, however, I can achieve the full network bandwidth using SCP or TTCP/IPERF > etc. NFS seems to be achieving a factor of 5 less. Well there will always be much less protocol overhead with streams like that Plus the NFS client can go wire speed... I've seen it... I just noticed "NFS V2 WRITE Call" Why are you using v2? How does V3 using TCP work? > In addition, intense NFS activity completely locks up Xorg for tens of > seconds, sometimes several minutes -- no mouse cursor update, no panel clock > updates, no system monitor graph updates etc. Although NFS may contribute to it.... it very rare that NFS (or any other filesystem) causes mouses and displays to lock up... Try opening up another console terminal (Alt-Ctrl-F2) and run top to see who is graping your CPU... (In reply to comment #5) > Well there will always be much less protocol overhead with streams like that > Plus the NFS client can go wire speed... I've seen it... I've seen NFS at wirespeed as well (from the very same rawhide box to an FC1 NFS server for example). > I just noticed "NFS V2 WRITE Call" Why are you using v2? How does V3 using > TCP work? Hmmm. I don't recall setting it to V2; should be using the default. Will try to force it to V3. > Although NFS may contribute to it.... it very rare that NFS (or any > other filesystem) causes mouses and displays to lock up... Try opening > up another console terminal (Alt-Ctrl-F2) and run top to see who is > graping your CPU... Can't Ctrl-Alt-F2 (console is completely stuck) but can log into the stuck host from another host as mentioned in the original post; top shows 0% cpu and 0% io wait. Seems to be working well these last few months. Closing this bug for now. |