In <bitnet.adsm-l%ADSM-L%95062115472463 AT VM.MARIST DOT EDU>,
MAINT%PUCC.BITNET AT vm.marist DOT edu (Melinda Varian) writes:
>On Wed, 21 Jun 1995 at 17:05:05 GMT, Bill Colwell said:
>
>> Caution - this ran pretty quickly at level 11 of the mvs server, but
>> export was radically changed at level 12 and the performance of an
>> export of a single node or filespace got much worse when actually
>> moving the data.
>
>I had thought that the rationale for the change to EXPORT in Level 12
>was to improve performance. (I can't tell, because every level higher
>than 11 goes into a loop as soon as I try doing an EXPORT.) Given that
>my last EXPORT ran for 6.5 days under Level 11 (on a 3090E), I find your
>statement disheartening to say the least. Do you have any comparison
>numbers?
>
>Melinda Varian,
>Princeton University
Export has two components - selection and data movement. The problem in
level 11 and before was in selection. It used a very bad sort to put the
files in order by media. The sort cpu time increased exponentially - double
the files and quadruple the cpu time. This wasn't too bad for a small fraction
of the server - i.e. one node out of 700, which is how I use export. But it
was terrible for sites that exported a large fraction of the server, i.e. all
of it for disaster recovery.
To satisfy the disaster recovery needs, the export selection algorithm was
changed to not do a sort but instead to do some kind of scan of all the
media constructs in the database. This is a good change for sites exporting
a large fraction of the database but terrible for those doing a small fraction.
If the selection cpu component could be separated out and plotted against
'fraction of server exported' the new algorithm would be a fairly straight
line (y=100) while the old algorithm would look like y=x**2. The lines
cross somewhere - my guess is at around a 10% fraction.
The tests I did involved a test server with 67k db pages in use. Exporting one
filespace was about 50 times worse. Exporting the whole node, about 5% of
the server, was 5 times worse, and multiple nodes (unknown %) was just 25%
worse. I never did the whole server since I am not interested in export
for disaster recovery. Based on my tests, I haven't and may never do an export
on my production server which has 1.14M pages in use.
I intend to submit SHARE and GUIDE requirements to restore the old export in
Version 2, since disaster recovery functions are a big part of the new functions
and anyone who moves up to version 2 (when available ;-) ) will not use export
for disaster recovery.
The above are my observations and surmises. I have no factual knowledge
of the database or server code. IBM is invited to confirm or deny this
with the 'facts' at their disposal.
Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550
|
