Hi
I've got Sybase using a ramdisk for storage. It is currently
partitioned as JFS but I'm thinking of changing it to raw to avoid the
secondary O/S caching. A colleague has expressed concerns about the
performance of raw ramdisks and I wondered if anyone had any experience
or advice.

thanks
Mark

Hey Mark,

My experience is on Solaris and HP/UX but with the advent of ASE 12.0
(I believe that was the release) SYBASE allows for real-time writes to
file-system-based databases by setting the "dsync" parameter to "true"
on a device. This will cause SYBASE/kernel to bypass the O/S cache and
issue a real write to the file-system device. This parameter has no
meaning if the device is raw. Of course I would orchestrate a test in
your environment if performance is the issue. Tempdb on a ramdisk
filesystem is good ... and set the "dsync" value to "false" because
tempdb is not recoverable anyway ...

Hope this helps ...

Cheers,

Sara ...

markg wrote:
> Hi
> I've got Sybase using a ramdisk for storage. It is currently
> partitioned as JFS but I'm thinking of changing it to raw to avoid the
> secondary O/S caching. A colleague has expressed concerns about the
> performance of raw ramdisks and I wondered if anyone had any experience
> or advice.
>
> thanks
> Mark

Sarah
thanks for the info. I think dsync is set to false at the moment: we're
not worried about the write flushing just the memory overhead of the
secondary caching of the ram disk. The man page for the mkramdisk
command seems to recommend not using the ramdisk as a block device due
to "overhead".

"DBAGAL" <saradba@hotmail.com> wrote in
news:1128633162.029177.289470@g43g2000cwa.googlegr oups.com:

> My experience is on Solaris and HP/UX but with the advent of ASE
> 12.0 (I believe that was the release) SYBASE allows for real-time
> writes to file-system-based databases by setting the "dsync"
> parameter to "true" on a device. This will cause SYBASE/kernel to
> bypass the O/S cache and issue a real write to the file-system
> device.

Hi Sara,

Setting DSYNC to true makes the write post to disk rather than to
memory. The write still moves from User Space, to kernel buffers,
to disk. This is what makes DSYNC = true inefficient and why using
raw is the best way to go for true write performance.

If your database(s) are read-mostly, I can see using DSYNC = true on
their data devices. Or for tempdb, setting DSYNC = false (if your
O/S supports it).

Cheers!
--
Pablo Sanchez - Blueoak Database Engineering, Inc
http://www.blueoakdb.com

Hey Pablo ...

Thanks for the detail ... I think I see the pattern ... I am currently
testing the "directio" parameter for large volume data loads on
file-system resident database devices on a copy of the GA release of
ASE 15.0 (Solaris) ... Do you think this makes file-system resident
devices "equivalent" in terms of write-performance to raw volume
devices??

TIA,

Sara ...

Pablo Sanchez wrote:
> "DBAGAL" <saradba@hotmail.com> wrote in
> news:1128633162.029177.289470@g43g2000cwa.googlegr oups.com:
>
> > My experience is on Solaris and HP/UX but with the advent of ASE
> > 12.0 (I believe that was the release) SYBASE allows for real-time
> > writes to file-system-based databases by setting the "dsync"
> > parameter to "true" on a device. This will cause SYBASE/kernel to
> > bypass the O/S cache and issue a real write to the file-system
> > device.
>
> Hi Sara,
>
> Setting DSYNC to true makes the write post to disk rather than to
> memory. The write still moves from User Space, to kernel buffers,
> to disk. This is what makes DSYNC = true inefficient and why using
> raw is the best way to go for true write performance.
>
> If your database(s) are read-mostly, I can see using DSYNC = true on
> their data devices. Or for tempdb, setting DSYNC = false (if your
> O/S supports it).
>
> Cheers!
> --
> Pablo Sanchez - Blueoak Database Engineering, Inc
> http://www.blueoakdb.com

"DBAGAL" <saradba@hotmail.com> wrote in
news:1128989254.826665.242360@z14g2000cwz.googlegr oups.com:

> Hey Pablo ...
>
> Thanks for the detail ...

yw.

> I think I see the pattern ... I am
> currently testing the "directio" parameter for large volume data
> loads on file-system resident database devices on a copy of the GA
> release of ASE 15.0 (Solaris) ... Do you think this makes
> file-system resident devices "equivalent" in terms of
> write-performance to raw volume devices??

I believe it brings it closer in line with raw however I don't have
any recent numbers.

I realize most folks are comfortable with 'cp' but 'dd' isn't too
difficult to copy raw devices from raw to cooked/raw.

Cheers!
--
Pablo Sanchez - Blueoak Database Engineering, Inc
http://www.blueoakdb.com