Opened 16 years ago

Last modified 14 years ago

#398 closed Bug report

Exporting Large Queue/Closing FZ w/Large Queue = 100% CPU

Reported by: blujay Owned by:
Priority: normal Component: Other
Keywords: Cc: blujay, kaaspertje, Tim Kosse
Component version: Operating system type:
Operating system version:

Description

I help run a large Web site, and have been downloading
the entire site to backup to CD. Right now I'm trying
to download ~900MB from our main server, totaling
several thousand files. Since FZ does not show a queue
count (please add this!), I'm having to guess that the
total is around 2,000-3,000 files.

Naturally, a transfer of this much data may not
complete in one day, and I sure don't want to have to
start over from scratch. Just downloading all of the
directory listings takes about 10-15 minutes. So, I
have been trying to export the queue.

I've tried exporting the entire queue of the ~900MB of
files, and smaller portions of ~150MB, and whenever I
try, FZ remains at 100% CPU usage, with memory usage
continually fluctuating in small amounts. When I tried
to export the 900MB queue, memory usage was around
96MB; when I tried the smaller one, it fluctuated more,
from ~11MB to ~26MB, occasionally jumping to ~66MB.

I have FZ set to use XML, not the registry, and when I
try to close FZ the same thing happens.

At first I had FZ set to use the registry, and when I
tried to close it, the queue was so large, it ran the
registry up to the max registry size, so I switched FZ
to XML.

With the 900MB queue, I let FZ run at 100% CPU for
around 15 minutes, which should certainly be enough on
an Athlon XP 1700+ with 512MB of memory, don't you
think? I mean, come on, what's a list of a few
thousand files for a machine like that? :)

I think this is a fairly serious bug. If there's
anything I can do to help the devs fix it, let me know.

Change History (6)

comment:1 Changed 16 years ago by blujay

Well, it turns out I underestimated the number of files
rather dramatically: the actual total of the 900MB of files
is over 25,000 files. That is a lot, but FZ should still be
able to handle it. And it happened with a smaller queue of
3,000-5,000 files too.

comment:2 Changed 15 years ago by anonymous

Logged In: NO

I have this same problem. I traced it to the export function
being incredibly slow. It exports a little over 100 files per
second. That's terribly slow.

comment:3 Changed 15 years ago by kaaspertje

Hi there,

I'm also trying to download about 10000 files (about 460 MB)
wich does well. but when i want to delete those files my CPU
also goes to 100% and it does not seem to like that file
zilla can handle this.

I hope this bug will be fixed soon.

Cheers, Sander

comment:4 Changed 15 years ago by kaaspertje

Keep up the good work!

comment:5 Changed 15 years ago by blujay

kaaspertje, I have noticed that if you deselect the files in
the remote pane that are being deleted, the deletion speed
will go way up. All you have to do is, after queueing the
deletions, click one of the files in the remote pane, and it
will instantly speed up.

comment:6 Changed 14 years ago by Tim Kosse

This bug report has been closed due to inactivity and has possibly
already been solved.

You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).

Note: See TracTickets for help on using tickets.