| 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 |
|
