The Mozilla Firefox Browser

Activity log for bug #215728

Date Who What changed Old value New value Message
2008-04-11 14:49:31 Parag Warudkar bug added bug
2008-04-11 14:49:31 Parag Warudkar bug added attachment 'opreport.out' (Oprofile report)
2008-04-21 13:05:23 unggnu bug assigned to firefox (Ubuntu)
2008-04-22 17:14:14 Alexander Sack firefox: status New Incomplete
2008-04-23 09:30:10 Bryce Harrington xorg: status New Invalid
2008-04-23 17:29:55 Chris Coulson firefox: status Incomplete Confirmed
2008-04-24 08:30:36 Alexander Sack bug assigned to firefox
2008-04-24 08:31:15 Alexander Sack firefox-3.0: status Confirmed Incomplete
2008-04-24 09:17:30 Bug Watch Updater firefox: status Unknown Confirmed
2008-04-24 21:28:04 Parag Warudkar firefox-3.0: status Incomplete Confirmed
2008-04-25 10:17:07 unggnu bug added attachment 'urlclassifier.7z' (both urclassifier files)
2008-04-25 14:35:22 John Vivirito firefox: status New Invalid
2008-04-25 14:37:29 John Vivirito title High CPU Consumption [MASTER] High CPU Consumption
2008-04-29 13:22:11 Daniel T Chen title [MASTER] High CPU Consumption [MASTER] Committing to urlclassifier3.sqlite causes excessive CPU usage and disk I/O
2008-05-02 05:33:34 Bug Watch Updater firefox: status Confirmed In Progress
2008-05-02 22:34:22 Alexander Sack bug assigned to xulrunner-1.9 (Ubuntu)
2008-05-02 22:35:04 Alexander Sack firefox: status New Invalid
2008-05-02 22:36:00 Alexander Sack xorg: status New Invalid
2008-05-02 22:36:14 Alexander Sack xulrunner-1.9: status New In Progress
2008-05-02 22:36:38 Alexander Sack xulrunner-1.9: importance Undecided High
2008-05-02 22:36:38 Alexander Sack xulrunner-1.9: status New In Progress
2008-05-02 22:36:48 Alexander Sack xulrunner-1.9: importance Undecided High
2008-05-02 22:37:05 Alexander Sack firefox-3.0: importance Undecided High
2008-05-02 22:37:05 Alexander Sack firefox-3.0: status New In Progress
2008-05-02 22:37:18 Alexander Sack firefox-3.0: status Confirmed In Progress
2008-05-02 22:37:30 Alexander Sack firefox-3.0: importance Undecided High
2008-05-02 23:15:06 Launchpad Janitor xulrunner-1.9: status In Progress Fix Released
2008-05-03 04:42:58 Bug Watch Updater firefox: status In Progress Fix Released
2008-05-03 10:48:49 Alexander Sack xulrunner-1.9: status In Progress Fix Committed
2008-05-05 08:32:46 Alexander Sack description Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. === From https://bugzilla.mozilla.org/show_bug.cgi?id=430530#c4: After some testing, it looks like this gets pretty bad on linux. Once we hit sqlite's cache size, sqlite starts hitting the disk pretty hard. While the database is small this isn't a big deal (we don't hit the cache limit), and once we're up-to-date it isn't as bad (we aren't adding as much data). But during the middle/end of the push to get the complete database, things take way too long, and we're thrashing the disk the whole time. We can reduce the amount of IO by increasing the cache size, and that'll help some (it'll help a whole lot if we increase the cache size by enough to hold the db). We might also need to look at throttling the update process a bit, so that we don't slam the system all at once...
2008-05-05 08:33:10 Alexander Sack bug added subscriber Ubuntu Stable Release Updates Team
2008-05-05 08:35:58 Alexander Sack bug added attachment 'bz430530_attachment_318939.patch' (backport upstream patch for ffox 3 beta 5)
2008-05-05 08:37:36 Alexander Sack bug added attachment '215728.hardy-proposed.diff' (diff of hardy-proposed upload)
2008-05-05 08:46:26 Alexander Sack description Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. === From https://bugzilla.mozilla.org/show_bug.cgi?id=430530#c4: After some testing, it looks like this gets pretty bad on linux. Once we hit sqlite's cache size, sqlite starts hitting the disk pretty hard. While the database is small this isn't a big deal (we don't hit the cache limit), and once we're up-to-date it isn't as bad (we aren't adding as much data). But during the middle/end of the push to get the complete database, things take way too long, and we're thrashing the disk the whole time. We can reduce the amount of IO by increasing the cache size, and that'll help some (it'll help a whole lot if we increase the cache size by enough to hold the db). We might also need to look at throttling the update process a bit, so that we don't slam the system all at once... Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. === From https://bugzilla.mozilla.org/show_bug.cgi?id=430530#c4: After some testing, it looks like this gets pretty bad on linux. Once we hit sqlite's cache size, sqlite starts hitting the disk pretty hard. While the database is small this isn't a big deal (we don't hit the cache limit), and once we're up-to-date it isn't as bad (we aren't adding as much data). But during the middle/end of the push to get the complete database, things take way too long, and we're thrashing the disk the whole time. We can reduce the amount of IO by increasing the cache size, and that'll help some (it'll help a whole lot if we increase the cache size by enough to hold the db). We might also need to look at throttling the update process a bit, so that we don't slam the system all at once... === To reproduce: 1. enable browser.safebrowsing.malware.enabled + browser.safebrowsing.enabled 2. observe IO on urlclassifier3.sqlite while browsing the web
2008-05-05 08:49:30 Alexander Sack firefox-3.0: status In Progress Invalid
2008-05-05 08:54:38 Alexander Sack firefox-3.0: status In Progress Invalid
2008-05-05 09:49:02 Martin Pitt bug added subscriber SRU Verification
2008-05-07 07:05:26 Martin Pitt xulrunner-1.9: status Fix Committed Fix Released
2008-05-11 18:14:17 f3a97 bug added attachment 'disktop.stp' (disktop.stp)
2008-05-12 21:51:20 Alexander Sack description Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. === From https://bugzilla.mozilla.org/show_bug.cgi?id=430530#c4: After some testing, it looks like this gets pretty bad on linux. Once we hit sqlite's cache size, sqlite starts hitting the disk pretty hard. While the database is small this isn't a big deal (we don't hit the cache limit), and once we're up-to-date it isn't as bad (we aren't adding as much data). But during the middle/end of the push to get the complete database, things take way too long, and we're thrashing the disk the whole time. We can reduce the amount of IO by increasing the cache size, and that'll help some (it'll help a whole lot if we increase the cache size by enough to hold the db). We might also need to look at throttling the update process a bit, so that we don't slam the system all at once... === To reproduce: 1. enable browser.safebrowsing.malware.enabled + browser.safebrowsing.enabled 2. observe IO on urlclassifier3.sqlite while browsing the web Note: the follow up bug for this is https://bugs.edge.launchpad.net/ubuntu/+source/firefox/+bug/229745: #229745 - after fix for #215728 - Committing to urlclassifier3.sqlite still causes excessive CPU usage and disk I/O (the 2nd) === Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. === From https://bugzilla.mozilla.org/show_bug.cgi?id=430530#c4: After some testing, it looks like this gets pretty bad on linux. Once we hit sqlite's cache size, sqlite starts hitting the disk pretty hard. While the database is small this isn't a big deal (we don't hit the cache limit), and once we're up-to-date it isn't as bad (we aren't adding as much data). But during the middle/end of the push to get the complete database, things take way too long, and we're thrashing the disk the whole time. We can reduce the amount of IO by increasing the cache size, and that'll help some (it'll help a whole lot if we increase the cache size by enough to hold the db). We might also need to look at throttling the update process a bit, so that we don't slam the system all at once... === To reproduce: 1. enable browser.safebrowsing.malware.enabled + browser.safebrowsing.enabled 2. observe IO on urlclassifier3.sqlite while browsing the web
2008-05-12 23:10:57 Tormod Volden description Note: the follow up bug for this is https://bugs.edge.launchpad.net/ubuntu/+source/firefox/+bug/229745: #229745 - after fix for #215728 - Committing to urlclassifier3.sqlite still causes excessive CPU usage and disk I/O (the 2nd) === Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. === From https://bugzilla.mozilla.org/show_bug.cgi?id=430530#c4: After some testing, it looks like this gets pretty bad on linux. Once we hit sqlite's cache size, sqlite starts hitting the disk pretty hard. While the database is small this isn't a big deal (we don't hit the cache limit), and once we're up-to-date it isn't as bad (we aren't adding as much data). But during the middle/end of the push to get the complete database, things take way too long, and we're thrashing the disk the whole time. We can reduce the amount of IO by increasing the cache size, and that'll help some (it'll help a whole lot if we increase the cache size by enough to hold the db). We might also need to look at throttling the update process a bit, so that we don't slam the system all at once... === To reproduce: 1. enable browser.safebrowsing.malware.enabled + browser.safebrowsing.enabled 2. observe IO on urlclassifier3.sqlite while browsing the web Note: the follow up bug for this is bug #229745: #229745 - after fix for #215728 - Committing to urlclassifier3.sqlite still causes excessive CPU usage and disk I/O (the 2nd) === Browsing with Firefox 3.0b5 on Hardy (All updates applied) causes Xorg to use 50-60% CPU all the time. This is not limited to a particular site or page - it happens any time when Firefox is rendering pages. The high CPU usage makes browsing very jerky - switching tabs takes more time than it should, pages appear frozen for a brief moment. === From https://bugzilla.mozilla.org/show_bug.cgi?id=430530#c4: After some testing, it looks like this gets pretty bad on linux. Once we hit sqlite's cache size, sqlite starts hitting the disk pretty hard. While the database is small this isn't a big deal (we don't hit the cache limit), and once we're up-to-date it isn't as bad (we aren't adding as much data). But during the middle/end of the push to get the complete database, things take way too long, and we're thrashing the disk the whole time. We can reduce the amount of IO by increasing the cache size, and that'll help some (it'll help a whole lot if we increase the cache size by enough to hold the db). We might also need to look at throttling the update process a bit, so that we don't slam the system all at once... === To reproduce: 1. enable browser.safebrowsing.malware.enabled + browser.safebrowsing.enabled 2. observe IO on urlclassifier3.sqlite while browsing the web
2009-04-10 10:37:26 agnul removed subscriber agnul
2009-06-27 07:44:08 Launchpad Janitor branch linked lp:ubuntu/karmic/xulrunner-1.9
2010-09-18 07:58:21 Bug Watch Updater firefox: importance Unknown Medium