From: Jos Houtman <jos@hyves.nl>
To: Yiannis Mavroukakis <jander@darthvader.us>
Cc: reiserfs-list@namesys.com
Subject: Re: improving Reiserfs Performance
Date: Wed, 25 May 2005 18:24:15 +0200 [thread overview]
Message-ID: <4294A6AF.10502@hyves.nl> (raw)
In-Reply-To: <42949FDF.8000406@darthvader.us>
Yiannis Mavroukakis wrote:
> Jos Houtman wrote:
>
>> Yiannis Mavroukakis wrote:
>>
>>> Jos Houtman wrote:
>>>
>>>> Hello list,
>>>>
>>>> First of all, We are a website that provide picture albums to its
>>>> users.
>>>> At moment we host almost 2 million, which are served in 5 different
>>>> formats from icons to 700x500.
>>>> We store all there files on our NAS server and serve these with
>>>> SQUID proxys.
>>>>
>>>> But we are having performance problems, and I'am orientating myself
>>>> for possible fields of improvement.
>>>>
>>> [snip]
>>> Have you considered the fact that your bottleneck may be over NFS?
>>>
>>> Y.
>>
>>
>>
>> I most certainly did, and it is a problem, but iam trying to work my
>> way bottom up.
>> It's a bit hard to say anything about NFS performance while the
>> filesystem/disks
>> could be causing the majority of the delays.
>>
>> After i did my best on the this level i intend to look at NFS in more
>> depth, but any hints/tips you allready have are welcome.
>>
>> jos
>>
>>
> ReiserFS actually performs the best under heavy hammering and
> thousands of files IMHO ;)
This i acknowledge, it proved to be alot better then ext3.
> Changing to RAID10 will improve performance
> Reiser4: again IMHO not yet, although your site would make a nice test
> bed :)
> Have you done any localised (i.e. not over a network) testing on the
> filesystem? If not, you'll be stabing in the dark for reasons, at
> least in my book.
Not yet, we have a spare machine on which i can run some localised
tests, but iam still copying the backup to it.
I did try some public available performance tests but since I can not
tailer it enough to our situation i dont consider the results reliable.
Iam thinking about making a perl scripts that does the following:
- forks an x number of times. Where X would represent the number of nfsd
daemons or maybe the nr of clients.
- each forks requests a number of random images.
I could simply measure the number of files openen, and the data read
divided by the execution time.
but i haven't gotten around to writing it yet.
something to give an indicator though, currently iam scanning through
some directory's in a while loop doing a bash file exists test [ -e ] to
detect which files are missing (we had some trouble yesterday). iam
doing this on the live system during peak hours.
though vmstat indicates that it reads an avarage 400 blocks per second
which is quite low i think.
On the other machine to which iam currently copying the backup from a
usb drive. i get about 14000 blocks per second.
> Do you have a stock kernel or have you 'custom' compiled yours?
I have a custom kernel with the latest 3ware drivers.
not necessarily truly optimized, iam no expert (yet).
Another thing i though of was trying another IO scheduling technique.
I remember reading in the kernel documentation that the deadlock
scheduling could give a better performance when using read 10.
does anybody have experience with this? or seem some performance testing
with it?
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
next prev parent reply other threads:[~2005-05-25 16:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-25 12:54 improving Reiserfs Performance Jos Houtman
[not found] ` <4294783C.5040001@darthvader.us>
[not found] ` <42947BCA.9080702@hyves.nl>
2005-05-25 15:55 ` Yiannis Mavroukakis
2005-05-25 16:24 ` Jos Houtman [this message]
2005-05-25 17:22 ` ReiserFS on large-scale flash Artem B. Bityuckiy
2005-05-25 17:31 ` Hans Reiser
2005-05-25 17:33 ` Artem B. Bityuckiy
2005-05-26 0:36 ` improving Reiserfs Performance John Dong
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=4294A6AF.10502@hyves.nl \
--to=jos@hyves.nl \
--cc=jander@darthvader.us \
--cc=reiserfs-list@namesys.com \
/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.