We just moved a user, who deals with a *lot* of data, to a new server,
since his old NFS home directory was on a disk that had started showing
problems.
Now, i/o is about six times slower, my manager reports.
After a fair bit of googling, I started looking at tc and ip, and found
the following: from ip address show, first, on the old home directory
server,
eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
then, on the new:
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
I've tried tc qdisc add dev eth0 mq pfifo_fast
and
tc qdisc add dev eth0 pfifo_fast
and neither works. I've googled, and seen something about you can't set
something with tc, because pfifo_fast is the hardwired default.
Anyone know how I can reset this, or is there a package I can reinstall
that would do that?
mark
From: "m.roth at 5-cent.us" <m.roth at 5-cent.us>> I've tried tc qdisc add dev eth0 mq pfifo_fast > and tc qdisc add dev eth0? pfifo_fast > and neither works. I've googled, and seen something about you can't set > something with tc, because pfifo_fast is the hardwired default.Not an expert, but this seems to add 'mq' succesfully on my unused eth1: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 # tc qdisc add dev eth1 root handle 1: mq eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000 But it fails for 'pfifo_fast': # tc qdisc add dev eth1 root handle 1: pfifo_fast qdisc 'pfifo_fast' does not support option parsing Also, maybe you need to delete before adding? JD
On 03/01/2012 08:15 AM, m.roth at 5-cent.us wrote:> We just moved a user, who deals with a *lot* of data, to a new server, > since his old NFS home directory was on a disk that had started showing > problems. > > Now, i/o is about six times slower, my manager reports. > > After a fair bit of googling, I started looking at tc and ip, and found > the following: from ip address show, first, on the old home directory > server, > eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000 > then, on the new: > eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > > I've tried tc qdisc add dev eth0 mq pfifo_fast > and > tc qdisc add dev eth0 pfifo_fast > > and neither works. I've googled, and seen something about you can't set > something with tc, because pfifo_fast is the hardwired default. > > Anyone know how I can reset this, or is there a package I can reinstall > that would do that? > > mark > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centosAre you sure your performance problems are network related? Have you measured performance of the filesystems on the two servers? You may have a data alignment problem with your disk partitions. Nataraj
(Sorry 'bout the screwed-up headers - forwarded to my work email from home, then forwarded back to this account just now....) ---------------------------- Original Message ---------------------------- From: John Doe <jdmls at yahoo.com> References: <76baacf79f928a056c17d63f02d53ae7.squirrel at mail.5-cent.us> <1330619990.16821.YahooMailNeo at web114705.mail.gq1.yahoo.com> <86feb08093663823b4190d6fae1e3a3b.squirrel at mail.5-cent.us> From: "m.roth at 5-cent.us" <m.roth at 5-cent.us>> Yeah: after I tried to add it, and it gave me the "does not support > options parsing", I began trying to del the mq, but I can't seem to > find the Magical Syntax (tm) that let's me get rid of that.This worked for me... # tc qdisc del dev eth1 root handle 1 That works... but won't get rid of mq. Right now, I'm trying pfifo, unless someone thinks that PRIO might be better. The real question is why *some* of my 6.2 boxen have pfifo_fast, and others have mq. Does anyone know where this is set? mark
Nataraj wrote:> On 03/01/2012 08:15 AM, m.roth at 5-cent.us wrote: >> We just moved a user, who deals with a *lot* of data, to a new server,since his old NFS home directory was on a disk that had started showing problems.>> >> Now, i/o is about six times slower, my manager reports.<snip> Ok, more info: at this point, it seems obvious that it's an NFSv4 problem, not a network problem: I've created /scratch/foo, exported it, and mounted it on the same machine at /mnt/foo. I then cd to that directory, and unpack a large file which is located in a user's home directory which is NFSv4 mounted. In a native directory, takes about a minute; when I cd to /mnt/foo and do it, it takes about 6.5 min. I've tried setting wsize and rsize to 1M; I've tried noatime, which someone in a post said helped, and nothing I do makes more than a second or two's difference. Clues for the poor? mark