All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manuel Krause <manuel.krause@mb.tu-ilmenau.de>
To: Naoki <naoki@valuecommerce.ne.jp>
Cc: reiserfs-list <reiserfs-list@namesys.com>
Subject: Re: Getting very interesting - Poor read performance
Date: Fri, 08 Nov 2002 01:48:34 +0100	[thread overview]
Message-ID: <3DCB09E2.8040206@mb.tu-ilmenau.de> (raw)
In-Reply-To: 3DCB03E6.7040602@valuecommerce.ne.jp

Hi Naoki and all others!

I like your kind of testing very well!

But, mainly, kernel 2.4.2 (??? really ???) is very very outdated in 
terms of reiserfs bug fixing activities in the recent past. Maybe the 
earlier bugs made some speed advantages due to missing checks. ;-)

You may want to try stock kernel 2.4.19 that was basically really fast 
itself with reiserfs and safe! Apply the fixes from
   ftp://ftp.namesys.com/pub/reiserfs-for-2.4/2.4.19.pending !

When you want to try the additional reiserfs mount option "notail" you 
could get another speedup. Then you should rebuild your original disk 
content (copy to a spare partition and copy back, e.g.).

If you want to exaggerate speedups try the data-logging patches from 
Chris Mason for 2.4.19 to be found in the base directory
   ftp://ftp.suse.com/pub/people/mason/patches/data-logging
(Then some original reiserfs patches (namesys ones) won't apply 
afterwards - skip them by trial and error)

Best wishes,

Manuel


On 11/08/2002 01:23 AM, Naoki wrote:
> Aha, very good point.
> 
> Now strace'ing the 'wc' I see the same on both servers. Just a bunch of 
> 'read'
> sys calls.
> 
> So why would 'read' generate such a different user time on the two machines?
> 
> Trying some tests with larger files in where the problem becomes far 
> more evident:
> 
> 'New' box :
> 
> # wc -l bigfile
> 
>  290314 bigfile
> 
> real    0m23.047s
> user    0m16.072s
> sys     0m0.348s
> 
> # mount
> /dev/sda3 on / type reiserfs (rw,noatime,nodiratime,nolog)
> 
> # strace -c wc bigfile
> execve("/usr/bin/wc", ["wc", "bigfile"], [/* 23 vars */]) = 0
> 290314 3127604 40121984 bigfile
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  68.33    0.104694          43      2453           read
>  31.51    0.048270          76       637           write
>   0.07    0.000113           9        13         7 open
>   0.02    0.000029          10         3           munmap
>   0.02    0.000028           7         4           mmap2
>   0.02    0.000025           5         5           old_mmap
>   0.01    0.000020           3         6           fstat64
>   0.01    0.000013           2         6           close
>   0.01    0.000010           3         4           brk
>   0.00    0.000005           5         1           mprotect
>   0.00    0.000004           4         1           uname
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.153211                  3133         7 total
> 
> 
> 
> Old box :
> 
> # time wc -l /root/bigfile
>  290314 /root/bigfile
> 0.68user 0.09system 0:00.86elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (114major+19minor)pagefaults 0swaps
> 
> And again :
> 
> [root@banner23 logs]# strace -c wc /root/bigfile
> execve("/usr/bin/wc", ["wc", "/root/bigfile"], [/* 20 vars */]) = 0
>  290314 3127604 40121984 /root/bigfile
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  99.59    0.100965          41      2453           read
>   0.16    0.000161          12        13         2 open
>   0.07    0.000075          15         5           brk
>   0.06    0.000062           5        13           old_mmap
>   0.03    0.000031           3        11           close
>   0.02    0.000023           3         9           fstat
>   0.02    0.000019           6         3           munmap
>   0.01    0.000015          15         1           write
>   0.01    0.000015           5         3           mprotect
>   0.01    0.000008           4         2           fstat64
>   0.00    0.000005           5         1           ioctl
>   0.00    0.000002           2         1           getpid
>   0.00    0.000002           2         1           personality
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.101383                  2516         2 total
> 
> 
> # mount
> /dev/sda3 on / type reiserfs (rw,noatime,nodiratime)
> 
> 
> That's messed up! Why are they doing exactly the same # of 'read' calls
> but my newer system has decided to add 637 'write' calls ??????
> 
> What reiserfs / mount options should I try to get this at a more normal 
> level ?
> 
> 
> -n.
> 
> Valdis.Kletnieks@vt.edu wrote:
> 
>>On Thu, 07 Nov 2002 19:59:55 +0900, Naoki <naoki@valuecommerce.ne.jp>
>>said:
>>
>>  
>>
>>>real    0m3.059s
>>>user    0m2.543s <== say what???
>>>sys     0m0.064s
>>>    
>>>
>>>0.25user 0.04system 0:00.38elapsed 76%CPU (0avgtext+0avgdata
>>>    
>>>
>>0maxresident)k
>>  
>>
>>>0inputs+0outputs (115major+19minor)pagefaults 0swaps
>>>    
>>>
>>
>>I'd start by investigating why on the new box the 'user' time is 2.5+
>>seconds.
>>
>>Notice that the 'system' times on both boxes are comparable (0.06 versus
>>0.04 - low enough that timer resolution probably matters in any jitter
>>in
>>the measurements).
>>
>>Does 'which wc' show you running something other than /usr/bin/time on
>>the
>>new box?
>>  
>>


      reply	other threads:[~2002-11-08  0:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-07 10:59 Poor sequential write performance Naoki
2002-11-07 18:09 ` Valdis.Kletnieks
2002-11-08  0:23   ` Getting very interesting - Poor read performance Naoki
2002-11-08  0:48     ` Manuel Krause [this message]

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=3DCB09E2.8040206@mb.tu-ilmenau.de \
    --to=manuel.krause@mb.tu-ilmenau.de \
    --cc=naoki@valuecommerce.ne.jp \
    --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.