f



IDS 10 on RHEL4 Linux: I/O benchmark of RAW DEVICES vs BLOCK DEVICES vs COOKED FILES

Hello there,

this is a long message (sorry in advance) which contains some hopefully
interesting information. There are also some questions at the end.

I have this nice new Red Hat Enterprise Linux 4 machine, it's an HP DL 385
with 8 internal 10K RPM SAS disks, 2 dual-core AMD Opteron CPUs and 4 GB RAM.
Machine features 256 Mb of cache on the disks controller. Here it is:
http://tinyurl.com/p6k6y

I have installed Informix Dynamic Server 10.00.FC4 (64 bit).

I bumped into this IBM article: http://tinyurl.com/gfovb, where it says that
Informix IDS 10 on RHEL4 Linux is able to access block devices in unbuffered
fashion -like it does for the raw devices- using KAIO (Kernel Asynchronous I/O).

The server is brand new, and I can play with it a bit before it goes into
production, so I decided to do some performance testing of RAW vs BLOCK
vs COOKED, to see which one was better from the I/O performance point of view.

Some definitions, first:

* RAW DEVICE or CHARACTER DEVICE = devices through which data is transmitted
   one character at a time, using unbuffered input and output routines; each
   character is read from, or written to, the device immediately; such devices
   are disk partitions without a file system on them, and are therefore managed
   from outside the operating system using direct access and bypassing the OS
   layer and its cache

* BLOCK DEVICE = devices through which data is transmitted in the form of
   blocks, the most significant difference between block and character devices
   is that block devices use buffered input and output routines; normally a block
   device is a mounted partition with a filesystem

Here is how to distinguish, listing with 'ls -l', if a device is a file or a
raw/character device or a block device:
1) FILE:      -rw-rw-rw-	(prefix is "-")
2) RAW/CHAR:  crw-rw-rw-	(prefix is "c")
3) BLOCK:     brw-rw-rw-	(prefix is "b")

Given in all cases the same server and the same identical set of physical disks,
here are the tests I have performed:

1. time for dbimport of a certain database (around 500 Mb big once dbexport-ed
    on a filesystem)

2. execution of a raw benchmark program that creates 1 table with 1 row and
    forces 1000 INSERT/UPDATE/DELETE operations in a prepared and non-prepared
    fashion

Here are the results of the two tests:

1. Time to do dbimport of the same database:

    - RAW:    14 min 45 sec
    - BLOCK:  14min 54 sec
    - COOKED: 12 min 20 sec

    Raw devices and block devices are in line. Cooked file gives around 20%
    better performance. Dropping the DB and repeating dbimport when using cooked
    files entails even better results: there must be some filesystem caching
    being used, and that is not available when the dbspace is configured using
    raw or block devices. For the record, the filesystem type used is EXT3,
    default for RHEL4 Linux.

2. Average figures (upon three runs) for 1,000 INSERT/UPDATE/DELETE operations:
 
                             	    				     RAW            BLOCK         COOKED
    - average INSERT transactions per second  9403           9413          8866
    - average UPDATE transactions per second  258            256           254 

    - average DELETE transactions per second  1371           1442          1342 

    - average PREPARED INSERT trans per sec   17995          19262         13443 

    - average PREPARED UPDATE trans per sec   304            309           317
    - average PREPARED DELETE trans per sec   1326           1239          1316

    Apart INSERT operations, which seems to be 20-30% slower, all results of
    COOKED files are in line with those of RAW and BLOCK devices.


I always knew that COOKED files should have been "much" slower than RAW devices.
Latest Informix Admin Guide, http://tinyurl.com/m2of2, does even state this
clearly (page 241 and following ones): <<The database server can use regular
operating-system files or raw disk devices to store data. On UNIX, you should
use raw disk devices to store data whenever performance is important. [...]
When dbspaces reside on raw disk devices (also called character-special
devices), the database server uses unbuffered disk access. Performance is much
better when you use raw disk devices than cooked files because the database
server has direct I/O access to the devices. A raw disk directly transfers data
between the database server memory and disk without also copying data.>>

So, here are my questions:
- The machine that have been used features 256Mb of cache on the disks
   controller: how much do you think this influenced the results, especially in
   giving advantage to the filesystem-based (COOKED) dbspace compared to the
   low-level access (RAW / BLOCK) to the devices?

- Given the same combination of OS and Informix version, are similar results
   to be always and reasonably expected, independently from the underlying
   hardware (with/without disk cache etc.)?

- Test #1 was clearly won by COOKED files configuration, but that test is not
   representative of a typical OLTP kind of I/O: having an OLTP application that
   needs to run on the machine, would you trust what Informix says in its
   Admin Guide (see above) and results of #2 or go for COOKED files instead?

- In which proven cases the sentence from Informix documentation "On UNIX, you
   should use raw disk devices to store data whenever performance is important"
   is to be taken in consideration? OLTP-style usage or what?

- Any obvious reason why in test #2 only INSERT (not UPDATE nor DELETE)
   operations were significantly slower when using COOKED files based dbspaces?

