| Summary: | Mozilla applications use 100% cpu for 2 mins on first run in a session | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Barry Jackson <zen25000> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins |
| Version: | 2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
Screenshot showing cpu usage during launch of Firefox.
strace output |
||
|
Description
Barry Jackson
2012-08-13 21:03:18 CEST
Created attachment 2641 [details]
Screenshot showing cpu usage during launch of Firefox.
If I can find anything that looks relevant in the logs I will add later.
I don't see what we can do with such bugs... are you sure it's not flash or something like that ? (In reply to comment #2) > I don't see what we can do with such bugs... are you sure it's not flash or > something like that ? No idea. I didn't report this in Cauldron because I expect things to be a bit broken, however now it has migrated to mga2 it's more serious. I guess that it must be some common dependency of these Mozilla apps that has been recently updated in mga2. I am hoping that others will notice this too and add comments. Any suggestions on debugging ? I tried firefox in -safe-mode (i.e. no extensions, add-ons - flash etc.) but it makes no difference. I notice that recently the duration is somewhat less in Cauldron, but it's still a long delay. I can't believe that this only affects me - in both mga2 and mga3. :\ This is still happening and Mga3 is getting closer. In a clean net-installed Cauldron the first run of Firefox in a session now takes 35 seconds to start. This is a KDE installation on an SSD. Subsequent starts of Firefox take a few hundred milliseconds. This is a major issue as a novice user would keep clicking the icon thinking they had not clicked it properly. Even the clock hangs for a large part of the time. Am I really the only one seeing this? On a VirtualBox install of Mageia 3 x86-64, from the beta 1 kde dvd, with all updates installed, I created a new user. Starting firefox for the first time took less than a second here. Same with thunderbird. As part of the qa testing for the alpha/beta iso images, (14 installs on real hardware, per build, 3 builds for beta 3), plus additional testing under VirtualBox, one of the things I always do, is start firefox. I haven't seen any noticeable delays here. For debugging, I think running $ sudo urpmi strace $ strace -r -ostrace.txt firefox (close firefox, as soon as it does open). $ grep -v gettimeofday strace.txt>strace2.txt The compress and attach the strace2.txt CC:
(none) =>
davidwhodgins Created attachment 3299 [details]
strace output
Likewise I never see this in a vbox install.
This is so frustrating.
I ran strace on the clean install and FF opened instantly. Thinking that strace was affecting things I tried over and over in the new installation that yesterday was exhibiting this issue, and it always opens without problem after reboots today. I wondered if KDE session management was upsetting it but changing the defaults to not remember previous sessions made no difference.
I reverted to my regular Cauldron installation which I use full time, and ran strace on that in a new user - it took around 35 seconds. The two files strace.txt and strace2.txt are binary equal, so I compressed the former.
After a reboot I again timed the opening of FF in my user in my normal Cauldron. It takes 1 min 5 seconds. During the first 20 seconds one core is at 100% then two then 3 hit 100% then it opens.
The strace output indicates little to me - maybe you can see something.
I found it! I have been seeing a few HD problems with my SSD and today I backed it up and cloned my Cauldron system onto a regular HD. I am now not seeing this issue - launch time for FF after boot is about 1 second and Thunderbird about 3 seconds - (very large profile). I am going to update the firmware in the SSD and clone this clone back to it, when I have checked it over and re-partitioned it. Note that it was only / that was on the SSD, I am still using the same /home. Closing as invalid for now, but I may be back ;) Status:
NEW =>
RESOLVED Make sure you have discard in the mount options in fstab, for every filesystem
on the ssd.
With my ssd drive on sdb, I also run the following after every boot ...
#!/bin/bash
IFS=$'\n'
dfout=($(df -h|grep sdb|sort))
for dfline in "${dfout[@]}"; do
mountpoint="/${dfline##*/}"
fstrim -v "$mountpoint"
done
Yes I do, however prior to my SSD firmware update discard was not working. Now all is well - I wrote a little script to check it. http://mtf.no-ip.co.uk/pub/linux/barjac/soft/chkdiscard I ran your script and it reported some very large numbers, so I will run it from time to time to get an idea of how often it is really needed. I uploaded it here with a couple of enhancements (nothing important ;) http://mtf.no-ip.co.uk/pub/linux/barjac/soft/trimfs Thanks for that, Barry |