SEO

Hi.

During the testing of the OKP module for UnixWare 7.1.3 I found out
something I'd like to share with the group.

I'm in the process of writing a large article which will be (hopefully)
published on Tony Lawrences' site but I'd like some comments about the
following issue before actually publishing it.

For those of you unaware of it, OKP is a module which allows the
execution os unmodified OS5 binaries on UnixWare 7; the LITE version is
freely downloadable from SCO's site whereas the FULL version (which
comes with a 5.0.7 media kit) comes with a small fee.

I selected a given box (PIII-700, 256MB, Adaptec 39160 SCSI controller,
1 8GB SCSI disk) for my tests; the above HD was divided into 2
partitions. The first one got installed with SCO OS 5.0.7 + MP1 and the
second one was a UnixWare 7.1.3 + MP3.

I installed Informix OnLine 7.31 for SCO OS5 on the first one, tuned
some kernel parameters as suggested by Informix and performed some
tests, such as the "dbimport" of a previously exported dbase, the
"update statistics high" on the root dbspace and a "select" on a couple
of non-indexed tables.

The above parameters were mainly related to the SHARED MEMORY, an IPC
mechanism highly used by Informix during its operations.

On UW 7.1.3, I installed OKP and "imported" the OS 5.0.7 filesystem from
another box (running the same OS & Informix version), set up the same
Informix environment, I did __NOT__ tune the UW7 kernel as suggested
(since UW7 kernel has some auto-tuning parameters which does not require
it) and performed the very same tests as above.

Mind you that, after every test, I rebooted the box as to avoid a
possible performance boost due to the disk caching system and that every
test was repeated several times and measured with "time".

I had some soft of mixed results.

The "dbimport" procedure (a procedure which performs a lot of write
operations) was faster on the "real" OS5 (9m41s vs 10m44s) but the
"update statistics high" (mainly read ops) was faster under OKP (1m06s
vs 1m38s).

The "select" procedure (again, a read op) saw OKP literally
outperforming OS5, with a time of 1m21s against 4m47s.

I performed some other non Informix related tests such as "openssl
speed" (OS5 outperformed - in some case - OKP by a factor of 2-3%) and a
"tar xvf" of a 80MB file, which again showed that OS5 was faster (20s vs
1m04s).

Keeping in mind that I did __NOT__ tune both kernels as to provide
optimized filesystem performances, I was wondering if UnixWare7/OKP (out
of the box) can indeed be faster than OS5 while __READING__ and slower
while __WRITING__.

I know that I might tune both kernels to achieve a speed enhancement but
I'd like to know the opinion of the group before proceeding with further
tests.

--
Best,
Roberto
--
Roberto Zini - Technical Support Manager - email:r.zini<AT>strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)

On Wed, 14 Jan 2004 12:15:49 +0100, Roberto Zini <rob@robnothere.com> wrote:

> I performed some other non Informix related tests such as "openssl
> speed" (OS5 outperformed - in some case - OKP by a factor of 2-3%) and a
> "tar xvf" of a 80MB file, which again showed that OS5 was faster (20s vs
> 1m04s).

UnixWare's 'tar' and UnixWare's default filesystem paramaters conspire
to deliver an, uuuuh, less than satisfying performance experience.
The rapid creation of files and the explict call to fsync is an
achilles heel. Be sure your filesystems are being mounted without
'mincache=closesync' to help things along. I also find GNU tar to be
about 30% faster on extraction than either of the System V tars shipped
with UnixWare.


> optimized filesystem performances, I was wondering if UnixWare7/OKP (out
> of the box) can indeed be faster than OS5 while __READING__ and slower
> while __WRITING__.

I know both systems reasonably well and I'm sure I can produce a test
showing either one faster depending on who is asking. :-) The results
you posted aren't really suprising to me. I do suspect with only minor
tweaking, you can reduce or eliminate the write penalty.

On modernish, robust hardware, it doesn't suprise me that UnixWare +
one of the personality modules outperforms the OS being impersonated
in many (not all) cases. If the environment being tested it totally
computationally bound in user space, I'd expect it to be a wash. The
more time you spend using OS services like VM or I/O, the more you're
likely to gain, but there are specific services that will go either way.


The filesystem paramaters have a LOT to do with perceived performance,
esp in a case like your tar extraction test. If you're spending your
life creating and writing what are essentially temporary files (as one
might be when, say, compiling software) it's worth noting that the UW
filesystem defaults may penalize you.

