By Henk Vandenbergh-Oracle on Aug 07, 2015
Any questions, or requests, please use
Any questions, or requests, please use
A few weeks ago I was reminded of an incompatibility between Vdbench503and Swat302 that I introduced quite a while back. The file format when using Swat302 'File' 'Import Vdbench data' for Vdbench503 data has changed. Since at this time no new version of Swat is available outside of Oracle that of course is a problem.
To help you convert the new 503 'swat_mon.txt' file contents so that it can be used by Swat302, run the AWK program below.
# Conversion of Vdbench503 swat_mon.txt file to a format that can be read
# by Swat302 using 'Import Vdbench data'.
# Note that this AWK program reads file swat_mon.txt (or a copy of it) and
# then replaces swat_mon.txt again.
# I suggest therefore that you first make a copy of swat_mon.txt and use that
# as input, because if you would accidentally run TWICE using swat_mon.txt as
# both input AND output you will have destroyed the original content of the file.
# To run:
# - cd /vdbench503
# - awk -f convert.awk output/swat_mon.txt.copy > output/swat_mon.txt
if ($1 == ":vdbench503_vdbench_data_for_swat303")
else if (NF != 14)
printf("%d %d %d %d %d %d %d %d %d %d %d %d %d %d\n",
$1, $2, $3, $4, $5/1000, $6, $7, $8, $9/1000, 0, 0, 0, 0, 0);
When running Vdbench in multi-host mode make sure that you specify at least one thread for each host. If you don't, all the remote hosts will start, but some of them will not have any work to do. 16 hosts with (default) 8 threads for an SD will only have 8 hosts active. Use either the sd=xxx,threads= or the rd=xxx,threads= parameter. (I have not figured out how to start half threads :-)
After elapsed=nn seconds, Vdbench tells its slaves to terminate the current run, and waits for them to do so. If that takes more than 30 seconds Vdbench displays this message: "SlaveList.waitForSlaveWorkCompletion()".
Why could it take more than 30 seconds? At the end of a run no new i/o is generated by Vdbench, but it still has to wait for i/o that is already outstanding to complete. But why can that take more than 30 seconds? There can be multiple reasons for that.
As an FYI: I just remembered that Vdbench503 journal recovery still has some outstanding problems for which I have not had the time to look at. Journaling is an infrequent used option so if you need it, fall back to Vdbench 5.02
It was just brought to my attention that there are some problems with the way that I implemented the O_SYNC, O_DSYNC, and O_RSYNC flags for Linux.
First of all, I misinterpreted what I found in /usr/include/bits/fcntl.h The flags are octal, not hex as I mistakenly read, meaning that what I coded as 0x010000 should have been 0x1000.
Second, I learned that the flags themselves have changed since I last looked at it, with the three flags in some versions of Linux no longer having the same value (octal 010000), but instead now have different values.
Since I can't begin to identify and check all the different flavors and versions of Linux and their flag settings I highly suggest before using these flags to check the contents of above header file and code openflags=0x…… with the proper HEX value as needed.
The next 503rcx version will have the 'proper' flags set to 0x1000, (whatever 'proper' means today).
As of February 15 the link to MOS in this blog entry has changed!
Swat 3.02 has been moved to My Oracle Support (MOS) and is available for download for properly licensed Oracle customers from here. Swat is now only distributed as a zip file but contains everything needed for both Unix or Windows systems.
You will need to have a valid MOS logon ID. You can also just go to MOS and request patch 10350687.
November 2013: An update: when I made Swat 302 available I put a five year expiration date on, fully expecting a new version to be available by then. And then Sun became Oracle, and a decision was made to no longer offer external support for Swat or make new versions available.
This now will cause Swat302 to expire on 'Thu Feb 13 14:45:12 MST 2014', warning messages will show up three months before that.
To work around this, download https://blogs.oracle.com/henk/resource/fixes/dont_expire_swat302.zip, place it in the swat302 directory, and unzip. You should now have a new /swat302/classes/Swt/ directory. This will eliminate the expiration check.
Though my discussions with Oracle legal have not completed yet it looks as if the limitation that only customers that have 'some' Oracle contract can download Swat will stay. I understand that the contract itself will be some minimal contract (you don't have to spend $100 million to get it), so loads of customers therefore should be able to get access to Swat. There is a Swat 3.03 coming; the legal status is pending.
For the "avg2-xxxx" that vdbench puts out at the end of the test run, I was wondering if there was anyway to tune vdbench to use a different starting interval for the average, something other than 2? I've been running tests and we have some cases where it actually takes a while for the IO to reach a stable state. "
There is an elapsed= and an interval= parameter, and Vdbench502 also
has a warmup= parameter.
Normally only the first interval is ignored, but with warmup= the first 'warmup= / interval=' intervals are ignored.
Do realize though that the total elapsed time is increased by the warmup time.
will run for 70 seconds, with only the last 60 seconds included in the avg_11-70 totals.
The followings message shows up after a format has completed successfully: The FWD parameters defined for 'fwd=xxxxx' do not match the parameters used in the previous run.
This message is there to tell you that a newly defined file structure does not match the existing structure and therefore can not be reused without the old structure first being deleted using the 'format=yes' parameter.
However, in this case a size=6.6m was used, which translates to 1024\*1024\*6.6=6920601.6 bytes. In the code where I compare the sizes I compare the old integer value of 6920601.0 with 6920601.6 and therefore report a mismatch. In this example changing size=6.6m to 6600k works around this problem. I will fix this in the next release.
Vdbench aborts after displaying this message on localhost-0.stdout.htm:
Vdbench JNI abort: generate lfsr_data(): String passed must be 8 bytes long: sd3456789
It's clear that I never test with long SD names, it's usually sd1,sd2, etc.
503 introduced a dependency to an SD name not being longer than 8 characters. The SD name is used as input to the Logical Feedback Shift Register (LFSR) logic used to create the default data pattern. Until I fix this, just keep the SD name no longer than 8 characters (it may be shorter than 8).
Blog for Henk Vandenbergh, author of Vdbench, and Sun StorageTek Workload Analysis Tool (Swat). This blog is used to keep you up to date about anything revolving around Swat and Vdbench.