Messages in this thread | | | Subject | Re: [big performances boost for DataBases] Re: cache killer memory death test - 2.0 vs 2.2 vs arca - programs inside | From | (Harvey J. Stein) | Date | 26 Apr 1999 01:05:24 +0300 |
| |
I just finished testing 2.2.6andrea2. It went fast because this baby flies! Here are the numbers (along with the other #s previously quoted), with 50,000 records:
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.
To stress it on my 32mb machine, I tried out the 100,000 record interactive test (test2) both with gdbm_sync & without gdbm_sync:
This was with netscape blowing up sizably:
hjstein 479 5.2 26.9 25736 8360 1 S 23:40 0:36 /usr/lib/netscape/netscape-communicator -install hjstein 488 0.0 0.0 12776 0 1 SW 23:40 0:00 (netscape-commun)
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
Now I started periodically getting sizable pauses, along with significant mouse freezes (~5-10 seconds). I would have expected them to occur during heavy I/O, but surprisingly, the disk is pretty busy most of the time (I can hear it), and during most of the pauses/freezes, the disk is silent! System time is way up and utilization is way down. Maybe it's locked up while organizing memory for the fsync call?
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.
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 what I want it to do, or I'm hitting edge conditions - maybe we start seeing serious degredation when sufficient memory is in use and I'm not always hitting that level. Maybe writes to disk are getting cached for too long - they fill up memory & then the system starts writing wildly? The silent freezes are weird, though.
The plots of time for each 1000 records tell a story too, but I don't want to include a 758 line uuencoded file here.
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 gnuplot, an emacs & some xterms to see if you can pin down the freezes? Or maybe on your 128mb machine you'll need a 500,000 record test to really stress it. I wouldn't be surprised if this is as good as it gets, but you never know...
-- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il
- 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/
| |