http://uw713doc.sco.com/en/FS_admin/...ount_Mode.html
http://uw713doc.sco.com/en/ODM_FSadmin/fssag-8.html

Robert Lipe wrote:
> On Wed, 14 Jan 2004 12:15:49 +0100, Roberto Zini <rob@robnothere.com> wrote:
>
>
>>I performed some other non Informix related tests such as "openssl
>>speed" (OS5 outperformed - in some case - OKP by a factor of 2-3%) and a
>>"tar xvf" of a 80MB file, which again showed that OS5 was faster (20s vs
>>1m04s).

Robert,

first of all thanks for taking the time to provide me (and the group)
with useful findings and tips !

>
>
> UnixWare's 'tar' and UnixWare's default filesystem paramaters conspire
> to deliver an, uuuuh, less than satisfying performance experience.
> The rapid creation of files and the explict call to fsync is an
> achilles heel. Be sure your filesystems are being mounted without
> 'mincache=closesync' to help things along. I also find GNU tar to be
> about 30% faster on extraction than either of the System V tars shipped
> with UnixWare.
>

I knew about that but the aim of my tests was to compare things on
unmodified/not tweaked systems since I expect not all users are able to
tune fs performances of their systems.

>
>
>>optimized filesystem performances, I was wondering if UnixWare7/OKP (out
>>of the box) can indeed be faster than OS5 while __READING__ and slower
>>while __WRITING__.
>
>
> I know both systems reasonably well and I'm sure I can produce a test
> showing either one faster depending on who is asking. :-)

Yup !

> The results
> you posted aren't really suprising to me. I do suspect with only minor
> tweaking, you can reduce or eliminate the write penalty.
>
> On modernish, robust hardware, it doesn't suprise me that UnixWare +
> one of the personality modules outperforms the OS being impersonated
> in many (not all) cases. If the environment being tested it totally
> computationally bound in user space, I'd expect it to be a wash. The
> more time you spend using OS services like VM or I/O, the more you're
> likely to gain, but there are specific services that will go either way.

Agreed.

>
>
> The filesystem paramaters have a LOT to do with perceived performance,
> esp in a case like your tar extraction test. If you're spending your
> life creating and writing what are essentially temporary files (as one
> might be when, say, compiling software) it's worth noting that the UW
> filesystem defaults may penalize you.
>
> http://uw713doc.sco.com/en/FS_admin/...ount_Mode.html
> http://uw713doc.sco.com/en/ODM_FSadmin/fssag-8.html
>

Thanks for the above pointers.

I hope today I'll be able to perform some tests with a minor fs tweaking
and I'll post the groups with the results.

Thanks again,
Roberto
--
Roberto Zini - Technical Support Manager - email:r.zini<AT>strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)

Robert Lipe wrote:
> On Wed, 14 Jan 2004 12:15:49 +0100, Roberto Zini <rob@robnothere.com> wrote:
>
>
>>I performed some other non Informix related tests such as "openssl
>>speed" (OS5 outperformed - in some case - OKP by a factor of 2-3%) and a
>>"tar xvf" of a 80MB file, which again showed that OS5 was faster (20s vs
>>1m04s).
>

[snip]

>
>>optimized filesystem performances, I was wondering if UnixWare7/OKP (out
>>of the box) can indeed be faster than OS5 while __READING__ and slower
>>while __WRITING__.
>
>
> I know both systems reasonably well and I'm sure I can produce a test
> showing either one faster depending on who is asking. :-) The results
> you posted aren't really suprising to me. I do suspect with only minor
> tweaking, you can reduce or eliminate the write penalty.
>
> On modernish, robust hardware, it doesn't suprise me that UnixWare +
> one of the personality modules outperforms the OS being impersonated
> in many (not all) cases. If the environment being tested it totally
> computationally bound in user space, I'd expect it to be a wash. The
> more time you spend using OS services like VM or I/O, the more you're
> likely to gain, but there are specific services that will go either way.
>
>
> The filesystem paramaters have a LOT to do with perceived performance,
> esp in a case like your tar extraction test. If you're spending your
> life creating and writing what are essentially temporary files (as one
> might be when, say, compiling software) it's worth noting that the UW
> filesystem defaults may penalize you.
>
> http://uw713doc.sco.com/en/FS_admin/...ount_Mode.html
> http://uw713doc.sco.com/en/ODM_FSadmin/fssag-8.html
>

Robert,

