I'm running a mupip extract -format=binary for a very large global.
Monitoring the performance while it's running I don't see any cpu utilisation, no iowait and quite modest disk write rate. There's nothing else running on the system so there's no other competition for resources.
What's the resource bottleneck? I'd expect disk IO to be the limiting factor but it doesn't seem to be. Is there anything that will make mupip extract run faster?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have always found mupip extract to be cpu bound. Be sure to display cpu utilization for all cores when using a tool such as top - mupip only runs on one core, so total cpu usage for a system with dual quad processors and hyperthreading (16 virtual cores) would only show around 5-6% utilization.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I failed to notice the binary format specifier, which as you say, should just be dumping the blocks to the file . Have you tried the default ZWR format to see how it compares? Also, have you tried writing the output file to disk or partition separate from where the GT.M .dat file resides?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm running a mupip extract -format=binary for a very large global.
Monitoring the performance while it's running I don't see any cpu utilisation, no iowait and quite modest disk write rate. There's nothing else running on the system so there's no other competition for resources.
What's the resource bottleneck? I'd expect disk IO to be the limiting factor but it doesn't seem to be. Is there anything that will make mupip extract run faster?
I have always found mupip extract to be cpu bound. Be sure to display cpu utilization for all cores when using a tool such as top - mupip only runs on one core, so total cpu usage for a system with dual quad processors and hyperthreading (16 virtual cores) would only show around 5-6% utilization.
CPU is virtually 0% on all cores.
I don't understand why a binary extract would be CPU bound. It can't be doing much more than reading blocks and writing them to the output file.
I failed to notice the binary format specifier, which as you say, should just be dumping the blocks to the file . Have you tried the default ZWR format to see how it compares? Also, have you tried writing the output file to disk or partition separate from where the GT.M .dat file resides?