9:17 p.m.
Every time I start firefox after recent updates, top
shows it periodically taking up to 50% of the CPU
even if I'm just looking at a simple page of plain
html (no scripts, not even any images) on my local
web server.
This is ff 13.0.1 on x86_64 fedora 17.
Any clues? Anyone see anything similar?
10:22 a.m.
On Wed, 2012-07-11 at 12:00 +0200, Roberto Ragusa wrote:
We *do* have a table of rules
I know that, I was wondering about the scope of it.
Those links made for interesting reading.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
5 a.m.
On 07/01/2012 04:20 PM, Tim wrote:
On that note, I've often wondered how systems that look at a
file's GMT
datestamp and tell you that time translated into your local time, cope
with datestamps from a long way away, when timezone rules keep on
changing. We could maintain a table of rules so that the computer can
correctly give you the times during summer of 1976, but how far back is
the table maintained? Sure, you won't have to read back a timestamp
from the year 1827, but there could be a reason to calculate something
from a known date and time, that's not to do with a computer file. And
there's the converse function. If you had to calculate a date and time
in 2023, would you know what rules would be applied during that year to
do it correctly?
We *do* have a table of rules, it is in the tzdata package.
You will be surprised by how much information is there.
For future dates, of course, there can be inaccuracies, as rules are
often changed. That is the reason tzdata.rpm is often updated.
Try
"zdump Europe/Rome"
I see rules covering since 1866 up to 2500. Not bad (Italy was forged on 1861).
Maintaining the tzdata rules is quite a job.
Recently the maintainer retired and IANA had to prepare a "transition plan"
to handle the emergency:
http://tech.slashdot.org/story/11/03/03/2143249/timezone-maintainer-retiring
Then there were guys claiming that the info is copyrighted:
http://yro.slashdot.org/story/11/10/06/1743226/civil-suit-filed-involving...
(they then realized they were wrong).
Handling time is really complex, but some smart guys work on that.
--
Roberto Ragusa mail at robertoragusa.it
2:37 p.m.
On 06/30/12 22:17, Tom Horsley wrote:
Every time I start firefox after recent updates, top
shows it periodically taking up to 50% of the CPU
even if I'm just looking at a simple page of plain
html (no scripts, not even any images) on my local
web server.
This is ff 13.0.1 on x86_64 fedora 17.
Any clues? Anyone see anything similar?
I'm experiencing similar behavior with Firefox and Thunderbird.
While I don't have it nailed down, I've got some hunches that
may (or may not) apply to your situation.
I'm running F17 on x86_64 with
firefox-13.0.1-1.fc17.x86_64
thunderbird-13.0.1-1.fc17.x86_64
The issues I have are high CPU utilization and frequent
freezes of these applications. The freeze lasts for a bit
and then the applications become responsive again.
I thought I had it licked when I switched from nouveau to
the nVidia proprietary drivers. This did result in a significant
drop in CPU utilization but did not address the frequent
pauses in TB and FF.
Using strace, I found that a delay happened (to TB) when trying
to get a lock:
open("/u/scott/.pulse-cookie", O_RDWR|O_CREAT|O_NOCTTY|O_CLOEXEC, 0600) = 65
fcntl(65, F_GETFD) = 0x1 (flags FD_CLOEXEC)
fcntl(65, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}^C
Process 4385 detached
<detached ...>
As you can see, I killed the strace. Of note, my home directory is
NFS mounted. It seems that I may be hitting this issue in pulse-audio:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-August/0110...
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269
I followed the suggestion on comment 9:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269/comments/9
to move the pulse-cookie to /tmp and this improved things. However,
I still get some freezes and more strace-ing led to the NFS mounted
~/.cache/event-sound-cache.tbd.{long_hex_string}.x86_64-redhat-linux-gnu
as another possible culprit. I created a symlink from ~/.cache to
local disk and now things seem OK (with about 30 minutes of testing).
Scott
4:08 a.m.
On 01.07.2012, Tom Horsley wrote:
It is sitting there using between 50 and 100% of the
CPU virtually all the time :-(.
I did watch closely over a period of 15 min. now, and Firefox
showed totally normal behaviour without any CPU-spikes.
[root@wildsau ~]# rpm -qa | grep -i "firefox"
firefox-13.0.1-1.fc17.x86_64
7:03 p.m.
On Mon, 2 Jul 2012 00:57:05 +0100
Alan Cox wrote:
The glibc rules are however pretty good for all times that matter
and
there are time geeks who love this kind of detail.
And the tzdata rpm shows as size:1837780 so there is a fair
amount of data being used by the libraries to try and
interpret time correctly.
8:31 p.m.
On 2 July 2012 00:57, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote:
> On 1 July 2012 15:20, Tim <ignored_mailbox(a)yahoo.com.au>
wrote:
>
> > On that note, I've often wondered how systems that look at a file's GMT
> > datestamp and tell you that time translated into your local time, cope
> > with datestamps from a long way away, when timezone rules keep on
> > changing.
They don't.
Fortunately most people are not worried about the exact day the Tynwald
of the Isle of Man adopted GMT and other such trivia
Until relatively recently we also had madness like the UK daylight
savings change being a human selected date, and it did get moved a couple
of times to avoid clashing with major events.
For the future 2800 is where the fun really gets going. Is it a leap year
- depends which church calendar is used 8)
Some people make their own fun: http://en.wikipedia.org/wiki/Ethiopian_calendar
--
imalone
http://ibmalone.blogspot.co.uk
6:57 p.m.
On Sun, 1 Jul 2012 21:04:27 +0100
Ian Malone <ibmalone(a)gmail.com> wrote:
On 1 July 2012 15:20, Tim <ignored_mailbox(a)yahoo.com.au>
wrote:
> On that note, I've often wondered how systems that look at a file's GMT
> datestamp and tell you that time translated into your local time, cope
> with datestamps from a long way away, when timezone rules keep on
> changing.
They don't.
Fortunately most people are not worried about the exact day the Tynwald
of the Isle of Man adopted GMT and other such trivia
Until relatively recently we also had madness like the UK daylight
savings change being a human selected date, and it did get moved a couple
of times to avoid clashing with major events.
For the future 2800 is where the fun really gets going. Is it a leap year
- depends which church calendar is used 8)
The glibc rules are however pretty good for all times that matter and
there are time geeks who love this kind of detail.
Alan
3:04 p.m.
On 1 July 2012 15:20, Tim <ignored_mailbox(a)yahoo.com.au> wrote:
On that note, I've often wondered how systems that look at a
file's GMT
datestamp and tell you that time translated into your local time, cope
with datestamps from a long way away, when timezone rules keep on
changing. We could maintain a table of rules so that the computer can
correctly give you the times during summer of 1976, but how far back is
the table maintained? Sure, you won't have to read back a timestamp
from the year 1827, but there could be a reason to calculate something
from a known date and time, that's not to do with a computer file. And
there's the converse function. If you had to calculate a date and time
in 2023, would you know what rules would be applied during that year to
do it correctly?
Of course it's not a particularly new problem, historians have had to
contend with missing (or extra) days and years for a long time.
--
imalone
http://ibmalone.blogspot.co.uk
9:20 a.m.
On Sun, 2012-07-01 at 08:47 -0400, Tom Horsley wrote:
I don't understand the complicated interactions that
make a leap second confuse a computer more than the
RTC running slow confuses it,
It's a smallish problem to tell the computer that the time is wrong, and
to reset the clock to another time, whether forwards or backwards.
Sometimes that's handled without major issues, sometimes it does have
repercussions. But it's something that computing has dealt with for
quite a long time.
Leap seconds, on the other hand, means that for one particular moment in
time, a minute isn't 60 seconds long. That's not an event that a lot of
people calculating dates and times have ever considered, and some things
handle that very badly, such as crashing.
For some situations, you can simply reset and start again, after the
time change. But how do you handle things that happen during that extra
second with software that has no concept of a 61 second minute? When
something happened on that date, how do you represent it if you cannot
say a date of 2012-06-30 00:00'60"? (Remember the seconds count from
zero to 59, not 1 to 60.) Do you call it 00:01'00" and have two,
different, 1 minutes past midnight?
And then there's the converse... If we have a year where they have to
deduct seconds, how do represent something that happened during the,
now, removed seconds, but recorded by the, then, still counting clock?
And, in either case, when you use a system that counts the number of
seconds since a certain epoch, to show you the date and time of
something, do you show the right time and date when there's a miscount
in the middle of it? You need a correction table of dates it has to
modify, and I don't think anybody's ever produced a clock program that
does that.
On that note, I've often wondered how systems that look at a file's GMT
datestamp and tell you that time translated into your local time, cope
with datestamps from a long way away, when timezone rules keep on
changing. We could maintain a table of rules so that the computer can
correctly give you the times during summer of 1976, but how far back is
the table maintained? Sure, you won't have to read back a timestamp
from the year 1827, but there could be a reason to calculate something
from a known date and time, that's not to do with a computer file. And
there's the converse function. If you had to calculate a date and time
in 2023, would you know what rules would be applied during that year to
do it correctly?
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
8:31 a.m.
New subject: what on earth is firefox up to? (and httpd, ATS, named...)
On Sunday, 1. July 2012. 15.06.34 Reindl Harald wrote:
Am 01.07.2012 14:47, schrieb Tom Horsley:
> They really ought to switch to a new version of NTP
> protocol that is just like the old one, but works from
> TAI and sends a database of leap second info around as
> well so computers can translate TAI into UTC.
in case of a bug whatever new protocol will not help
this seems more likely to be a kernel bug because
there were many apps on different machines affected
* BIND
* MySQL (hardly!)
* Apache Traffic Server
* Firefox
* Thunderbird
* who knows what else
see also:
http://bugs.mysql.com/bug.php?id=65778
i recently restarted ALL computers in our production envirnonment
up to any VMware ESXi Host, SAN-Storage-Controllers (Managment/Storage)
even up to my Android-Phone for security after woke up and saw tons of
alarms about high CPU usage on the whole infrastructure caused
mostly by 15 mysqld instances (and saw the same at home in VMware-Guests
and host)
yes, my first guess to the mysql-list was that i think it
has something to do with teh leap-second last night
I've got bitten by this as well.
It was a kernel bug, mishandling the leap second (AFAIU, it left the door open
for some race condition to happen or not happen, and if it happens...). See
http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html
Of course, the workaround is to reset the date or reboot the machine,
whichever is easier. ;-)
Best, :-)
Marko
8:06 a.m.
New subject: what on earth is firefox up to? (and httpd, ATS, named...)
Am 01.07.2012 14:47, schrieb Tom Horsley:
On Sun, 01 Jul 2012 00:53:11 -0700
Nataraj wrote:
>
http://www.google.com/search?ix=acb&sourceid=chrome&client=ubuntu...
Thanks for the pointer, that may have been it!
I don't understand the complicated interactions that
make a leap second confuse a computer more than the
RTC running slow confuses it, but this issue did indeed
go away after a reboot
a bug is a bug
They really ought to switch to a new version of NTP
protocol that is just like the old one, but works from
TAI and sends a database of leap second info around as
well so computers can translate TAI into UTC.
in case of a bug whatever new protocol will not help
this seems more likely to be a kernel bug because
there were many apps on different machines affected
* BIND
* MySQL (hardly!)
* Apache Traffic Server
* Firefox
* Thunderbird
* who knows what else
see also:
http://bugs.mysql.com/bug.php?id=65778
i recently restarted ALL computers in our production envirnonment
up to any VMware ESXi Host, SAN-Storage-Controllers (Managment/Storage)
even up to my Android-Phone for security after woke up and saw tons of
alarms about high CPU usage on the whole infrastructure caused
mostly by 15 mysqld instances (and saw the same at home in VMware-Guests
and host)
yes, my first guess to the mysql-list was that i think it
has something to do with teh leap-second last night
7:47 a.m.
On Sun, 01 Jul 2012 00:53:11 -0700
Nataraj wrote:
I think maybe this is caused by the leap second issue. Try
rebooting
and see if it goes away. See
http://www.google.com/search?ix=acb&sourceid=chrome&client=ubuntu...
Thanks for the pointer, that may have been it!
I don't understand the complicated interactions that
make a leap second confuse a computer more than the
RTC running slow confuses it, but this issue did indeed
go away after a reboot (and I'm pretty sure I didn't
see the problem till after midnight UTC which is when
the leap second would have happened).
They really ought to switch to a new version of NTP
protocol that is just like the old one, but works from
TAI and sends a database of leap second info around as
well so computers can translate TAI into UTC.
4:09 a.m.
Tim:
> General things that cause Firefox to chew through the CPU, when
you
> don't expect it to:
>
> 2. A long page visit history.
JD:
The storage for this list is like a drop in the bucket compared
to the storage for a large web page cache.
The same answer applies for the keeping of the list of what you've
downloaded, the cache, the visit history, et cetera: It's not the space
used, but the processing of lots of little files, comparing the data
kept in the database about the files, and working out which ones should
be left or deleted.
There seems to be something extremely inefficient about how it does
that. For instance, people noticed a big difference when the bookmarks
changed from being a flat HTML file to a database system.
> 4. Bookmarked RSS feeds that it's going to visit and
fetch updates
> from.
I have none of those!
I can't recall whether there were any pre-bookmarked with the default
installation.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
2:53 a.m.
On 06/30/2012 10:13 PM, David Timms wrote:
On 01/07/12 13:58, Tim wrote:
> On Sat, 2012-06-30 at 22:17 -0400, Tom Horsley wrote:
> 4. Bookmarked RSS feeds that it's going to visit and fetch updates
> from.
> 5. Even just a large collection of static page bookmarks seem to
> bog it down.
It would be interesting to see what net traffic is requested/received
during startup. Stopping all other net apps (updates, etc), starting
wireshark capturing, and then starting firefox, could give a good clue.
I think maybe this is caused by the leap second issue. Try rebooting
and see if it goes away. See
http://www.google.com/search?ix=acb&sourceid=chrome&client=ubuntu...
Nataraj
2:52 a.m.
On 2012/07/01 00:27, JD wrote:
On 07/01/2012 12:39 AM, jdow wrote:
> On 2012/06/30 20:55, JD wrote:
>> On 06/30/2012 08:17 PM, Tom Horsley wrote:
>>> Every time I start firefox after recent updates, top
>>> shows it periodically taking up to 50% of the CPU
>>> even if I'm just looking at a simple page of plain
>>> html (no scripts, not even any images) on my local
>>> web server.
>>>
>>> This is ff 13.0.1 on x86_64 fedora 17.
>>>
>>> Any clues? Anyone see anything similar?
>> 50% !!!???
>> Huh.... consider yourself LUCKY!
>> On my old unicore amd64 (3.7GHz "equivalent :) :) /smirk/)
>> it escalates sometimes to 95% of cpu.
>
> top tends to be confusing that way.
> Note this line from my machine at a time it said FF was at 87.8%:
> Cpu(s): 13.6%us, 33.7%sy, 0.0%ni, 52.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
>
> That was really 87.4% of the 13.6% user time that was consumed.
>
> {^_^}
in <kernel source>/include/linux/taskstats.h
The comment reads:
/* cpu "virtual" running time
* Uses time intervals seen by the kernel i.e. no adjustment
* for kernel's involuntary waits due to virtualization.
* Value is cumulative, in nanoseconds, without a corresponding count
* and wraps around to zero silently on overflow
*/
Hm, please define virtualization in this context. I am running a flat
SL6.2 system with no virtual machine in the box at all.
Note that you get 100% if you add up all the values on that line.
There is no way you can get 87.4% cpu usage out of those numbers
without claiming some of the idle time is used by firefox without
attribution.
{^_^}
2:27 a.m.
On 07/01/2012 12:39 AM, jdow wrote:
On 2012/06/30 20:55, JD wrote:
> On 06/30/2012 08:17 PM, Tom Horsley wrote:
>> Every time I start firefox after recent updates, top
>> shows it periodically taking up to 50% of the CPU
>> even if I'm just looking at a simple page of plain
>> html (no scripts, not even any images) on my local
>> web server.
>>
>> This is ff 13.0.1 on x86_64 fedora 17.
>>
>> Any clues? Anyone see anything similar?
> 50% !!!???
> Huh.... consider yourself LUCKY!
> On my old unicore amd64 (3.7GHz "equivalent :) :) /smirk/)
> it escalates sometimes to 95% of cpu.
top tends to be confusing that way.
Note this line from my machine at a time it said FF was at 87.8%:
Cpu(s): 13.6%us, 33.7%sy, 0.0%ni, 52.5%id, 0.0%wa, 0.0%hi, 0.2%si,
0.0%st
That was really 87.4% of the 13.6% user time that was consumed.
{^_^}
in <kernel source>/include/linux/taskstats.h
The comment reads:
/* cpu "virtual" running time
* Uses time intervals seen by the kernel i.e. no adjustment
* for kernel's involuntary waits due to virtualization.
* Value is cumulative, in nanoseconds, without a corresponding
count
* and wraps around to zero silently on overflow
*/
1:39 a.m.
On 2012/06/30 20:55, JD wrote:
On 06/30/2012 08:17 PM, Tom Horsley wrote:
> Every time I start firefox after recent updates, top
> shows it periodically taking up to 50% of the CPU
> even if I'm just looking at a simple page of plain
> html (no scripts, not even any images) on my local
> web server.
>
> This is ff 13.0.1 on x86_64 fedora 17.
>
> Any clues? Anyone see anything similar?
50% !!!???
Huh.... consider yourself LUCKY!
On my old unicore amd64 (3.7GHz "equivalent :) :) /smirk/)
it escalates sometimes to 95% of cpu.
top tends to be confusing that way.
Note this line from my machine at a time it said FF was at 87.8%:
Cpu(s): 13.6%us, 33.7%sy, 0.0%ni, 52.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
That was really 87.4% of the 13.6% user time that was consumed.
{^_^}
12:13 a.m.
On 01/07/12 13:58, Tim wrote:
On Sat, 2012-06-30 at 22:17 -0400, Tom Horsley wrote:
4. Bookmarked RSS feeds that it's going to visit and fetch updates
from.
5. Even just a large collection of static page bookmarks seem to
bog it down.
It would be interesting to see what net traffic is requested/received
during startup. Stopping all other net apps (updates, etc), starting
wireshark capturing, and then starting firefox, could give a good clue.
10:58 p.m.
On Sat, 2012-06-30 at 22:17 -0400, Tom Horsley wrote:
Every time I start firefox after recent updates, top
shows it periodically taking up to 50% of the CPU
even if I'm just looking at a simple page of plain
html (no scripts, not even any images) on my local
web server.
General things that cause Firefox to chew through the CPU, when you
don't expect it to:
1. A large cache, that it's going to process to work out what's old
enough to be discarded.
2. A long page visit history.
3. Keeping the download list of everything you've downloaded.
4. Bookmarked RSS feeds that it's going to visit and fetch updates
from.
5. Even just a large collection of static page bookmarks seem to
bog it down.
Those are the ones that I can remember noticing over the years. Point 4
has always seemed a terrible hog, seriously delaying the program from
even starting up, for me. Point 1, tied with point 2, gets seriously
worse over time.
Go through your Firefox preferences, and check out what options are set.
Some of the defaults aren't always the best choices.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
10:55 p.m.
On 06/30/2012 08:17 PM, Tom Horsley wrote:
Every time I start firefox after recent updates, top
shows it periodically taking up to 50% of the CPU
even if I'm just looking at a simple page of plain
html (no scripts, not even any images) on my local
web server.
This is ff 13.0.1 on x86_64 fedora 17.
Any clues? Anyone see anything similar?
50% !!!???
Huh.... consider yourself LUCKY!
On my old unicore amd64 (3.7GHz "equivalent :) :) /smirk/)
it escalates sometimes to 95% of cpu.
10:06 p.m.
On Sun, 01 Jul 2012 10:44:26 +0800
Ed Greshko wrote:
Also, have you tried starting in "safe mode" to see if it
happens?
Yep, tried all the standard stuff, then went ahead and
submitted this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=836763
This was displaying about:blank in a safe mode firefox
instance logged in as a brand new freshly created user.
It is sitting there using between 50 and 100% of the
CPU virtually all the time :-(.
9:44 p.m.
On 07/01/2012 10:17 AM, Tom Horsley wrote:
Every time I start firefox after recent updates, top
shows it periodically taking up to 50% of the CPU
even if I'm just looking at a simple page of plain
html (no scripts, not even any images) on my local
web server.
This is ff 13.0.1 on x86_64 fedora 17.
Any clues? Anyone see anything similar?
Not seeing this on F16 i686....
Will it happen if the firefox window doesn't have focus? Or, does it need to have
focus and you're actually doing something?
It you don't have focus and it periodically goes to 50% usage, you can try
"strace -p
NNN" where NNN is the PID see what goes one.
Also, have you tried starting in "safe mode" to see if it happens?
--
Never be afraid to laugh at yourself, after all, you could be missing out on the joke
of the century. -- Dame Edna Everage
9:36 p.m.
On 06/30/2012 07:17 PM, Tom Horsley wrote:
Every time I start firefox after recent updates, top
shows it periodically taking up to 50% of the CPU
even if I'm just looking at a simple page of plain
html (no scripts, not even any images) on my local
web server.
I'm running the latest Firefox on F16, and see the same thing. In fact,
unless my memory's wrong, every time I had one of those weird crashes I
mentioned recently Firefox was loading a page. And, if it matters, it
was always on the visible workspace.
11:19 p.m.
On 06/30/2012 09:58 PM, Tim wrote:
On Sat, 2012-06-30 at 22:17 -0400, Tom Horsley wrote:
> Every time I start firefox after recent updates, top
> shows it periodically taking up to 50% of the CPU
> even if I'm just looking at a simple page of plain
> html (no scripts, not even any images) on my local
> web server.
General things that cause Firefox to chew through the CPU, when you
don't expect it to:
1. A large cache, that it's going to process to work out what's old
enough to be discarded.
Not true in my case. I have set the cache size to
0.
2. A long page visit history.
The storage for this list
is like a drop in the bucket compared
to the storage for a large web page cache.
3. Keeping the download list of everything you've
downloaded.
The storage for that list pales in comparison to a large web page
cache.
It is just appended to, so no insertions are made into the middle of
the list as it is not kept sorted.
4. Bookmarked RSS feeds that it's going to visit and fetch
updates
from.
I have none of those!
5. Even just a large collection of static page bookmarks seem
to
bog it down.
Why would that bog it down? Again, storage for bookmarks
is a drop inthe bucket compared with web page cache.
On my machine, with 0 cache storage, FF sometimes consumes
95% of cpu. Currently running 13.0.1
Those are the ones that I can remember noticing over the years. Point 4
has always seemed a terrible hog, seriously delaying the program from
even starting up, for me. Point 1, tied with point 2, gets seriously
worse over time.
Go through your Firefox preferences, and check out what options are set.
Some of the defaults aren't always the best choices.
4343
days inactive
4353
days old
24 comments
15 participants
participants (15)
-
Alan Cox -
Development discussions related to Fedora -
Ed Greshko -
Heinz Diehl -
Ian Malone -
JD -
jdow -
Joe Zeff -
Marko Vojinovic -
Nataraj -
Reindl Harald -
Roberto Ragusa -
Scott Karlin -
Tim -
Tom Horsley