From: Avi Kivity <avi@argo.co.il>
To: fitzboy <fitzboy@iparadigms.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: tuning for large files in xfs
Date: Tue, 23 May 2006 11:05:48 +0300 [thread overview]
Message-ID: <4472C25C.2090909@argo.co.il> (raw)
In-Reply-To: <447259E7.8050706@iparadigms.com>
fitzboy wrote:
> >
> > What's your testing methodology?
> >
>
> here is my code... pretty simple, opens the file and reads around to a
> random block, 32k worth (note, doing a 2k read doesn't make much of a
> difference, only marginal, from 6.7ms per seek down to 6.1).
>
> int main (int argc, char* argv[]) {
> char buffer[256*1024];
> int fd = open(argv[1],O_RDONLY);
> struct stat s;
> fstat(fd,&s);
> s.st_size=s.st_size-(s.st_size%256*1024);
> initTimers();
> srandom(startSec);
> long long currentPos;
> int currentSize=32*1024;
> int startTime=getTimeMS();
> for (int currentRead = 0;currentRead<10000;currentRead++) {
> currentPos=random();
> currentPos=currentPos*currentSize;
This will overflow. I think that
currentPos = drand48() * s.st_size;
will give better results
> currentPos=currentPos%s.st_size;
I'd suggest aligning currentPos to currentSize. Very likely your
database does the same. Won't matter much on a single-threaded test though.
> if (pread(fd,buffer,currentSize,currentPos) != currentSize)
> std::cout<<"couldn't read in"<<std::endl;
> }
> std::cout << "blocksize of
> "<<currentSize<<"took"<<getTimeMS()-startTime<<" ms"<<std::endl;
> }
>
> > You can try to measure the amount of seeks going to the disk by using
> > iostat, and see if that matches your test program.
> >
>
> I used iostat and found exactly what I was expecting: 10,000 rounds x
> 16 (number of 2k blocks in a 32k read) x 4 (number of 512 blocks per
> 2k block) = 640,000 reads, which is what iostat told me. so now my
> question remains, if each seek is supposed to average 3.5ms, how come
> I am seeing an average of 6-7ms?
>
Sorry, I wasn't specific enough: please run iostat -x /dev/whatever 1
and look at the 'r/s' (reads per second) field. If that agrees with what
your test says, you have a block layer or lower problem, otherwise it's
a filesystem problem.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2006-05-23 8:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-22 18:57 tuning for large files in xfs fitzboy
2006-05-22 19:15 ` Avi Kivity
2006-05-22 19:32 ` fitzboy
2006-05-22 19:36 ` Avi Kivity
2006-05-23 0:40 ` fitzboy
2006-05-23 8:05 ` Avi Kivity [this message]
2006-05-23 20:21 ` fitzboy
2006-05-24 8:12 ` Avi Kivity
2006-05-22 22:22 ` Miquel van Smoorenburg
2006-05-22 22:30 ` Matheus Izvekov
2006-05-23 0:42 ` fitzboy
2006-05-23 1:07 ` Matheus Izvekov
2006-05-22 22:51 ` Nathan Scott
2006-05-23 0:49 ` fitzboy
2006-05-23 1:59 ` Nathan Scott
2006-05-24 1:41 ` fitzboy
2006-05-24 2:23 ` Nathan Scott
2006-05-25 19:15 ` fitzboy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4472C25C.2090909@argo.co.il \
--to=avi@argo.co.il \
--cc=fitzboy@iparadigms.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.