| Title: | DEC Rdb against the World |
| Moderator: | HERON::GODFRIND |
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
Hi,
After tuning/configuring the OSF/1 1.3 and the SPECIAL UK version of OnLine
we might have a EXCELLENT thing in our hands: Online with up to 4 GB of
buffers(shared memory), beating a **** out of any competitor on almost
any benchmark with the database that's 2-4GB in size:
WE can SHOW it NOW (all we need is RAM). Here is the report:
regards,
Paul
PS: COULD YOU PROVIDE ME WITH THE IDEAS and EXAMPLES(small) OF HOW TO
SHOW/DEMO THIS GREAT STUFF WITH INFORMIX !
*****************************************************************************
OnLine 5.00 UD2 configuration: 1,100,000 buffers(~2.5 GB of shared memory)
System: DEC 3000/500 with 256 MB RAM and 5 GB swap. OnLine started
OK and I ran a couple of simple tests to prove it works. The
system was swapping heavilly, what else with 10:1 ratio of
shared_memory to RAM!
All tests completed successfully with no problems whatsoever!
Next: test Informix with 3.5 GB of shared memory(=1,800,000 buffers)
this might be a problem if there is a int in the control
structures of OnLine 5.0.
Looks like there are NO SIGNED INT problems.
Paul Krneta, Alpha Resource Center(BPDA_GY) Munich, Germany
*******************************************************************
informix at malibu> tbstat -b
RSAM Version 5.00.UD2 -- On-Line -- Up 00:10:29 -- 2607456 Kbytes
Buffers
address user flgs pagenum memaddr nslots pgflgs xflgs owner
waitlist
0 modified, 1100000 total, 2097152 hash buckets, 2048 buffer size
********************************************************************
informix at malibu> tbstat -R
RSAM Version 5.00.UD2 -- On-Line -- Up 00:15:08 -- 2607456 Kbytes
16 buffer LRU queues
LRU 0: 0 ( 0.0%) modified of 137500 total
LRU 1: 0 ( 0.0%) modified of 137500 total
LRU 2: 0 ( 0.0%) modified of 137500 total
LRU 3: 0 ( 0.0%) modified of 137500 total
LRU 4: 0 ( 0.0%) modified of 137500 total
LRU 5: 0 ( 0.0%) modified of 137500 total
LRU 6: 0 ( 0.0%) modified of 137500 total
LRU 7: 0 ( 0.0%) modified of 137500 total
0 dirty, 1100000 queued, 1100000 total, 2097152 hash buckets, 2048
buffer size
start clean at 90% dirty, stop at 50%
**************************************************************************
Swap space free = 50.04% (2582.0MB out of 5160.2MB)
Total swap space to physical memory = 2015.70% (5160.2MB to 256.0MB)
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1311.1 | COPCLU::BRUNSGAARD | I swear to say the whole truth as often as I can | Thu Nov 11 1993 00:40 | 17 | |
But then again who on earth wouldn't get decent performance figures out of using 3GByte memory for database buffer ???? I mean taht would be like saying you would be able to get decent performance from a programming language if you only did a:=17 b:=19 aso. hardly a true or even realistic benchmark.... sorry but I'm not that impressed. Now tell us what the difference was from the previous version of Informix on the OSF 1.2 version, so we can hear what the difference the new version made. cheers Lars | |||||
| 1311.2 | OSF/1 is not BABY-UNIX | MUNICH::KRNETA | Thu Nov 11 1993 09:55 | 17 | |
re -.1
>who on earth wouldn't get decent performance figures out of using
>3GByte memory
>for database buffer ????
didn't get it, did You? OK, all other UN*X vendors are able to
deliver only BABY-UN*X, that means 32-bit UN*X, limitted to 2 GB of
virtual address space per process AND 2 GB of RAM.
You are right when You say "who on earth wouldn't get decent
performance figures out of using 3GByte memory", but they CAN NOT USE
3 GB of memory.
regards,
Paul
| |||||
| 1311.3 | So this is because of 64 bit OSF/1, right? | IJSAPL::OLTHOF | What I need right now is vision | Thu Nov 11 1993 10:01 | 14 |
So let me get this straight:
- the claim is that we can do this because of our 64 bit OSF/1
implementation, correct?
- if so, could other DB vendors like Oracle, Ingres or Sybase use the
same strategy
Don't know the numbers but 3BG of memory must be a lot of dollars. Is
this solution really affordable for regular computing?
Interesting benchmark still, shows database vendors which way to go.
Thanks for the info,
Henny Olthof
| |||||
| 1311.4 | think in advance or let SUN/HP claim 64-bit | MUNICH::KRNETA | Mon Nov 15 1993 16:12 | 21 | |
re .-1
>So this is because of 64 bit OSF/1, right?
right.
>if so, could other DB vendors like Oracle, Ingres or Sybase use the
>same strategy
yes, they could, but we have to check and make sure their code is OK.
>Don't know the numbers but 3BG of memory must be a lot of dollars. Is
>this solution really affordable for regular computing?
how big was memory on VAX 11/780 in 1978? 1/2 MB? and today? 1/2 GB?
the factor is 1000:1 in 10-15 years? Our GB RAM is approx $100-150K.
If you get facto 5:1 improvement for soeme apps is it worth it?
Ever bought 1GB RAM for IBM 3090?
regards,
Paul
| |||||
| 1311.5 | Ahhhh, now I see | COPCLU::BRUNSGAARD | I swear to say the whole truth as often as I can | Tue Nov 16 1993 10:33 | 7 |
AHHH Thanks Paul, Baby-Unix ! Great buzz-word, I'll definitly use that ! Lars | |||||
| 1311.6 | tm: BABY-MAINFRAME as well | MUNICH::KRNETA | Tue Nov 16 1993 11:03 | 10 | |
re .-1
>Baby-Unix !
>Great buzz-word, I'll definitly use that !
there is a BABY-MAINFRAME as well
Paul
PS: Baby-Unix and Baby-Mainframe are trademarked by mysekf :-)
| |||||