Hope my findings might be of some interest for someone.

Waiting for your feedback on my questions,

Ciao,
   Rupan3rd (from Italy)

0
Rupan3rd
6/20/2006 12:30:23 PM
comp.databases.informix 16083 articles. 0 followers. Post Follow

5 Replies
519 Views

Similar Articles

[PageSpeed] 12

Rupan3rd wrote:

> - Test #1 was clearly won by COOKED files configuration, but that
> test is not representative of a typical OLTP kind of I/O: having an
> OLTP application that needs to run on the machine, would you trust
> what Informix says in its Admin Guide (see above) and results of #2
> or go for COOKED files instead?

Test 1 involves loading from the filesystem which will use OS caching. I 
may be on shaky ground here but it may be that writing to a cooked file 
that also uses the same OS cache is faster than a raw device in this 
instance. However, as you say, unless you do a lot of dbimports this 
won't matter to you very much.

Test 2 works on a single table with one row initially. This is a small 
amount of data and all the operations could easily take place inside 
Informix's buffers with only occasional LRU writes or maybe a checkpoint 
making any difference. 1000 operations may not be enough to cause a 
checkpoint. You would need to tune your server to have a very small 
bufferpool to force all the changes to be written to disc more quickly 
to see any significant differences between filesystems in this test. For 
this reason I would be interested to see your ONCONFIG and your cached 
read and write rate from "onstat -p" after each test. I would also 
bounce the server before every test (if you didn't do this before) to 
clear out the bufferpool and reset the statistics ("onstat -z").

Ben.
0
Ben
6/20/2006 2:13:26 PM
Ben,

thanx for the feedback.

You are right. I did reset statistics and run the test again: all is cached
in the buffers (see below). I need to either change the testing tool or reduce
buffers.

This means that the previously provided figures about test #2 are not very
significant. I'll see if I manage to produce something more useful.

Regards
   R.


Ben Thompson wrote:
> Test 2 works on a single table with one row initially. This is a small 
> amount of data and all the operations could easily take place inside 
> Informix's buffers with only occasional LRU writes or maybe a checkpoint 
> making any difference. 1000 operations may not be enough to cause a 
> checkpoint. You would need to tune your server to have a very small 
> bufferpool to force all the changes to be written to disc more quickly 
> to see any significant differences between filesystems in this test. For 
> this reason I would be interested to see your ONCONFIG and your cached 
> read and write rate from "onstat -p" after each test. I would also 
> bounce the server before every test (if you didn't do this before) to 
> clear out the bufferpool and reset the statistics ("onstat -z").
> 
> Ben.


[orc@zeus:~/custom] onstat -p

IBM Informix Dynamic Server Version 10.00.FC4     -- On-Line -- Up 23:36:44 -- 
310052 Kbytes

Profile
dskreads   pagreads   bufreads   %cached dskwrits   pagwrits   bufwrits   %cached
0          0          6335194    100.00  166        2812       3046883    99.99

isamtot    open       start      read       write      rewrite    delete 
commit     rollbk
9232557    22415      36912      3054060    14295      3005457    6375       927 
        0

gp_read    gp_write   gp_rewrt   gp_del     gp_alloc   gp_free    gp_curs
0          0          0          0          0          0          0

ovlock     ovuserthread ovbuff     usercpu  syscpu   numckpts   flushes
0          0            0          26.09    0.68     0          0

bufwaits   lokwaits   lockreqs   deadlks    dltouts    ckpwaits   compress 
seqscans
2          0          15094199   0          0          0          1032       12354

ixda-RA    idx-RA     da-RA      RA-pgsused lchwaits
0          0          0          0          96
0
Rupan3rd
6/20/2006 3:42:16 PM
Since cooked uses filesystem cache you can savely add more buffers to
make the comparison
better.

another thing:

try big volumes; you may swamp the file system cache and as a result
your performance
goes down the drain.

ex on sun solaris (sorry have no figures on linux) restoreing a
database
was 3 times slower on cooked then on char mode raw.

another good test: create a db of say 20 GB and restore that use big
blocksizes of course
for ontape or setup onbar properly.

cooked may give you a hard time. machine may be slow due swamping the
filesystem cache.

Superboer.


Rupan3rd schreef:

> Hello there,
>
> this is a long message (sorry in advance) which contains some hopefully
> interesting information. There are also some questions at the end.
>
> I have this nice new Red Hat Enterprise Linux 4 machine, it's an HP DL 385
> with 8 internal 10K RPM SAS disks, 2 dual-core AMD Opteron CPUs and 4 GB RAM.
> Machine features 256 Mb of cache on the disks controller. Here it is:
> http://tinyurl.com/p6k6y
>
> I have installed Informix Dynamic Server 10.00.FC4 (64 bit).
>
> I bumped into this IBM article: http://tinyurl.com/gfovb, where it says that
> Informix IDS 10 on RHEL4 Linux is able to access block devices in unbuffered
> fashion -like it does for the raw devices- using KAIO (Kernel Asynchronous I/O).
>
> The server is brand new, and I can play with it a bit before it goes into
> production, so I decided to do some performance testing of RAW vs BLOCK
> vs COOKED, to see which one was better from the I/O performance point of view.
>
> Some definitions, first:
>
> * RAW DEVICE or CHARACTER DEVICE = devices through which data is transmitted
>    one character at a time, using unbuffered input and output routines; each
>    character is read from, or written to, the device immediately; such devices
>    are disk partitions without a file system on them, and are therefore managed
>    from outside the operating system using direct access and bypassing the OS
>    layer and its cache
>
> * BLOCK DEVICE = devices through which data is transmitted in the form of
>    blocks, the most significant difference between block and character devices
>    is that block devices use buffered input and output routines; normally a block
>    device is a mounted partition with a filesystem
>
> Here is how to distinguish, listing with 'ls -l', if a device is a file or a
> raw/character device or a block device:
> 1) FILE:      -rw-rw-rw-	(prefix is "-")
> 2) RAW/CHAR:  crw-rw-rw-	(prefix is "c")
> 3) BLOCK:     brw-rw-rw-	(prefix is "b")
>
> Given in all cases the same server and the same identical set of physical disks,
> here are the tests I have performed:
>
> 1. time for dbimport of a certain database (around 500 Mb big once dbexport-ed
>     on a filesystem)
>
> 2. execution of a raw benchmark program that creates 1 table with 1 row and
>     forces 1000 INSERT/UPDATE/DELETE operations in a prepared and non-prepared
>     fashion
>
> Here are the results of the two tests:
>
> 1. Time to do dbimport of the same database:
>
>     - RAW:    14 min 45 sec
>     - BLOCK:  14min 54 sec
>     - COOKED: 12 min 20 sec
>
>     Raw devices and block devices are in line. Cooked file gives around 20%
>     better performance. Dropping the DB and repeating dbimport when using cooked
>     files entails even better results: there must be some filesystem caching
>     being used, and that is not available when the dbspace is configured using
>     raw or block devices. For the record, the filesystem type used is EXT3,
>     default for RHEL4 Linux.
>
> 2. Average figures (upon three runs) for 1,000 INSERT/UPDATE/DELETE operations:
>
>                              	    				     RAW            BLOCK         COOKED
>     - average INSERT transactions per second  9403           9413          8866
>     - average UPDATE transactions per second  258            256           254
>
>     - average DELETE transactions per second  1371           1442          1342
>
>     - average PREPARED INSERT trans per sec   17995          19262         13443
>
>     - average PREPARED UPDATE trans per sec   304            309           317
>     - average PREPARED DELETE trans per sec   1326           1239          1316
>
>     Apart INSERT operations, which seems to be 20-30% slower, all results of
>     COOKED files are in line with those of RAW and BLOCK devices.
>
>
> I always knew that COOKED files should have been "much" slower than RAW devices.
> Latest Informix Admin Guide, http://tinyurl.com/m2of2, does even state this
> clearly (page 241 and following ones): <<The database server can use regular
> operating-system files or raw disk devices to store data. On UNIX, you should
> use raw disk devices to store data whenever performance is important. [...]
> When dbspaces reside on raw disk devices (also called character-special
> devices), the database server uses unbuffered disk access. Performance is much
> better when you use raw disk devices than cooked files because the database
> server has direct I/O access to the devices. A raw disk directly transfers data
> between the database server memory and disk without also copying data.>>
>
> So, here are my questions:
> - The machine that have been used features 256Mb of cache on the disks
>    controller: how much do you think this influenced the results, especially in
>    giving advantage to the filesystem-based (COOKED) dbspace compared to the
>    low-level access (RAW / BLOCK) to the devices?
>
> - Given the same combination of OS and Informix version, are similar results
>    to be always and reasonably expected, independently from the underlying
>    hardware (with/without disk cache etc.)?
>
> - Test #1 was clearly won by COOKED files configuration, but that test is not
>    representative of a typical OLTP kind of I/O: having an OLTP application that
>    needs to run on the machine, would you trust what Informix says in its
>    Admin Guide (see above) and results of #2 or go for COOKED files instead?
>
> - In which proven cases the sentence from Informix documentation "On UNIX, you
>    should use raw disk devices to store data whenever performance is important"
>    is to be taken in consideration? OLTP-style usage or what?
>
> - Any obvious reason why in test #2 only INSERT (not UPDATE nor DELETE)
>    operations were significantly slower when using COOKED files based dbspaces?
>
> Hope my findings might be of some interest for someone.
>
> Waiting for your feedback on my questions,
> 
> Ciao,
>    Rupan3rd (from Italy)

