cpu % on zip... SLOWWW

[Nate]

This seems so odd to me. I downloaded a zip file (of Java jdk docs) of
around 40 MBs. It is taking many, many minutes to unzip this thing.
CPU usage, as seen on the performance tab of task manager, is
generally only in the teens. When I close Task Manager, it is
similarly just crawling along.

The limiting factor maybe is the writing to the drive. The HD light is
dimly flickering the whole time, with a bright flash once every few
seconds. But this is insane. It must be 10-15 minutes elapsed so far,
and only 75% complete. The machine is 2.8GHz P4 and a 7200rpm drive.
The ram is 512MB, and the page file is not increasing. I'm using the
XP unzip program. McAfee AV is running.

Disk write bytes/sec is averaging 140K, according to perfmon. Even if
I assume only 10 minutes, that's 10 x 60 x 140K = 84 MB, not 40. What
gives?

Why so slow? I bet my old 500Mhz computer with '98 and winzip would
have been long done by now.

 

[Galen]

In

This seems so odd to me. I downloaded a zip file (of Java jdk docs) of
around 40 MBs. It is taking many, many minutes to unzip this thing.
CPU usage, as seen on the performance tab of task manager, is
generally only in the teens. When I close Task Manager, it is
similarly just crawling along.

The limiting factor maybe is the writing to the drive. The HD light is
dimly flickering the whole time, with a bright flash once every few
seconds. But this is insane. It must be 10-15 minutes elapsed so far,
and only 75% complete. The machine is 2.8GHz P4 and a 7200rpm drive.
The ram is 512MB, and the page file is not increasing. I'm using the
XP unzip program. McAfee AV is running.

Disk write bytes/sec is averaging 140K, according to perfmon. Even if
I assume only 10 minutes, that's 10 x 60 x 140K = 84 MB, not 40. What
gives?

Why so slow? I bet my old 500Mhz computer with '98 and winzip would
have been long done by now.

McAfee is probably scanning all the files as you're opening it. That'd be my
first guess at any rate.

Galen

 

[Nate]

McAfee is probably scanning all the files as you're opening it. That'd be my
first guess at any rate.

thanks. Yes, that seemed a possibility. But wouldn't cpu usage have
climbed way up in that case?

 

[Gerry Cornell]

Try Ctrl+Alt+Delete to bring Task Manager and select the Process Tab.
What is the Commit Charge?

--


Hope this helps.

Gerry
~~~~~~~~~~~~~~~~~~~~~~~~
FCA

Using invalid email address

Stourport, Worcs, England
Enquire, plan and execute.
~~~~~~~~~~~~~~~~~~~~~~~~
Please tell the newsgroup how any
suggested solution worked for you.



~~~~~~~~~~~~~~~~~~~~~~~~

 

[Galen]

In

thanks. Yes, that seemed a possibility. But wouldn't cpu usage have
climbed way up in that case?

I use KAV (technically AVP) here and when a large compressed file that
contains a number of other files is opened it takes a while (not that long
but a while regardless) and the CPU usage doesn't increase a great deal. It
tends to get a bit more bogged down when opening a compressed file with many
other compressed files inside it. If you know that the file is safe you
could try opening it, after it's been opened once already and scanned,
without your McAfee running and see if there's a difference.

Galen

 

[Nate]

Try Ctrl+Alt+Delete to bring Task Manager and select the Process Tab.
What is the Commit Charge?

total 241M
limit 1278M
peak 287M

209M available RAM

so, that seems acceptable to me, though I'm new to XP by about a week
or so. Next, by closing out all other programs, the total commit
reduces to about 180M, but no real change in the unzipping speed.
Gerry, were you expecting it might be thrashing, or something else?

 

[Nate]

I use KAV (technically AVP) here and when a large compressed file that
contains a number of other files is opened it takes a while (not that long
but a while regardless) and the CPU usage doesn't increase a great deal. It
tends to get a bit more bogged down when opening a compressed file with many
other compressed files inside it.

this file I am expanding does expand to a large doc tree

If you know that the file is safe you
could try opening it, after it's been opened once already and scanned,
without your McAfee running and see if there's a difference.

Well, I'm using McAfee until the free trial runs out, then back to AVG
for me

meanwhile, I did stop the AV and though cpu usage went down to about
7% (from ~15%), there is no perceivable change in the unzipping speed.
So I manually had the AV scan a large, 'regular' zip, and cpu goes
at/near 100%. I next tell McAfee to manually scan this particular zip
of many-foldered java docs, and it also goes at/near 100% cpu.

Galen, I'm wondering if XP's builtin unzipper has problems handling a
large zip that contains many subfolders? I didn't notice any
particular slowness, e.g., when unzipping the Java SDK itself - though
that file was about the same overall size.

Ohhhhhh, wait a minute... the SDK download was a self-extracting zip.
The only other fairly large download I did was the one for MySQL, but
that was an *.msi. I don't recall that being slow.

 

[Gerry Cornell]

Nate

I was interested in the relationship between RAM and virtual memory. It
looks OK to me.


--


Regards.

Gerry

~~~~~~~~~~~~~~~~~~~~~~~~
FCA

Stourport, Worcs, England
Enquire, plan and execute.
~~~~~~~~~~~~~~~~~~~~~~~~

 

[Galen]

In

Ohhhhhh, wait a minute... the SDK download was a self-extracting zip.
The only other fairly large download I did was the one for MySQL, but
that was an *.msi. I don't recall that being slow.

You mentioned WinZip earlier. Have you tried to open/extract with that as
opposed to the self extraction methods? Now I'm a bit curious as to the
results.

McAfee products aren't in my list of recommendations to be honest though I
hear that they're getting better. I'd also wonder what the application was
that was used to compress the file. That too could be one of the issues if
it's nothing that's reputable or capable perhaps.

Galen