Operating System - OpenVMS
1748235 Members
3297 Online
108759 Solutions
New Discussion юеВ

Postmark benchmark on OpenVMS

 
SOLVED
Go to solution

Re: Postmark benchmark on OpenVMS

That benchmark opens files with standard fopen/open (without any of the needed VMS kludges to be competetive). Unless one have other VMS and RMS system parameters changed those open kludges are needed.

Some of the things you can test...
SET VOLUME/NOHIGHWATER
SET RMS/BLOCK_COUNT=124
SYSMAN RMS_SEQFILE_WBH 1
SYSMAN ACP_DATACHECK 0
ENABLE SCSI WRITE CACHE ;)

As for databases, I would argue that OpenVMS's file system is actually better than Windows and UNIX for real database systems. Windows have a journaling file system and most UNIXes also today, which is not what a database system want.

There are reasons why Windows based and most UNIX based TPC-C benchmarks have to use raw device and bypass the filesystems completely. That is not needed on OpenVMS.

/Daniel - Mimer SQL Development
Hein van den Heuvel
Honored Contributor

Re: Postmark benchmark on OpenVMS

Jose>> Using the filesystem as a database is a workaround for not having a proper database, or index-sequential files.

Right on.

Jose>> The librarian, didn't think of that yet.

On RSX-11M that was a solution even more worth considering, as you could 'open' blobs stored in a library as psuedo files.
So libraries were sort of a light file system within a robust (ODS-1) file system.


Joe>> What I would like is to simulate a
hierarchical structure, that is the good thing about the file system, so I was thinking of an index-sequential file with as key a bogus filename. Most files are shorter than 20k, so they would fit in a record.

Absolutely. Go for it!
That's fine usage of RMS indexed files.

And you could overflow large files to real files, like OpenVMS Mail does (except they overflow too soon @1500 bytes), or you could use extention records or (part-1, part-2,...), or just use duplicates indicating 'more' (RMS keeps dups in order of arrival).

RMS will provide the hierarchy, and a little bit of compression. It will also offer alternate keys to the file.

RMS will give you much better control over caching than a directory structure would: pick the optimal bucket sizes for data and index, select your own local buffers and global buffers and such.

>> I'm not sure if it's RMS perse that's causing
the overhead in this, I still have the feeling that most time is spent updating the directory file when creating and deleting files, which is more part of the file system than of RMS. (Isn't it?)

All the overhead in the Postmark test is in the file system. RMS really only gets involved with the actuall data record writing which has to happen no matter how you turn it and is a minor component in the scheme. RMS can also get involved with wildcard file lookup (not for staight names) and used to have this 128 block directory size performance limitation but that's long since fixed.

>> I googled around a bit, but could not find any evidence to support this feeling, nor anything against it. I guess I'll have to test it myself. Or does anyone have a pointer?

What exactly do you want to test here?
If the benchmark is written in C and writes 'simple' (stream-lf) files then the C RTL actually does RMS Block IO, not record IO. Block IO is an unmeasurably thin layer around SYS$QIO. The C RTL does its own thing because too many C program pushed a byte at a time toward RMS and the trip into EXEC mode and back which RMS needs to implement protected file sharing proved too costly for that. A good sized record at a time warrants probing buffers and control structures, but to have to do that every few bytes gets expensive.

Anyhow... if you are worried about RMS overhead vs system vs user, then all you need to do is MONITOR MODE during the run.
RMS is the EXEC MODE component.

WAG: I suspect your benchmark to show 3% User mode, 1% Exec, 30% Kernel, 5% Interupt, rest Idle = Wait


Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

Hein van den Heuvel
Honored Contributor

Re: Postmark benchmark on OpenVMS

Forgot to add something Jose probably knows... RMS indexed file record MUST entirely fit in a bucket. The Maximum bucket size is still 63 blocks and will not change (127 blocks = 16 bits would be readily conceivable). Thus RMS solutions are stuck with a maximum record size of about 32,000 bytes.

And you would want to take the key design, bucket size selections, and pre-allocations and such more serious than ever

Daniel>>
Unless one have other VMS and RMS system parameters changed those open kludges are needed.
Some of the things you can test...
SET VOLUME/NOHIGHWATER

Beg to differ! Bad rumor!
Yes, highwatermark can have a (performance) effect on certain usages, but just writting data sequentially into sequential files is NOT influenced by highwater marking

>> SET RMS/BLOCK_COUNT=124

The C RTL indeed listens to this to some degree.

>> SYSMAN RMS_SEQFILE_WBH 1

I don't this C RTL listens to that.

>> SYSMAN ACP_DATACHECK 0
>> ENABLE SCSI WRITE CACHE ;)

Yeah the scsi (disk level) write cache always was a big easy win for Unix workstations. They enabled it, VMS did not and even (used to?) refused to mount disks marked as such.

A real database implementation can not accept scsi write cache nor an unified IO buffer cache of other sorts.

>> As for databases, I would argue that OpenVMS's file system is actually better than Windows and UNIX for real database systems. Windows have a journaling file system and most UNIXes also today, which is not what a database system want.

Argreed from that perspective.
A good, quick FORK would help creating session quickly, allthough multythreading and AST coding can strech that nicely.

>> There are reasons why Windows based and most UNIX based TPC-C benchmarks have to use raw device and bypass the filesystems completely. That is not needed on OpenVMS

Right on.

Hein.
SDIH1
Frequent Advisor

Re: Postmark benchmark on OpenVMS

After having been distracted by other work, I found the time to do a quick test on Itanium and EVA4000, with an indexed sequential file
with 2064 byte records and a key of 64 bytes to reflect the virtual filename.
Writing 10000 records (even after the file already contains 120000 records) takes a stable 3.6 seconds. This is 2777 records a second.
This is without really optimizing on bucketsize, rms buffers, or what have you.

Nothing to be ashamed about and definitely within the range of the Postmark
benchmark results on Solaris, with the added advantage of record locking, being sure data is on disk etc.

Apparently somewhere around the 3000 ops/second number a hardware limit is reached.

Thanks all for the inspiring comments.

Dean McGorrill
Valued Contributor

Re: Postmark benchmark on OpenVMS

>the overhead in this, I still have the feeling that most time is spent updating the directory file when creating and deleting files, which is more part of the file

absolutely if there are many files. just
ask a old time vms user who'd let thousands
and thousands of his mail messages pile up in
one directory :)
SDIH1
Frequent Advisor

Re: Postmark benchmark on OpenVMS

I close the thread, most relevant issues
have been covered. It demonstrated (once again) that a benchmark is useful, but not always for the purpose it is designed for.