- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Postmark benchmark on OpenVMS
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-25-2007 11:55 PM
тАО04-25-2007 11:55 PM
Re: Postmark benchmark on OpenVMS
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2007 12:03 AM
тАО04-26-2007 12:03 AM
Re: Postmark benchmark on OpenVMS
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2007 12:29 AM
тАО04-26-2007 12:29 AM
Re: Postmark benchmark on OpenVMS
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2007 05:17 AM
тАО06-11-2007 05:17 AM
Re: Postmark benchmark on OpenVMS
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2007 06:04 AM
тАО06-11-2007 06:04 AM
Re: Postmark benchmark on OpenVMS
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 :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2007 06:27 AM
тАО06-11-2007 06:27 AM
Re: Postmark benchmark on OpenVMS
have been covered. It demonstrated (once again) that a benchmark is useful, but not always for the purpose it is designed for.
- « Previous
-
- 1
- 2
- Next »