lkml.org 
[lkml]   [1999]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [big performances boost for DataBases] Re: cache killer memory death test - 2.0 vs 2.2 vs arca - programs inside
On 26 Apr 1999, Harvey J. Stein wrote:

> Test 1 Test 2
> user sys elapsed worst 2nd user sys elapsed worst 2nd comments
>2.0.36 27.69 7.70 2:37.27 9.73 6.88 28.97 10.21 17:30.68 76.37 75.11 poor
> 28.32 7.33 0:43.87 3.36 2.32
> 27.52 7.40 0:43.08 3.42 2.22
>
>2.2.5 28.13 6.80 2:50.52 8.00 7.19 29.44 8.70 13:21.34 61.29 64.95 fine
> 28.64 6.61 1:47.39 7.91 6.77
> 28.55 6.40 1:48.49 7.88 7.11
>
>2.2.5arca12 27.99 6.77 1:24.68 14.93 9.38 30.13 6.91 4:13.60 14.08 13.09 very poor
> 28.98 6.69 1:19.67 14.12 9.56
> 28.18 6.77 1:18.99 13.89 9.39
>
>2.2.6 28.20 6.70 2:47.06 7.47 6.87 31.73 8.92 14:41.84 16.57 16.53 fine
> 28.92 6.17 1:46.01 7.97 6.62
> 28.69 6.39 1:47.77 7.81 6.76
>
>2.2.6arca1 28.66 7.73 1:24.43 13.85 9.06 30.07 9.62 10:45.50 65.61 45.63 fine
> 29.15 7.82 1:15.55 13.38 8.74
> 28.37 7.85 1:12.91 13.33 7.24
>
>
>2.2.6a2* 28.04 7.24 0:42.24 2.82 2.10 29.89 7.33 1:30.70 6.09 4.34 excellent
> 28.44 7.06 0:42.37 2.82 2.10
> 28.02 6.96 0:41.94 2.79 2.09
> 27.88 7.23 0:42.39 2.80 2.09**
>
>* - 2.2.6a2 = 2.2.6andrea2.
>** - run again directly from a reboot because I couldn't believe the #s!

;)

>Smokin! 2.2.6andrea2 was so incredibly fast that I didn't really
>have much time to test it interactively, but it was great. Netscape
>came up in under a minute.

I am very happy to hear that ;). Now it would be also interesting to see a
DBMS benchmark.

BTW, did you tried without fsync with 50000 records?

>With gdbm_sync (interactive test, 100,000 records):
>
> user sys elapsed worst 2nd
> 91.16 24.42 10:51.33 51.41 46.82
> 87.56 21.85 3:12.71 13.88 9.72

What was referring the 10 minutes numbers?

>significant mouse freezes (~5-10 seconds). I would have expected them
>to occur during heavy I/O, but surprisingly, the disk is pretty busy

Hmm, I would expect that too. Doing the right thing with dirty data under
all scenarios is hard like hell.

>The second time I guess I just wasn't hitting the system as hard
>interactively. I barely noticed it running. It's still pretty
>amazing - the #s are competitive with the other kernels doing half as
>many records.

Fine.

>Without gdbm_sync (interactive test):
>
> user sys elapsed worst 2nd
> 88.50 24.90 17:38.55 97.38 74.78
>
>It didn't have big pauses while the test was running, but it ran much
>slower! The system *was* sluggish and did have lots of annoying
>little pauses, more so than with gdbm_sync. Either gdbm_sync is doing

I think to know why.

>Andrea - maybe you'd like to reboot with 32 mb & try running a 100,000
>record test with gdbm_sync on and lots of netscape windows, maybe

I'll reboot now.

Andrea Arcangeli


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.228 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site