0
Superboer
6/20/2006 5:14:18 PM
Rupan3rd wrote:
> Hello there,
>
> - The machine that have been used features 256Mb of cache on the disks
>    controller: how much do you think this influenced the results, especially in
>    giving advantage to the filesystem-based (COOKED) dbspace compared to the
>    low-level access (RAW / BLOCK) to the devices?
>

   It gives more advantage to either test since they both go via the
disk controller and
   so both use the cache.

> - Given the same combination of OS and Informix version, are similar results
>    to be always and reasonably expected, independently from the underlying
>    hardware (with/without disk cache etc.)?
>

   No. The results depend upon the hardware. Disk cache on/off will
affect the results.

> - Test #1 was clearly won by COOKED files configuration, but that test is not
>    representative of a typical OLTP kind of I/O: having an OLTP application that
>    needs to run on the machine, would you trust what Informix says in its
>    Admin Guide (see above) and results of #2 or go for COOKED files instead?
>

    I would test further.

    The COOKED test should be as is.

    The RAW test should use minimal filesystem cache (say 500Mb) to
cache things like the online.log.
    However it should use the reduction in fileysystem cache as buffers
otherwise it is not a fair test.

    You need to use the same memory for caching in both tests. In the
COOKED this should be
    fileysystem cache. In the RAW test this should be Informix buffers.
 Presumably somewhere there is a way
    to limit filesystem cache memory?

    In both tests set RESIDENT -1 in $ONCONFIG to avoid
