Closed Bug 676284 Opened 13 years ago Closed 10 years ago

slow downloads; more bytes transferred results in lower data rate

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
5 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: herber, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

http://linux1.fnal.gov/linux/fermi/slf6rolling/i386/iso/SLF-6-i386-2011-07-01-Install-DVD.iso

I attempted to down the ISO from the link above on this web page:

http://linux1.fnal.gov/linux/fermi/slf6rolling/i386/iso/

Using Firefox 5.0


Actual results:

Very slow download.  Perhaps, zero bytes per second.


Expected results:

The ISO should have downloaded.

When I use the exact same link with wget the file downloads in about 6 minutes
(I have a 100MbHz kink to the server from my workstation.  Average wget download
speed was 11.2 MbHz.

I have seen this problem in every 3, 4 and 5 version of Firefox I have used.
(At least the following: 3.0, 3.5, 3.6.4, 4.0, 4.0.1 and 5.0).  This problem only
seems to occur on large downlaods (10s of MB or larger)..
herber@xyzzy iso$ uname -a
Linux xyzzy.fnal.gov 2.6.32-131.6.1.el6.i686 #1 SMP Tue Jul 12 17:12:20 CDT 2011 i686 i686 i386 GNU/Linux
herber@xyzzy iso$ cat /etc/redhat\-release 
Scientific Linux Fermi release 6.1 (Ramsey)

herber@xyzzy iso$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 6
model name	: Intel(R) Pentium(R) D CPU 3.60GHz
stepping	: 4
cpu MHz		: 2400.000
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 6
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est cid cx16 xtpr pdcm lahf_lm tpr_shadow
bogomips	: 7182.62
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 15
model		: 6
model name	: Intel(R) Pentium(R) D CPU 3.60GHz
stepping	: 4
cpu MHz		: 2400.000
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 6
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts pni dtes64 monitor ds_cpl vmx est cid cx16 xtpr pdcm lahf_lm tpr_shadow
bogomips	: 7180.62
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 48 bits virtual
power management:
herber@xyzzy iso$ cat /proc/meminfo
MemTotal:        3368752 kB
MemFree:         1360684 kB
Buffers:          217856 kB
Cached:           382944 kB
SwapCached:            8 kB
Active:          1561484 kB
Inactive:         266260 kB
Active(anon):     981504 kB
Inactive(anon):   251772 kB
Active(file):     579980 kB
Inactive(file):    14488 kB
Unevictable:          16 kB
Mlocked:              16 kB
HighTotal:       2499460 kB
HighFree:         918344 kB
LowTotal:         869292 kB
LowFree:          442340 kB
SwapTotal:       4192956 kB
SwapFree:        4192948 kB
Dirty:                92 kB
Writeback:             0 kB
AnonPages:       1226952 kB
Mapped:            70160 kB
Shmem:              6332 kB
Slab:             127192 kB
SReclaimable:      47104 kB
SUnreclaim:        80088 kB
KernelStack:        2976 kB
PageTables:        11164 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     5877332 kB
Committed_AS:    3172816 kB
VmallocTotal:     122880 kB
VmallocUsed:       43896 kB
VmallocChunk:      43044 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        6136 kB
DirectMap2M:      901120 kB

Comment from another user:

As a test, I just downloaded a 3.5 GB ISO image from linux1, using Firefox 5.0.1 
for Mac. It transferred at 11.2 MB/sec, which is all my 100BASE-TX connection 
can do. I do confirm a small memory leak, as the RSIZE of Firefox increased 
slowly but monotonically during the transfer, by about 100 MB, which is ~3% of 
the amount of data transferred.


Tom Roberts


On 8/3/11 8/3/11 - 9:57 AM, David Eads wrote:
> I've noticed this behavior on occasion as well, though I didn't realize it was
> an FF bug. Can you send a link to the bug report?
>
> On 08/02/2011 05:12 PM, Randolph J. Herber wrote:
>> There is a bug in firefox such that the download has a memory leak and
>> ever slower, I reported the bug. The firefox people seem not to understand
>> that it requires large files to make the problem easily visible. The bug
>> has not been fixed in several firefox releases.
>>
>> I have gone to using curl, wget or other browsers when I need to download
>> large files.
I confirm a memory leak in Firefox 5.0.1 while downloading a 3.6 GB file. The RSIZE of Firefox increased monotonically during the download, adding about 100 MB, or about 3% of the file size. So it's clear that a large file is needed to observe this problem.

This is Mac OS X 10.5.8 (Leopard), on a Mac Pro with 4 cores, 6 GB RAM, and 3 TB disk.

The transfer rate remained 11.2 MB/s throughout, the capacity of my 100BaseTX link. That server is a half mile away on the same campus as my office, with networking via 100BaseTX in my office, fiber optics thereafter, >>100 Mb/sec in the server room.

However, a second test did not show this problem to the same degree. The above test had RSIZE increase from about 300 MB to about 400MB during the download.

My second test was of a 4.1 GB file, and Firefox's RSIZE increased from 147.21 to 153.20 MB during the download. The 4.1 GB download stayed at 11.2 MB/sec and took just over 5 minutes.

I do not know what might affect this memory leak so dramatically. The two tests were within an hour of each other, on the same machine, without reboot. Firefox was restarted between them (due to a Microsoft Office 2011 Update). The first test used a Firefox instance that was at least several days old, and the download was in the only open window and tab. The second download was in the third open tab of the only Firefox window. The difference in RSIZE between the two tests suggests that this is a memory leak that builds up and gets worse over time.
No significant difference in download speed for me (all about 1.6MB/s) downloading the iso in comment 0:
Mozilla/5.0 (X11; Linux x86_64; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Wget/1.12 (linux-gnu)


Does the issue still occur if you start Firefox in Safe Mode?
https://support.mozilla.com/en-US/kb/Safe+Mode

How about with a new, empty profile?
https://support.mozilla.com/en-US/kb/Basic+Troubleshooting#w_8-make-a-new-profile

Does the slowness occur from the very beginning of the huge download, or does it happen after a while?
It does not happen in either Safe Mode or new .profile mode.
<<Oh, is new profile mode painful -- with a new profile Firefox
  does many "evil" things like picking places to put files instead
  of asking where I want them. >>

The rate exponentially slows. Initially (normally) full rate.
My test today with normal mode and full profile started at a
very low rate. normally, it starts at full rate and decreases
to 1MBHz by about 1MB.
Here is my extensions list (the Addons Manager should have the capacity
to generate a list to a file or on a page from which the text can be copied).
"1-ClickWeather"
"Add Bookmark Here ??"
"BetterPrivacy"
"CS Lite"
"Cert Viewer Plus"
"ColorfulTabs"     
"CuteButtons - Crystal SVG"
"Default"
"Domain Details"
"Element Hiding Helper for Adblock Plus"
"Firecookie"
"Flagfox"
"Font Size"
"Forecastfox Weather"
"Ghostery"
"Hebrew Calendar"
"International Sideboard"
"MicroFox"
"Plugins Toggler"
"QuickToggles"
"Tabs Menu"
"Toolbar Buttons"
"User Agent Switcher"
"Validator"
"View Cookies"
"View Dependencies"
"View Source Chart"
"Web Developer"
"YSlow"
"i18nsideboard"
Well, if it doesn't happen in Safe Mode then the problem is likely caused by an add-on.

You may try to track down which one is the faulty one:
https://support.mozilla.com/en-US/kb/Troubleshooting+extensions+and+themes#w_test-for-faulty-extensions
YSlow when disabled restored the data rate. I can not tell whether
the memory leak was also repaired.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.