Hi Openedge world.
A little help please.
OE 11.7 DB on Windows 2019 server with a DB Blocksize of 4k.
Virtual disk is on a SAN which is set to 512 Bytes per Sector/Physical sector
Openedge DB actions such as DB restore or prostrct create give me roughly 40MB/sec thoughput on the disk (I cannot live with this).
Copy a big file around like a Openedge BCK file, and I get 200 MB/sec throughput on the disk (I can live with this).
I am the only user of the disk so I am ruling out "other stuff" as the issue.
Any bright ideas? Should that SAN be formatted to 4096 Bytes? Should I be using 8K DB blocksize? Should I give up and go back to the carpentry?
Many thanks in advance
Stu
Mr Gore, it's been a while.
What does the so called Furgal Test yield in terms of timings?
Create a sports2000 DB.
proutil sports2000 -C truncate bi -bi 16384
proutil sports2000 -C bigrow 2 -zextendSyncIO
What RAID structure does the SAN have? Is it SSD/HDD? How much cable is between the SAN and the virtual host? What drivers are on the virtual network adapter? Assuming this is VMWare, should be VMXNET 3 instead of the default E1000.
Other considerations here should be looked at too: knowledgebase.progress.com/.../P153991
Hi JP!
I had found that KBase thanks.
Not familiar with the Furgal Test? Those DB commands completed pretty quick.
The network driver is the VMXNET3.
Believe we have SSD, Not sure about the other questions as I haven't seen the hardware.
I have been shown the following:
Seems to suggest a speed limit.
You should be able to get the exact timings of the Furgal Test from the log file of the db. It's essentially timing how long it takes to grow a file of a certain size on disk. It should be quick, but would be interesting to know how quick.
By the way, this article gives a decent insight into some of the why's of bad virtual storage performance. wss.com/.../
Mon Oct 21 16:04:46 2019
[2019/10/21@16:04:46.103+0100] P-9396 T-10008 I DBUTIL : (451) Bigrow session begin for XXXXXXXXX on CON:.
[2019/10/21@16:04:46.105+0100] P-9396 T-10008 I DBUTIL : (15321) Before Image Log Initialisation at block 0 offset 235.
[2019/10/21@16:04:46.110+0100] P-9396 T-10008 I DBUTIL : (7129) Usr 0 set name to XXXXXXXXXX
[2019/10/21@16:04:46.110+0100] P-9396 T-10008 I DBUTIL : (6600) Adding 2 clusters to the Before Image file.
[2019/10/21@16:04:50.799+0100] P-9396 T-10008 I DBUTIL : (15109) At Database close the number of live transactions is 0.
[2019/10/21@16:04:50.800+0100] P-9396 T-10008 I DBUTIL : (15743) Before Image Log Completion at Block 0 Offset 235.
[2019/10/21@16:04:50.815+0100] P-9396 T-10008 I DBUTIL : (334) Bigrow session end.
So I am reading that as 4.5 seconds there or thereabouts.
SAN performance is never going to be good. Your experience sounds typical. It could be worse. Much worse.
"The Furgal Test" is quite simple (ProTop provides a script called "syncio" to automate it):
time -p proutil sports -C bigrow 2 -zextendSyncIO
If the "real" time is > 10 then your IO subsystem is pretty bad and you should replace it.
You need -zextentSyncIO to defeat some optimizations that were added to bigrow which ruined the test ;)
Just FYI, the bi cluster performance improvement (for runtime and bigrow) was in 11.3.0 and only applies to UNIX/Linux platforms.
-zextentSyncIO reverts this enhancement for 'Frugal Testing' (anyone care to define this term for the unenlightened)
000073407 - Performance improvement on new biclusters added to the bi chain.
knowledgebase.progress.com/.../Performance-improvement-BIGROW-000073407
The test is named after your colleague Mike Furgal who has popularized it in many PUG talks.
It is a quick and easy way to uniformly gather information about synchronous IO performance. The result enables you to a) compare your performance to other people and b) keep an eye on trends in your own infrastructure so that when the storage guys deny changing anything you can confidently rebut that claim.
Let me add that in the OE 12.1 release and in the OE 11.7.6 release (when it is released) the performance optimization affecting the extending of the bi file was made available on all platforms so the defeating switch used to execute this unbuffered I/O test will also be required on windows and Linux.