V
Venger
In every way possible.
I would like to skin alive the H1B mouthbreather who wrote this retarded
code.
Scenario:
Moving large files (6GB-7GB) from internal drive to external drive,
source and destination both compressed (NTFS compression).
System bogs down, showing hours to move files and moving at sub 3MB/sec
speeds.
Solution:
Clearly something is humping the I/O bus into submission. Track it down
using Task Manager and Resource Manager to one of the ubiquitous
catchcall svchost processes (thanks Microsoft for just shoving tasks
into the same process parent). Notice that while my copy process (both
robocopy and explorer equally slow) is moving data very slowly, the damn
svchost (LocalServiceNetworkRestricted) is reading the same file I am
writing *from the destination drive* at 250MB/min rate. Turns out it is
this shitheaded SuperFetch process.
So, for some reason, as the copy process writes the file to the
destination drive, SuperFetch is reading this same file from the
destination drive, absolutely saturating the I/O process. Thanks,
retarded service.
I'd also like to thank the asshats at Microsoft for naming the
SuperFetch service SysMain. That's right - SysMain. What in the ^%$&?
Not Fetch, SuperF, SFetch, or any other logical iteration, no, we need
my task/service enumeration as CRYPTIC as effing possible, to waste
minutes of my life (that I am trying to get back by killing this
service) by making it obtusely named.
As SOON as I stopped this service, my robocopy stopped acting like a
stillborn earthworm and actually starting cranking at 10 times the
former speed.
Hopefully, someone else wondering WHAT IN THE NAME OF SWEET BABY JESUS
IS GOING ON trying to simply copy files and wondering why it would be
faster to use a floppy intermediary drive may stumble upon this post and
rejoice.
Venger
I would like to skin alive the H1B mouthbreather who wrote this retarded
code.
Scenario:
Moving large files (6GB-7GB) from internal drive to external drive,
source and destination both compressed (NTFS compression).
System bogs down, showing hours to move files and moving at sub 3MB/sec
speeds.
Solution:
Clearly something is humping the I/O bus into submission. Track it down
using Task Manager and Resource Manager to one of the ubiquitous
catchcall svchost processes (thanks Microsoft for just shoving tasks
into the same process parent). Notice that while my copy process (both
robocopy and explorer equally slow) is moving data very slowly, the damn
svchost (LocalServiceNetworkRestricted) is reading the same file I am
writing *from the destination drive* at 250MB/min rate. Turns out it is
this shitheaded SuperFetch process.
So, for some reason, as the copy process writes the file to the
destination drive, SuperFetch is reading this same file from the
destination drive, absolutely saturating the I/O process. Thanks,
retarded service.
I'd also like to thank the asshats at Microsoft for naming the
SuperFetch service SysMain. That's right - SysMain. What in the ^%$&?
Not Fetch, SuperF, SFetch, or any other logical iteration, no, we need
my task/service enumeration as CRYPTIC as effing possible, to waste
minutes of my life (that I am trying to get back by killing this
service) by making it obtusely named.
As SOON as I stopped this service, my robocopy stopped acting like a
stillborn earthworm and actually starting cranking at 10 times the
former speed.
Hopefully, someone else wondering WHAT IN THE NAME OF SWEET BABY JESUS
IS GOING ON trying to simply copy files and wondering why it would be
faster to use a floppy intermediary drive may stumble upon this post and
rejoice.
Venger