Closed
Bug 443632
Opened 17 years ago
Closed 9 years ago
FF dns lookup slow down/stop after prolonged use in Mac OS X.
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: euan.webster, Unassigned)
References
Details
(Keywords: perf)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9) Gecko/2008061004 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9) Gecko/2008061004 Firefox/3.0
FF eventually slows down whilst performing lookups to an unusable state on Mac OS X 10.5. Witnessed on both Macbook and Macbook Pro. I've seen this on Leopard with previous beta versions of Firefox as well.
Turning off IPv6 both within FF and within Mac OS X has no effect. Restart browser helps sometimes. Deleting the Mozilla profile and creating a fresh one appears to fix the problem however.
Performing a 'dscacacheutil -flushcache' at the command line has no effect.
Safari continues to work normally, even when FF has ground to a halt. DNS lookups from command line on the same site works correctly. Pinging the same site works correctly. This is localised to FF.
Happy to zip up my profile and send it through if necessary.
Reproducible: Sometimes
Steps to Reproduce:
1. Use FF3 for extened period (weeks)
2. No idea!
Actual Results:
See details
Expected Results:
Carried on performing lookups in a timely fashion.
No theme installed.
Add-ons are: chatzilla, stumbleupon toolbar and User Agent Switcher.
Apple Macbook Pro 2.2GHz, 4Gb RAM
Also seen by other people: http://aplawrence.com/MacOSX/firefox_google.html, although not restricted to Google. Google is just the most common site used.
| Reporter | ||
Updated•17 years ago
|
Version: unspecified → 3.0 Branch
Comment 1•16 years ago
|
||
This had been fixed and now is back with FireFox-3.5.5 and I notice inputting google.com accesses all sorts of other sites in the status line at bottom of browser.
After minutes FireFox returns then works correctly.
Also if Firefox is killed and restarted it works correctly.
By correctly I mean inputting google.com returns a page in a few seconds, only hitting google.com rather than other random ip addresses.
Best for someone to update this thread with information about how to debug this so those of us experiencing this problem can return debug data.
Updated•14 years ago
|
Whiteboard: [closeme 2011-05-19]
I am experiencing this on firefox 4.0 on OS X snow leopard.
I ran a tcpdump udp port 53 today and noticed that when FF is not working it is not making any DNS requests at all. Other applications continue to function without error.
While I would be happy to dig deeper, could I repeat David Favor's request for someone with appropriate knowledge give us some idea on how to provide useful debugging information.
I kept digging and eventually looked through the system logs. Which I admit I should have reviewed sooner. I spotted log lines that appeared to be relevent:
Applications/Firefox.app/Contents/MacOS/firefox-bin[29162]: dnssd_clientstub ConnectToServer: socket failed 24 Too many open files
This got me searching for solutions in new and fun ways. This lead me to a discussion about the delicious awesome bar integration causing similar problems for some others. I have for the time being disabled the awesome bar integration and if things stay like they are iwll report it to the new delicious team in a couple of weeks.
Hopefully others who experience this problem can confirm similar scenarios.
Cheers,
S.
Updated•14 years ago
|
Whiteboard: [closeme 2011-05-19]
Comment 4•14 years ago
|
||
maybe see also
Component: Shell Integration → Networking
Product: Firefox → Core
QA Contact: shell.integration → networking
Version: 3.0 Branch → 2.0 Branch
Comment 5•14 years ago
|
||
(In reply to Patrick McManus from comment #4)
> maybe see also
http://code.google.com/p/chromium/issues/detail?id=73327
Comment 6•12 years ago
|
||
I'm experiencing a similar issue for about a month on nightly (currently 24) : After a while without restarting FF dns lookups become unable to finish.
A restart (i use the extension restartless restart as workaround), fixes the issue. I probably need to investigate a few more but I guess it appends more often when the connection isn't stable.
I presently use Xubuntu 13.04.
Sadly, or not, telemetry dashboard doesn't reflect my problem : https://metrics.mozilla.com/data/content/pentaho-cdf-dd/Render?solution=metrics2&path=%2Ftelemetry&file=telemetryEvolution.wcdf&bookmarkState={%22impl%22%3A%22client%22%2C%22params%22%3A{%22referenceDate%22%3A%222013-06-18%22%2C%22appNameParameter%22%3A%22[Application].[Firefox]%22%2C%22osParameter%22%3A%22[OS].[Linux]%22%2C%22channelParameter%22%3A%22[Channel].[nightly]%22%2C%22reasonParameter%22%3A%22[Reason].[saved-session]%22%2C%22histogramParameter%22%3A%22[Histogram].[DNS_LOOKUP_TIME]%22%2C%22histogramPopupTools%22%3A%22%22%2C%22duplicateHistogram%22%3A%22%23duplicateHistogram%22%2C%22medianButtonParam%22%3A0%2C%22scatterChart%22%3A%22%22%2C%22intervalParam%22%3A%223000%22}}
I will reinstall the SPS profiler soon to dig a few more.
NB :
+ I don't meet this behaviour with chromium.
+ The same issue appends on a Xubuntu 12.10 desktop.
Comment 7•12 years ago
|
||
Ok, the issue just append on this link http://www.jooks.fr/aaa/penible-cette_soiree-de-ouf_ou-tu-netais-pas/ (abstract: ideas about the way you feel when you've not been to a party because you were just lazy and then all you're friends tell you it was the best of the year...).
Anyway! The new tab opened, the statusbar shown "waiting for www.jooks.fr" and nothing then, the lookup never finished (it looks like at least), the awesomebar is still displaying about:newtab and the fav on the tab is still the loader after at least an hour.
I got 2 profiles then : One analysing since the startup of ff... but it seems too big and returns an error during server-side compression.
And another one http://people.mozilla.com/~bgirard/cleopatra/#report=913cd5f58f1a36323f2131d9b618c1900d1b1fd1 where you can find stuff about dns, dnscache...
Interesting things :
+ the profile was extremely slow and the browser was almost freezed.
+ I launched another profile but from the devtools this time an got a running time of 0 with a value of (empty). The browser lagged a lot two during this one.
PS : Seeing the missing symbols i've just installed a lot of -dbg packages related to libs I saw. If I get another relevant profile, it might be better.
Comment 8•12 years ago
|
||
I've finally got a profile when no more page was able to load : http://people.mozilla.com/~bgirard/cleopatra/#report=4957b0988f7be42af3856b585fe1d86ceac13b71
Comment 9•11 years ago
|
||
I'm experiencing this right now with Firefox 31 on Mac OS X 10.9.4. DNS lookups are taking a very, very long time to complete if they ever do. And even after they resolve network loads are incredibly laggy. At the same time, I can open the exact same links in Safari and Chrome without any apparently delays. I'm filing this report from Chrome as Firefox still hasn't resolved bugzilla.mozilla.org. I looked but didn't see another bug report, although I'm really hoping there is one ;-)
Comment 10•10 years ago
|
||
Euan, are you still seeing this?
Jean (from comment 6) writes "I still see it but less and less in time (probably due to the global perf improvements of FF). It always appends after a very long use without restart so it's quite hard to reproduce. Presently, I don't use nightly anymore (as it corrupted my profile). I can retry if you want."
Thanks for the response. Testing nightly is not so important, as long as you are using a current version of the build
Flags: needinfo?(euan.webster)
See Also: → 417689
Comment 11•9 years ago
|
||
Euan (the reporter) writes, "Haven't noticed this big in a long time though."
So closing WFM
Chris, Does it help to set network.dns.disableIPv6 true?
(some people in bug 417689 successfully used this setting)
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(euan.webster)
Keywords: perf
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•