paging/swapping. Monitor to make sure no
    paging/swapping is occuring during the test.



> - In which proven cases the sentence from Informix documentation "On UNIX, you
>    should use raw disk devices to store data whenever performance is important"
>    is to be taken in consideration? OLTP-style usage or what?
>

    Anything since RAW I/O involves less CPU overhead. Make sure that
the kernel limit on the
    maximum number of KAIO requests that can be done in parallel is
set. aio-max-nr? Something like
    that in the release notes. Are there any KAIO errors in the
online.log?   In the release notes it says
    that KAIOON can be set to the maximum number of KAIO requests per
CPU VP.

    We managed to hit >130,000 outstanding KAIO requests at any 1 time
and started getting errors.
    However this was on RHEL3 where KAIO is NOT supported by IBM. We
are yet to test on RHEL4.

> - Any obvious reason why in test #2 only INSERT (not UPDATE nor DELETE)
>    operations were significantly slower when using COOKED files based dbspaces?

    Inserts are mainly writes only I guess. Updates/deletes have to
locate the row hence do more
    reads since you are accessing different index/data pages each time?

>
> Hope my findings might be of some interest for someone.

   Yes. Please rebenchmark changing most of the filesystem cache to
Informix buffers in the
   RAW case. I would leave say 500Mb for filesystem cache/kernel and
the rest of the free memory for
   buffers. Set RESIDENT to -1 in both cases.

   And increase the RA_PAGES and RA_THRESHOLD in the raw case to allow
Informix to do the
  same readahead as the filesystem would!

   Let us know the results (and the ONCONFIG that is used)...

   Also could you test on 10.00.FC5?


>
> Waiting for your feedback on my questions,
> 
> Ciao,
>    Rupan3rd (from Italy)

0
david
6/24/2006 12:35:59 AM
Hi Folks

We are an Informix house since 1984.  We have found that COOKED file chunks
give the best performance on Linux at the moment, which is the opposite to
what you would expect.  On Unix we always use RAW devices (c), but on Linux
always COOKED.  Raw chunks on Linux only became an option in 2003 due to
Linux kernel updates and LVM support, but I think the implementation thus
far has been poor.  We have tested this with databases ranging in size from
500mb to 25gb.  An advantage of cooked files on smaller databases is the
option of file backup of chunks when database is offline (ie for our smaller
clients), simpler backup procedure.

Noel

