FYI: relative performance of cooked vs. raw 
Author Message
 FYI: relative performance of cooked vs. raw

I've just setup a few engines on a sun box  and can make the following
observation. Two engines were setup - one for testing and one for
production. The engines were configured *absolutely identically* down to the
last detail excepting that the production instance was setup to use raw
spaces and the test instance is using files.

During the mass-loading operation with 250Mb buffers + 150Mb shared memory
(for pdq builds of indexes and statistics) the engines were showing

approx 8 second checkpoints for the raw space
approx 300 second checkpoints for the cooked files

So that's a definitive observation for the record.

Machine is

SunOS boxname 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-880

with twin procs and a few gig of memory, and 2 mirror pairs of 36gb disks.

PS - anyone got any essential tuning tips for solaris? I understand that you
only need to put entries into /etc/system and reboot?
--
Space Corps Directive #997
Work done by an officer's doppleganger in a parallel
universe cannot be claimed as overtime.
    -- Red Dwarf
..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .



Sat, 05 Jun 2004 11:40:34 GMT
 FYI: relative performance of cooked vs. raw


Quote:
> I've just setup a few engines on a sun box  and can make the following
> observation. Two engines were setup - one for testing and one for
> production. The engines were configured *absolutely identically* down to
the
> last detail excepting that the production instance was setup to use raw
> spaces and the test instance is using files.

How many aio vps?


Sat, 05 Jun 2004 16:21:55 GMT
 FYI: relative performance of cooked vs. raw

Quote:
----- Original Message -----


Sent: Tuesday, December 18, 2001 6:40 AM
Subject: FYI: relative performance of cooked vs. raw

> I've just setup a few engines on a sun box  and can make the following
> observation. Two engines were setup - one for testing and one for
> production. The engines were configured *absolutely identically* down to
the
> last detail excepting that the production instance was setup to use raw
> spaces and the test instance is using files.

> During the mass-loading operation with 250Mb buffers + 150Mb shared memory
> (for pdq builds of indexes and statistics) the engines were showing

> approx 8 second checkpoints for the raw space
> approx 300 second checkpoints for the cooked files

Were you using 'forcedirectio' ?

As far as I know the VM implemented on Solaris is not very effective ( but
rock stable! ).
I've tried to compare massive file I/O on Solaris 8 IA and Linux and I can
say -
Linux performs much faster.
(
  My computer for experiments is 2xPII 233, 256 M RAM UW SCSI-2
)

Quote:

> So that's a definitive observation for the record.

> Machine is

> SunOS boxname 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-880

> with twin procs and a few gig of memory, and 2 mirror pairs of 36gb disks.

> PS - anyone got any essential tuning tips for solaris? I understand that

you

I was looking for it too, but found nothing ...

- Show quoted text -

Quote:
> only need to put entries into /etc/system and reboot?
> --
> Space Corps Directive #997
> Work done by an officer's doppleganger in a parallel
> universe cannot be claimed as overtime.
>     -- Red Dwarf
> ..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .



Sat, 05 Jun 2004 16:24:51 GMT
 FYI: relative performance of cooked vs. raw
I did similar testing a while ago, where I actually used the same
server, but just brought the server down and copied the chunks to
different places (providing access to the chunk through a symlink).

