Tag Info

Hot answers tagged

6

you can try to use iostat to pin down which device generates the i/o wait: # iostat -k -h -n 5 see the iostat man page for further details. nfs is often part of the problem especially if you serve a large number of small files or have particular many file operations. you can tune nfs access by using the usual mount options like rsize=32768,wsize=32768. ...


4

First, NFS does not provide cache coherency, so if you need that, you must look elsewhere. What NFS specifies is a weaker model called close-to-open consistency. Meaning that when a file is closed, any dirty data are flushed to the server. Conversely, when a file is opened, an attribute check is performed, meaning that if the client has cached pages from ...


4

NFS 4.1 (minor 1) is designed to be a faster and more efficient protocol and is recommended over previous versions, especially 4.0. This includes client-side caching, and although not relevant in this scenario, parallel-NFS (pNFS). The major change is that is that the protocol is now stateful. ...


3

First of all, I'd use an actual I/O benchmark utility such as 'iozone'. It'll test a variety of things and will even use O_DIRECT if flagged to do so. And even, as I recall, has some NFS-specific flags. One thing I've found to be very reliable is to use a file-size that exceeds the RAM size for the device you're testing on. This busts the cache, and gives ...


2

This only depend about what you want to measure. You just forgot to define your goal. If you want the NFS cluster raw performances, then you have to bypass your RAM. If you want "real world" performances, then you have to use your RAM. But real world I/O are rarely those from dd. You will have better results with iozone for example. So define your goal. ...


2

You're definitely thinking on the right lines, but in my experience, shared-storage on virtual machines is rarely performant, so I doubt i'd actually go down the NFS route in this instance. The biggest disadvantage would be the Single Point Of Failure surrounding NFS atop EBS, which might prove quite tricky to mitigate. In a non-virtual datacenter, I'd use ...


2

The NFS {r,w}size defined by client mount option and/or server capabilities. IOW, you can define them on command line like: # mount -o rsize=1048576 ..... Linux client have different default values for v3 and v4 - 32k and 1MB. The nfs server may request a smaller or can support bigger sizes. You should be able to see that with wireshark as FSINFO call for ...


2

You should try the noatime option when mounting the remote filesystem in the client. From man 8 mount noatime - Do not update inode access times on this filesystem (e.g., for faster access on the news spool to speed up news servers). In my case, it improved write performance a lot.


2

By setting up a central NFS server you introduce a single point of failure into your design. That alone should be a deal breaker. If not, NFS can be plenty fast enough for a load like this. The critical factors will be having enough RAM to cache files, low latency interconnections (Gig-E or better), and tuning (less so than the previous). You should also ...


2

The answer is... no. The script is called on the m1.medium instance, so the CPU there serves that script. The NFS server running on the high compute instance will consume some CPU, but minimal. What youve said is sound.


1

The first thing I would do is set the retrans option to 1 (or 0, but I don't know if that will work as expected). This should lower the time it takes to actually timeout


1

Configuration: Try to export using async instead of sync. This way you won't be waiting for acknowledgment of each command issued (think of the impact this may have to data integrity in your situation). Networking: Make sure both links are running full-duplex and that jumbo frames are enabled throughout your network if possible. Make sure all devices and ...


1

The answer turned out to be an error on the RAID card. Sorry for the inconvenience. I write because of the slim possibilty that someone else might hit something similar. To recap: build duration slowed down by a factor of ~3, and the duration was consistent +/-10%, hence suggesting that load wasn't the primary factor.


1

You could handle this at your NFS server by bonding the connection (see: Link Aggregation). Use multiple links on the server side to make more bandwidth available for clients. The details of the implementation depend on what's actually running NFS, but that's somewhere to start.


1

I would advise against NFS unless you put some Caching in there. The nginx cache is better than nothing, but Varnish is better. With that said, if your load would change to be more dynamic content than static, it will become more important to serve apps files from local disk. If you put NFS in, make sure that you have redundancy.


1

The speed depends on many factors: How are your servers going to be connected against the NFS target? A single dual-port SAS disk can utilize 6gbit/s of transfer speed. Keep this in mind if you're planning to use 1gig Ethernet (which you can subtract 20% TCP overhead from). What kind of cache is the NFS server going to get? Are you using a enterprise grade ...


1

AFAIK RTT is the server response time, e.g. from the time the client sends a read/write request until it receives an ack from the server saying "thanks, got your request, putting it on the queue". exe is the entire time from the sending of the request until IO has been done and copied to/from the client. Depends. We have some fairly loaded NFS servers with ...


1

a simple file copy operation, running in a few instances should be enough. if you want even more, I'd run dd if=/dev/zero of=/path/to/nfs_mount/filename bs=$blocksize count=$amountOfBlocks Knowing the NFS params should provide the blocksize to be used, you can play with those. To really saturate it, I'd run a few of those dd's simultaneously


1

So you've got mirrored NFS servers and some mechanism for keeping them in sync using rsync? This is a recipe for problems. It also implies that you've got a homegrown script trying to keep it all working. Certainly NFS is the last of your problems. Ideally, you should consider using a shared storage backend with a cluster filesystem e.g. GFS). Alternatively ...



Only top voted, non community-wiki answers of a minimum length are eligible