during my tests I mainly operated under the /openserver/home filesystem;
from what I gathered from /etc/vfstab, it seems that both /linux/home
and /openserver/home are related to the lxuwfs. From the docs I see that
the lxuwfs is a special virtual filesystem that allows to "see" the UW7
native filesystem from LKP.

Could that be the reason behind the performances issues I had during my
tests ?

Thanks,
Roberto
--
Roberto Zini - Technical Support Manager - email:r.zini<AT>strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)

Roberto Zini wrote:
> Robert Lipe wrote:
>
>> On Wed, 14 Jan 2004 12:15:49 +0100, Roberto Zini <rob@robnothere.com>
>> wrote:
>>
>>
>>> I performed some other non Informix related tests such as "openssl
>>> speed" (OS5 outperformed - in some case - OKP by a factor of 2-3%)
>>> and a "tar xvf" of a 80MB file, which again showed that OS5 was
>>> faster (20s vs 1m04s).
>
>
> Robert,
>
> first of all thanks for taking the time to provide me (and the group)
> with useful findings and tips !
>
>>
>>
>> UnixWare's 'tar' and UnixWare's default filesystem paramaters conspire
>> to deliver an, uuuuh, less than satisfying performance experience.
>> The rapid creation of files and the explict call to fsync is an
>> achilles heel. Be sure your filesystems are being mounted without
>> 'mincache=closesync' to help things along. I also find GNU tar to be
>> about 30% faster on extraction than either of the System V tars shipped
>> with UnixWare.
>>
>
> I knew about that but the aim of my tests was to compare things on
> unmodified/not tweaked systems since I expect not all users are able to
> tune fs performances of their systems.
>
>>
>>
>>> optimized filesystem performances, I was wondering if UnixWare7/OKP
>>> (out of the box) can indeed be faster than OS5 while __READING__ and
>>> slower while __WRITING__.
>>
>>
>>
>> I know both systems reasonably well and I'm sure I can produce a test
>> showing either one faster depending on who is asking. :-)
>
>
> Yup !
>
>> The results
>> you posted aren't really suprising to me. I do suspect with only minor
>> tweaking, you can reduce or eliminate the write penalty.
>>
>> On modernish, robust hardware, it doesn't suprise me that UnixWare +
>> one of the personality modules outperforms the OS being impersonated
>> in many (not all) cases. If the environment being tested it totally
>> computationally bound in user space, I'd expect it to be a wash. The
>> more time you spend using OS services like VM or I/O, the more you're
>> likely to gain, but there are specific services that will go either way.
>
>
> Agreed.
>
>>
>>
>> The filesystem paramaters have a LOT to do with perceived performance,
>> esp in a case like your tar extraction test. If you're spending your
>> life creating and writing what are essentially temporary files (as one
>> might be when, say, compiling software) it's worth noting that the UW
>> filesystem defaults may penalize you.
>>
>> http://uw713doc.sco.com/en/FS_admin/...ount_Mode.html
>> http://uw713doc.sco.com/en/ODM_FSadmin/fssag-8.html
>>
>
> Thanks for the above pointers.
>
> I hope today I'll be able to perform some tests with a minor fs tweaking
> and I'll post the groups with the results.
>

Hi.

This afternoon I played a bit with the root fs mount options as to find
out if it was possibile to enhance the performance of the Informix
server under OKP.

During my original tests, I installed the dbase under
/openserver/home/informix; from the vfstab file I found out that
/openserver/home is managed by the lxuwfs so I'm not sure if the first
test I made was effective or not.

Anyway, I aggressively modified the mount parameters for the root (/)
filesytem as follows:

tmplog,convosync=delay,mincache=tmpcache

After rebooting the system I performed the "dbimport" procedure but it
took the same time (10m47s).

So, I reverted the changes into /etc/vfstab and moved the INFORMIX
directory out of /home, and precisely under /openserver/usr/informix
(which should be handled by the vxfs filesystem).

Again, I made the same changes in vfstab but I ended up having the very
same results (10m47s).

Last, I changed the mount options with

log,convosync=dsync

rebooted, performed the same tests and got the same time (10m47s).

Well, perhaps I'm not the greatest "tweaker" in the world but I'd have
expected to see different results.

Mind you that the dbspace is __NOT__ handled in a raw partition but it's
under /openserver/usr/informix/dev (is a regular file).

Robert, are you in the position to suggest a "more aggressive" tweaking
as to boost up the filesystem performance (if possible) ?

Thanks,
Roberto
--
Roberto Zini - Technical Support Manager - email:r.zini<AT>strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)