"Rupan3rd" <rupan.nospam.3rd@hotmail.com> wrote in message
news:ATRlg.17496$bj6.1382@tornado.fastwebnet.it...
> Hello there,
>
> this is a long message (sorry in advance) which contains some hopefully
> interesting information. There are also some questions at the end.
>
> I have this nice new Red Hat Enterprise Linux 4 machine, it's an HP DL 385
> with 8 internal 10K RPM SAS disks, 2 dual-core AMD Opteron CPUs and 4 GB
RAM.
> Machine features 256 Mb of cache on the disks controller. Here it is:
> http://tinyurl.com/p6k6y
>
> I have installed Informix Dynamic Server 10.00.FC4 (64 bit).
>
> I bumped into this IBM article: http://tinyurl.com/gfovb, where it says
that
> Informix IDS 10 on RHEL4 Linux is able to access block devices in
unbuffered
> fashion -like it does for the raw devices- using KAIO (Kernel Asynchronous
I/O).
>
> The server is brand new, and I can play with it a bit before it goes into
> production, so I decided to do some performance testing of RAW vs BLOCK
> vs COOKED, to see which one was better from the I/O performance point of
view.
>
> Some definitions, first:
>
> * RAW DEVICE or CHARACTER DEVICE = devices through which data is
transmitted
>    one character at a time, using unbuffered input and output routines;
each
>    character is read from, or written to, the device immediately; such
devices
>    are disk partitions without a file system on them, and are therefore
managed
>    from outside the operating system using direct access and bypassing the
OS
>    layer and its cache
>
> * BLOCK DEVICE = devices through which data is transmitted in the form of
>    blocks, the most significant difference between block and character
devices
>    is that block devices use buffered input and output routines; normally
a block
>    device is a mounted partition with a filesystem
>
> Here is how to distinguish, listing with 'ls -l', if a device is a file or
a
> raw/character device or a block device:
> 1) FILE:      -rw-rw-rw- (prefix is "-")
> 2) RAW/CHAR:  crw-rw-rw- (prefix is "c")
> 3) BLOCK:     brw-rw-rw- (prefix is "b")
>
> Given in all cases the same server and the same identical set of physical
disks,
> here are the tests I have performed:
>
> 1. time for dbimport of a certain database (around 500 Mb big once
dbexport-ed
>     on a filesystem)
>
> 2. execution of a raw benchmark program that creates 1 table with 1 row
and
>     forces 1000 INSERT/UPDATE/DELETE operations in a prepared and
non-prepared
>     fashion
>
> Here are the results of the two tests:
>
> 1. Time to do dbimport of the same database:
>
>     - RAW:    14 min 45 sec
>     - BLOCK:  14min 54 sec
>     - COOKED: 12 min 20 sec
>
>     Raw devices and block devices are in line. Cooked file gives around
20%
>     better performance. Dropping the DB and repeating dbimport when using
cooked
>     files entails even better results: there must be some filesystem
caching
>     being used, and that is not available when the dbspace is configured
using
>     raw or block devices. For the record, the filesystem type used is
EXT3,
>     default for RHEL4 Linux.
>
> 2. Average figures (upon three runs) for 1,000 INSERT/UPDATE/DELETE
operations:
>
>                                       RAW            BLOCK         COOKED
>     - average INSERT transactions per second  9403           9413
8866
>     - average UPDATE transactions per second  258            256
254
>
>     - average DELETE transactions per second  1371           1442
1342
>
>     - average PREPARED INSERT trans per sec   17995          19262
13443
>
>     - average PREPARED UPDATE trans per sec   304            309
317
>     - average PREPARED DELETE trans per sec   1326           1239
1316
>
>     Apart INSERT operations, which seems to be 20-30% slower, all results
of
>     COOKED files are in line with those of RAW and BLOCK devices.
>
>
> I always knew that COOKED files should have been "much" slower than RAW
devices.
> Latest Informix Admin Guide, http://tinyurl.com/m2of2, does even state
this
> clearly (page 241 and following ones): <<The database server can use
regular
> operating-system files or raw disk devices to store data. On UNIX, you
should
> use raw disk devices to store data whenever performance is important.
[...]
> When dbspaces reside on raw disk devices (also called character-special
> devices), the database server uses unbuffered disk access. Performance is
much
> better when you use raw disk devices than cooked files because the
database
> server has direct I/O access to the devices. A raw disk directly transfers
data
> between the database server memory and disk without also copying data.>>
>
> So, here are my questions:
> - The machine that have been used features 256Mb of cache on the disks
>    controller: how much do you think this influenced the results,
especially in
>    giving advantage to the filesystem-based (COOKED) dbspace compared to
the
>    low-level access (RAW / BLOCK) to the devices?
>
> - Given the same combination of OS and Informix version, are similar
results
>    to be always and reasonably expected, independently from the underlying
>    hardware (with/without disk cache etc.)?
>
> - Test #1 was clearly won by COOKED files configuration, but that test is
not
>    representative of a typical OLTP kind of I/O: having an OLTP
application that
>    needs to run on the machine, would you trust what Informix says in its
>    Admin Guide (see above) and results of #2 or go for COOKED files
instead?
>
> - In which proven cases the sentence from Informix documentation "On UNIX,
you
>    should use raw disk devices to store data whenever performance is
important"
>    is to be taken in consideration? OLTP-style usage or what?
>
> - Any obvious reason why in test #2 only INSERT (not UPDATE nor DELETE)
>    operations were significantly slower when using COOKED files based
dbspaces?
>
> Hope my findings might be of some interest for someone.
>
> Waiting for your feedback on my questions,
>
> Ciao,
>    Rupan3rd (from Italy)
>


0
Noel
6/30/2006 4:09:53 PM
Reply:

Similar Artilces:

Raw device VS cooked file
Hi everybody, a question about raw VS cooked once again (sorry about that), hopefully this time a bit different. I am using IDS 10.0 on Red Hat Enterprise Linux version 4, as well as on Solaris 8 and 9. I use Informix since years, and always have installed it making use of raw devices, since there always have been a clear statement in the IBM documentation telling that on UNIX raw devices are the suggested choice for the best I/O performance. The IBM IDS 10 Server Administrator Guide, http://publib.boulder.ibm.com/epubs/pdf/25122672.pdf, at page 241 says infact: -----------------...

RE: Raw device VS cooked file
In my experience with AIX. The new enhanced journal file system (JFS2), there are file system option to use SIO or DIO. Using DIO (direct io) gives pretty close results to raw partition with Oracle and Informix. I am not sure if Solaris, HPUX or Linux has any option similar to AIX Basim Chafik Senior Systems Analyst IBM Certified Advanced Technical Expert (CATE) 1.800.688.4895 basim.chafik@plx.com plexus (Division of BancTec) -----Original Message----- From: Rupan3rd [mailto:rupan.nospam.3rd@hotmail.com] Sent: Thursday, January 12, 2006 11:18 AM To: informix-list@iiu...