In my tests the RAW chunks were always 5 to 10 faster on checkpoints
(I'm running Informix 7.31.UC7 on Sun Solaris 8, running on Fire 4800).

Actually what I tested were:
* UFS filesystem on StorEdge T3
* Veritas VxFS filesystem on StorEdge T3
* NFS filesystem on NetApp 840, over Gigabit Ethernet
* Veritas VxFS with QIO option enabled (raw mode on top of a filesystem)

* Same Informix server with same test case and identical configuration
(except the symlink to the chunks)

Actually NFS did remarkably well, significantly outperforming the VxFS
and UFS filesystems. VxFS with QIO is equal to raw disk access with all
benefits of a file system, and that of course outperformed everything
else. But also the T3 is about the fastest disk array available from
Sun.
--
Toni

Quote:

> I've just setup a few engines on a sun box  and can make the following
> observation. Two engines were setup - one for testing and one for
> production. The engines were configured *absolutely identically* down to the
> last detail excepting that the production instance was setup to use raw
> spaces and the test instance is using files.

> During the mass-loading operation with 250Mb buffers + 150Mb shared memory
> (for pdq builds of indexes and statistics) the engines were showing

> approx 8 second checkpoints for the raw space
> approx 300 second checkpoints for the cooked files

> So that's a definitive observation for the record.

> Machine is

> SunOS boxname 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-880

> with twin procs and a few gig of memory, and 2 mirror pairs of 36gb disks.

> PS - anyone got any essential tuning tips for solaris? I understand that you
> only need to put entries into /etc/system and reboot?
> --
> Space Corps Directive #997
> Work done by an officer's doppleganger in a parallel
> universe cannot be claimed as overtime.
>     -- Red Dwarf
> ..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .



Sat, 05 Jun 2004 17:38:41 GMT
 FYI: relative performance of cooked vs. raw
Depending in the FS you are using you can turn off the filecaching and
write direct to disk and other particular FS tweaks.

There's not much you can do with memory, apart from not dumping big
files into /tmp - standard Unix'y stuff

The Adrian{*filter*}croft books are worth a look but they tend to be biased
towards Oracle and FS based data.

One rumour that keeps popping up, which I haven't had chance to test, is
on the larger Sun boxes it's better to run tli as it is quicker than
SHM.
On a reasonably spec'd 10K for example the major bottleneck is bandwidth
to memory

Quote:

> I've just setup a few engines on a sun box  and can make the following
> observation. Two engines were setup - one for testing and one for
> production. The engines were configured *absolutely identically* down to the
> last detail excepting that the production instance was setup to use raw
> spaces and the test instance is using files.

> During the mass-loading operation with 250Mb buffers + 150Mb shared memory
> (for pdq builds of indexes and statistics) the engines were showing

> approx 8 second checkpoints for the raw space
> approx 300 second checkpoints for the cooked files

> So that's a definitive observation for the record.

> Machine is

> SunOS boxname 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-880

> with twin procs and a few gig of memory, and 2 mirror pairs of 36gb disks.

> PS - anyone got any essential tuning tips for solaris? I understand that you
> only need to put entries into /etc/system and reboot?
> --
> Space Corps Directive #997
> Work done by an officer's doppleganger in a parallel
> universe cannot be claimed as overtime.
>     -- Red Dwarf
> ..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .

--
Paul Watson             #          
Oninit Ltd              # Growing old is mandatory
Tel: +44 1436 672201    # Growing up is optional
Fax: +44 1436 678693    #
www.oninit.com          #


Sat, 05 Jun 2004 18:51:48 GMT
 FYI: relative performance of cooked vs. raw
Has anyone run similar comparisons on Linux?
Quote:

> I've just setup a few engines on a sun box  and can make the following
> observation. Two engines were setup - one for testing and one for
> production. The engines were configured *absolutely identically* down to the
> last detail excepting that the production instance was setup to use raw
> spaces and the test instance is using files.

> During the mass-loading operation with 250Mb buffers + 150Mb shared memory
> (for pdq builds of indexes and statistics) the engines were showing

> approx 8 second checkpoints for the raw space
> approx 300 second checkpoints for the cooked files

> So that's a definitive observation for the record.

> Machine is

> SunOS boxname 5.8 Generic_108528-12 sun4u sparc SUNW,Sun-Fire-880

> with twin procs and a few gig of memory, and 2 mirror pairs of 36gb disks.

> PS - anyone got any essential tuning tips for solaris? I understand that you
> only need to put entries into /etc/system and reboot?
> --
> Space Corps Directive #997
> Work done by an officer's doppleganger in a parallel
> universe cannot be claimed as overtime.
>     -- Red Dwarf
> ..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .



Sat, 05 Jun 2004 21:26:43 GMT
 FYI: relative performance of cooked vs. raw

Quote:

>One rumour that keeps popping up, which I haven't had chance to test, is
>on the larger Sun boxes it's better to run tli as it is quicker than
>SHM.

I noticed this on a development Sparc20 too. Running Quantify on my app
pointed to mutex locking...




Sat, 05 Jun 2004 22:19:48 GMT
 FYI: relative performance of cooked vs. raw
Hmmm, the turnstile mechanism around the process tables is supposed
to get round this.

Quote:

> ?
> ?One rumour that keeps popping up, which I haven't had chance to test, is
> ?on the larger Sun boxes it's better to run tli as it is quicker than
> ?SHM.

> I noticed this on a development Sparc20 too. Running Quantify on my app
> pointed to mutex locking...



--
Paul Watson             #          
Oninit Ltd              # Growing old is mandatory
Tel: +44 1436 672201    # Growing up is optional
Fax: +44 1436 678693    #
www.oninit.com          #


Sun, 06 Jun 2004 00:38:53 GMT
 FYI: relative performance of cooked vs. raw
Quote:

>In my tests the RAW chunks were always 5 to 10 faster on checkpoints
>(I'm running Informix 7.31.UC7 on Sun Solaris 8, running on Fire 4800).

Any findings on general query performance especially when busy?

Quote:
>Actually NFS did remarkably well, significantly outperforming the VxFS
>and UFS filesystems. VxFS with QIO is equal to raw disk access with all
>benefits of a file system, and that of course outperformed everything
>else. But also the T3 is about the fastest disk array available from
>Sun.

I've got an *attitude* about NFS, but if I go into it, William will come out
of retirement...


Sun, 06 Jun 2004 16:22:46 GMT
 FYI: relative performance of cooked vs. raw
Quote:

>Depending in the FS you are using you can turn off the filecaching and
>write direct to disk and other particular FS tweaks.

What's that then? I'm newish to Suns. Actually call that new. I used to have
a little cube of disks and processor bound together by SCSI cable on my desk
with an X screen but that hardly counts.

It sounds like it's worth doing for the test instance. Are these settings
applied at the FS level? Please share.



Sun, 06 Jun 2004 16:24:50 GMT
 FYI: relative performance of cooked vs. raw
Quote:

>Has anyone run similar comparisons on Linux?

It may be early days still to draw any conclusion about raw performance on
Linux. The concept is relatively new (hearsay has it that Linus refused to
acknowledge the need for raw until about 1-2 years ago). Although with the
very rapid pace of Linux development, maybe it's peaked now? There were some
limitations, which a guy called Serge posted to the ng a while ago.
--
Space Corps Directive #997
Work done by an officer's doppleganger in a parallel
universe cannot be claimed as overtime.
    -- Red Dwarf
..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .


Sun, 06 Jun 2004 16:27:25 GMT
 FYI: relative performance of cooked vs. raw
Quote:



>> I've just setup a few engines on a sun box  and can make the following
>> observation. Two engines were setup - one for testing and one for
>> production. The engines were configured *absolutely identically* down to
>> the last detail excepting that the production instance was setup to use
>> raw spaces and the test instance is using files.

>How many aio vps?

1.5 per chunk. Although during a mass-load operation the demands would be
lower than that.

Do you expect this to affect cooked in any way? What's your theory?



Sun, 06 Jun 2004 16:30:39 GMT
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Raw I/O vs files (was Re: Raw partitions / cooked files)

2. Cooked files vs raw devices

3. Raw partitions vs. Cooked partitions

4. raw vs. cooked rehash

5. Raw vs. cooked devices

6. Raw Device Vs.Cooked File

7. Speed of raw IO vs Linux cooked files

8. Speed of raw IO vs Linux cooked files

9. Raw vs. cooked

10. cooked space vs raw space

11. cooked vs raw disk in an Data Warehousing environment

12. Raw vs Cooked space?


 
Powered by phpBB® Forum Software