Sybase on AIX: JFS or raw device? 2

[uxs]

We are running AIX 4.3.3 on a RS/6000-H80 (4way, SSA-D40-Disksubsystem) with Sybase 11.5.1, with asynchronous I/O.

We installed the sybase on 3 different ways:
1) IBM H80 SSA-Disks / AIX 4.3.3 / raw device
2) IBM H80 SSA-Disks / AIX 4.3.3 / JFS-filesystem
3) SUN Ultra5 internal Disk / Solaris 8 / raw device

Reading the sybase-documentations everybody says: install sybase on raw device!
But: Installed on AIX-raw-device (1) the system is very slow, we have WIO of 80% on creating databases and running the application. We can see, that the system writes more or less 400kBytes per second.

On a JFS-filesystem (2, same hardware) these tests are a lot faster! There is a difference up to factor 80 (eighty!) on sequencial reads or factor 5 on random reads.

We tried the sybase-installation on a SUN Ultra 5 (small workstation): here the raw-device-test ist fast, "similar" to the JFS-filesystem on the highend-IBM-H80!

Now, why the raw-device on AIX is so slow in comparison to the raw device on solaris? Is somewhere any parameter to change on AIX?

 

[ChrisBroadway]

Ok I'm not a DBA but I'd guess you've changed to raw devices without changing your RDBMS Buffer Pool Size ( or whatever Sybase calls is) ...
Under JFS a large proportion of your memory is being used for FS cache therefore you are getting reasonable performance. However when you change to raw you need to make sure that your database earmarks most of sysem memory for its usage.. Don't ask me how, I don't speak Sybase but I guess this may be where your problem lies

good luck

 

[Tison]

We also gave a lot of thought to RAW or JFS.
A DBA is only as good as his data so our conclusion was that although JFS was slightly faster , RAW was safer.
Here is an explanation I got from an expert ;
-----------------
RAW is "supposed" to give you unbuffered I/O writes
i.e. we are guarantied that when the OS signals that a I/O write is complete - then it has actually been done.
I say "supposed" as most disk subsystems have RAM buffers nowadays and simply report completed I/O when info is in buffer not physically on disk ..

File Systems will buffer I/O writes which means that in certain extreme circumstances involving power outages when can have the OS reporting that I/O was done when actually it was not - resulting in corruption of data.

File Systems I/O are much faster than RAW
File Systems I/O will use much more RAM as the OS needs to manage the file system

so
RAW is "safer" and slower
FS is faster but more risky

the official Sybase position is to recommend RAW devices for production systems.
----------
Hope this helps
Steve

 

[MikeLacey]

Steve,

Interesting. Oracle suggest that raw partitions are faster than file-system partitions. This is because using a filesystem for a database file (Oracle *or* Sybase for that matter) will result in "double-buffering"

The database will do caching - and then the filesystm will do caching as well. What people generally forget (me included) is that whilst the general rule is "the larger the cache buffer the more faster it will go" there are two big exceptions.

1. Double buffering -- because the system will play musical pages twice, so you get twice the overhead.
2. When a cache reaches a certain size the overhead required to maintain it will overtake any advantage from using it -- you can have a cache that's too big....

It seems to me that Chris' comment above has much to reccomend it to uxs. It's likely that you need to increase the amount of RAM available to Sybase as a buffer cache.

If you have a benchmark application I would test it with the db_buffer_cache equal to the old_db_buffer_cache + old_unix_buffer_cache and the:

db_buffer = old buffer_cache + copies of the databadr.

I can't commit to any dates yet.... Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[ChrisBroadway]

Chaps ...

Check out the IBM Redbook Database Performance on AIX in DB2 UDB and Oracle Environments.. This certainly suggests that databases are likely to be faster on raw device.. Of course this doesn't cover Sybase so I'd be most interested to find out if it acts differently to other RDBMS ...

I've always been taught that raw = fast but more difficult to administer whereas FS are slower due to the reasons outlined by Mike but have the advantage of much easier admin..

Of course the only answer is try it and see as it ultimately depends on your database characteristics..In my experience FS might be better for sequential IO whilst random IO tends to favour raw ...

Also I've gotta admit that worrying about a JFS failure is (IMHO) horribly paranoid.. Unjournaled FS, I'd be concerned about but journalled FS are hugely resilient ... For further paranoia remember that disks have caches so the OS will usually report a write to disk when the data hits the cache, not the disk surface.. Theoretically you could still lose data on a raw device if power fails and you lose the contents of the cache

Anyway just my ha'pennies worth

 

[MikeLacey]

"worrying about a JFS failure is (IMHO) horribly paranoid"

[tab]yep Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[duffbeer]

These days, performance differences between raw & filsystem I/O are neck and neck, and the debate about which is better often turns into a religous argument. Speed has little to do with my preference for raw spaces.

As a former DBA who has worked with both, I prefer raw for a few reasons:

- The database does an excellent job of maintaining raw space with its own "filesystem" of sorts and tends to remain statc. Tweaks and variations between the various vendor filesystems sometime create annoying problems and/or inconsistencies.

- While raw spaces are much harder for clueless and/or overworked admins to overwrite or otherwise destroy.

- I have seen situations where metadata journaling leaves a database in an inconsistent state, requiring the db engine to run a lengthy recovery.

In some situations, 'cooked' or filesystem based dbspaces are a better way to go. Especially when a database changes often and often has dbspaces deleted or moved.