Re: raw vs. cooked files under linux #10
DA Morgan said: > Data Goob wrote: >> Art, >> >> Your points are well made, and I'm willing to admit I could be >> misinformed, but quite honestly you are working in an exceptional >> environment compared to a lot of environments out there. You >> make the assertion that everyone should simply get it when it >> comes to disk drives, and quite honestly very few of us can keep >> up with this. You also make the assumption that it is easy when >> you should see what I have to work with when using sys admins--you >>...

raw vs. cooked files under linux
Hi all, i am an linux newbie. I must shift our Databases from SCO Unix (IDS 7.31 UD4) to SuSE Linux Enterprise Edition 8.1 (2.4.21-190-smp glibc 2.2.5) or (8.2) or 9 and SuSE Linux Professional 9.3 (2.6.11.4 glibc 2.3.4) (IDS 7.31 UD8). Later on i want to upgrade (in place) to IDS 10.0. Which Version of SuSE Linux Enterprise Edition must I use (8.? , 9 ..)? Under Sco Unix we use raw-devices. Is it better to use cooked files or raw files under these Linux-Versions? A colleague mentioned, it can be, that later releases of Linux don't support raw-devices. Is that correct? ...

Re: raw vs. cooked files under linux
SCO -> Linux ... good ;) If you want to upgrade to IDS 10.0 then better use Suse 9 'cause IDS use Kernel 2.6 specific features like KAIO. There is a nice document on IDS 10 and Linux on IBM site (can't remember link...). Regarding cooked vs. raw devices O bet for raw devices, they are very easy to configure in linux and give you some benefits like KAIO for example. J. Heinz Weitkamp escribi�: > Hi all, > > i am an linux newbie. > I must shift our Databases from SCO Unix (IDS 7.31 UD4) to SuSE Linux > Enterprise Edition 8.1 (2.4.21-190...

AW: raw vs. cooked files under linux
Thank you very much, Jean and Sandor, for your quick answers. One question more: I saw in the List on link: http://www-306.ibm.com/software/data/informix/linux/ids.html that IDS 7.31.UD8 don't support SUSE SLES9. Do you know, whether IDS 7.31.UD8 works under SUSE SLES9, because first i want to install IDS 7.31.UD8 on Linux and later IDS 10.0 without (if possible) changing the Linux Version? Thanks. Heinz -----Urspr�ngliche Nachricht----- Von: Sandor Szabo [mailto:sandor.szabo@de.ibm.com] Gesendet: Mittwoch, 11. Mai 2005 13:31 An: Heinz Weitkamp Cc: user-group Info...

RE: raw vs. cooked files under linux #3
We're about to setup a new client on IDS 10 on Linux and I've now seen two recommendations for SUSE in relation to IDS 10. Does anyone have experience with Redhat Enterprise Edition and IDS 10? Any issues there that we should be aware of? Bill Weaver Director of Engineering Amicus, Inc. 512-531-3463 (office) 512-531-3401 (fax) -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of Sandor Szabo Sent: Wednesday, May 11, 2005 6:31 AM To: Heinz Weitkamp Cc: user-group Informix (E-Mail); owner-informix-list@iiug...

Re: raw vs. cooked files under linux #7
We are running 24 instances of IDS 9.4 on 24 machines - about 95% raw chunks - no problems so far -Can you explain some of your reasoning below? What specifically are the risks and additional management? ----- Original Message ----- From: "Data Goob" <datagoob@netscape.net> To: <informix-list@iiug.org> Sent: Wednesday, May 11, 2005 9:08 PM Subject: Re: raw vs. cooked files under linux > Art S. Kagel wrote: > > Heinz Weitkamp wrote: > > > >> Hi all, > > > > > > Go RAW all the way. Contrary to the Goob'...

RE: raw vs. cooked files under linux #6
When you compare cooked versus raw here, are you focusing on Linux only, or talking about this in general - other Unix platforms as well ? -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of Data Goob Sent: 11 May 2005 03:08 PM To: informix-list@iiug.org Subject: Re: raw vs. cooked files under linux If you are in a slow-change environment raw-files are not a bad thing. They create extra problems on the management side that cooked files do not. Fast-changing environments create more demand on your time so why put y...

Re: raw vs. cooked files under linux #4
I guess almost all of us are convinced at this point of the performance improvement from using raw devices. But it would be great if we could get a benchmark report with a couple of Filesystems, specially on Linux, just in case we really need to use Filesystems. (JFS, Ext3, XFS , ReiserFS, ... ) I am a fan of XFS on Linux, because of its speed/stability/reliability against the other filesystems. I would be glad to see if XFS is better for database-OLTP performance or not. Could someone point us to a benchmark report of filesystems/raw devices ? Best Regards ----- Origina...

Re: raw vs. cooked files under linux #2
Dear Heinz, I would suggest that you pick SUSE SLES 9 This SUSE version works perfectly with IDS 10. Please check the following link: http://www-306.ibm.com/software/data/informix/linux/ids.html With IDS 10 you have the freedom of choice to use cooked or raw devices with KAIO This link should answer your raw device support question http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0503szabo/?ca=dgr-lnxw41IDSTen Let me know if you have any additional questions. bye Sandor IBM Informix Development Munich Information Management Hollerithstra�e 1 81...

Re: raw vs. cooked files under linux #8
How does one use O_SYNC with and ext3 filesystem on Linux? I don't see it mentioned anywhere. Normally I use raw but SA and management would rather use cooked. They would also rather use Postgres but that another story. Thanks >You assert that cooked files are as fast today as RAW on SANs. Have YOU >tested it? Are you comparing RAW to COOKED with O_SYNC? Or are you >depending on the vendor stats? Not me, not with my reputation, user >satisfaction, and my job at stake. > > sending to informix-list Peter J Diaz de Leon wrote: > How doe...

RE: raw vs. cooked files under linux #9
-----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of John Carlson Sent: 13 May 2005 03:48 AM > >Almost zero? Will you be in Denver? Come see how many Informix DBAs attend >my own sessions or Jonathan's or Lester's. There are a lot more of us out >there then you imagine. > [snip] >As for the job security comments . . . just remember that there are >still a goodnumber of DBAs who will not be able to go to Denver. True, my company will only allow me to go places I can drive ...

RE: raw vs. cooked files under linux #5
We use raw chunks on all our unix versions. Most are Linux. We find it easier to set up and manage raw devices, including under Linux. We also have a SAN environment running RAW devices under Linux - no problems at all. We have not had any issues and that includes recovering systems. Its all very simple when using RAW devices. MW > -----Original Message----- > From: owner-informix-list@iiug.org > [mailto:owner-informix-list@iiug.org] On Behalf Of Data Goob > Sent: Thursday, 12 May 2005 1:09 p.m. > To: informix-list@iiug.org > Subject: Re: raw vs. cook...

Getting name of device which is bind to raw device if i have raw device name
Hi Can any one tell me Ihave a raw device is bind to a logical volume How to get the logical volume name from the name of the raw device Thanks , Sachin sachin wrote: > > Hi > Can any one tell me > Ihave a raw device is bind to a logical volume > How to get the logical volume name from the name of the raw device That is imposible. You can get the device number by using the RAW_GETBIND ioctl (like raw -q does). But there is no way to get the device name from the device number (other than searching through all of /dev and hoping to find the right nod...

blocking i/o vs. non-blocking i/o
Hi, I'm writing (in linux) a proxy application for rfb protocol (vnc), but i'm not satisfied with it's performance. I'm using blocking i/o and my app just read(...) from source and the write(...) to destination. The performance diference (over a 100mbits lan) between the client directly connected to the server and the client passing thru the proxy is very visible. Does non-blocking i/o solves my problem? Maybe the problem here is the unnecessary(?) wait in (blocking) write(...) function. thank you. obs. sorry about my poor english. In article <29d62503.0310100448.4f09fdf2...

Raw vs. Cooked files
Hello, I am installing IDS 10 on RHEL3 on an intel x86 server. I need to make the choice between raw devices and cooked files. I found the following information in the FAQ's. Is this information still accurate? Do cooked files continue to be significantly slower than the raw files? I have heard that UNIX file systems have improved over the years and the performance divide between raw and cooked files has narrowed considerabley. Is it true? Thanks! - Rajesh -------------------------------------------------------------------------------------- 6.38 Is raw disk faster th...

Can I create a file-based standby database for a RAC database on raw device?
RDBMS Version: 9.2.0.5 Operating System and Version: Solaris 8 Error Number (if applicable): Product (i.e. SQL*Loader, Import, etc.): Data Guard Product Version: 9.2.0.5 Can I create a file-based standby database for a RAC database on raw device? We want to setup a disaster recovery site for a RAC database on raw device. For reducing the work of configurations, we consider to use a file-based datbase as the remote standby database. Is there any problem or compatible issue to do this ? Regards, William On Thu, 30 Sep 2004 05:28:55 +0200, William wrote (in article <544e016e.0409291928...

mounting eeprom device as file system block device ?
Hi Is there anything available in sourcecode so i can mount an serial eeprom as a disk device ? I currently have eeprom access in userspace but i would like to have a driver so from user point of view it behaves like a disk (mountable ) drive Any hints ? Regards Johan i am talking about small serial eeprom devices (64K bit) "Sagaert Johan" <sagaert.j AT belgacom.net> wrote in message news:433280c8$0$18366$ba620e4c@news.skynet.be... > Hi > > Is there anything available in sourcecode so i can mount an serial eeprom as > a disk device ? ...

blocking i/o vs. non blocking i/o (performance)
Hi, I'm writing a proxy application for rfb protocol (vnc), but i'm not satisfied with it's performance. I'm using blocking i/o and the app just read(...) from source and the write(...) to destination. The performance diference between the client directly connected to the server and the client passing thru the proxy is very visible. Does non-blocking i/o solves my problem? Maybe the problem here is the unnecessary(?) wait in write(...) function. thank you. obs. sorry about my poor english. On 9 Oct 2003 21:03:12 -0700, andre@kelmanson.net (Andre Kelmanson) wrote in comp.lang...

Re: Raw devices vs. Filesystems
Remarkable, perhaps, to you. Not in the Informix world. But irrelevant to postgres, no ? -----Original Message----- From: Chris Browne [mailto:cbbrowne@acm.org] Sent: Tuesday, April 06, 2004 1:57 PM To: pgsql-admin@postgresql.org Subject: Re: [ADMIN] Raw devices vs. Filesystems gsw@globexplorer.com ("Gregory S. Williamson") writes: > No point to beating a dead horse (other than the sheer joy of the > thing) since postgres does not have raw device support, but ... raw > devices, at least on solaris, are about 10 times as fast as cooked > file systems for Informix. This...

Re: Raw vs. Cooked files
Yes even with DB2 UDB you can get 20-25% improvement going with RAW over Cooked. If you use cooked the IO has to be written by the Unix Operating system - another set of commands to execute. Raw is controlled by the database. Why o Why Are we still having this discussion? Rob Vorbroker --- Rajesh Kapur <rkapur@mpr.org> wrote: > Hello, > > I am installing IDS 10 on RHEL3 on an intel x86 > server. I need to make the > choice between raw devices and cooked files. > I found the following information in the FAQ's. Is > this information still ...

Re: Raw devices vs. Filesystems
Remarkable, perhaps, to you. Not in the Informix world. But irrelevant to postgres, no ? -----Original Message----- From: Chris Browne [mailto:cbbrowne@acm.org] Sent: Tuesday, April 06, 2004 1:57 PM To: pgsql-admin@postgresql.org Subject: Re: [ADMIN] Raw devices vs. Filesystems gsw@globexplorer.com ("Gregory S. Williamson") writes: > No point to beating a dead horse (other than the sheer joy of the > thing) since postgres does not have raw device support, but ... raw > devices, at least on solaris, are about 10 times as fast as cooked > file systems for Informix. This...

Measurements: (was: Raw vs. Cooked files)
Hi, if you are interested : http://www.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130667.pdf (There's a part where they tested raw devices vs. file system files as well. These measurements were all done on zSeries, not by myself as I did not get to do such extensive work. But this document is really extensive ...) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management owner-informix-list@iiug.org wrote on 19.05.2005 16:43:23: > Martin Fuerderer wrote: > > Hi, > > I emailed a simple r...

Web resources about - IDS 10 on RHEL4 Linux: I/O benchmark of RAW DEVICES vs BLOCK DEVICES vs COOKED FILES - comp.databases.informix

Benchmark (venture capital firm) - Wikipedia, the free encyclopedia
Benchmark is an American venture capital firm responsible for the early stage funding of several successful startups . In 1997, the firm invested ...

Hootsuite Announces Global Agency Partner Program, Social Business Benchmark Survey Results
... and their account teams stay on top of social media trends and technology, and it released the results of its Hootsuite Social Business Benchmark ...

LinkBench: A database benchmark for the social graph - Facebook
Facebook Engineering hat eine Notiz mit dem Titel LinkBench: A database benchmark for the social graph geschrieben. Du kannst den vollständigen ...

Case Study: Auto brand, SPMD SocialCode beat Facebook ad CPA benchmark by 27 percent
... Preferred Marketing Developer SocialCode shows that an auto brand working with SocialCode was able to use Facebook ads to beat CPA benchmarks ...

faroo_p2p: 1000x Faster Spelling Correction updated: The benchmark is in! http://t.co/oY18ohyd #faroo ...
faroo_p2p: 1000x Faster Spelling Correction updated: The benchmark is in! http://t.

Andy Rachleff of Benchmark Capital claims that annually, there are 15 technology companies created that ...
Answer (1 of 3): Unfortunately I never published this research. It was prepared for a speech I gave a number of years ago and then updated. That ...

Bonsai Benchmark on the App Store on iTunes
Get Bonsai Benchmark on the App Store. See screenshots and ratings, and read customer reviews.

All sizes - MySpace Sandbox Developer Party - Bill Gurley of Benchmark Capital - Flickr - Photo Sharing ...
Flickr is almost certainly the best online photo management and sharing application in the world. Show off your favorite photos and videos to ...

Micromax Yu Yureka Long Review, Camera, Benchmarks, Price, Cyanogen User Interface Overview - YouTube ...
Visit http://www.gadgetstouse.com - to read more detailed reviews, unboxing, hands on and overview of smartphones, tablets, tech and gadgets ...

Brent joins other oil benchmarks below $80 a barrel
... year above $115. Brent crude fell below US$80 a barrel for the first time in more than four years on Thursday, joining the Asian regional benchmarks ...

Resources last updated: 2/28/2016 6:13:18 AM