|
Bugzilla – Full Text Bug Listing |
| Summary: | large delay after choosing "update" | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Christian Boltz <suse-beta> |
| Component: | Update Problems | Assignee: | Duncan Mac-Vicar <dmacvicar> |
| Status: | VERIFIED FIXED | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | jsrain |
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
y2logs
screen photo: top output Log from update run |
||
|
Description
Christian Boltz
2006-01-29 19:09:28 UTC
Created attachment 65563 [details]
y2logs
Can you reproduce this and use a tool like `top' to monitor what process is causing the load? Maby it is an external tool called by YaST. I'll attach a screen photo (is there a way to import the content of TTY4 to a text file?) At least the problem was reproducable. Created attachment 65758 [details]
screen photo: top output
I cannot see any heavy load here? Was the system stalled at this moment? Jiri: Can you provide a clue? Maby the logs give some information about this. I could work on the TTY without problems, and mouse movement was possible in YaST. I could even click the "next" button again (it changed state to pressed and not pressed again) - but without actually showing the next screen because the button was pressed before. See bug 146520 for a possible reason... BTW: I'm installing from a NFS share over 100 MBit network. Same problem when updating to beta3 - and same symptoms: load 0.9, but CPU was >95% idle. This time, I looked at my watch - the pause was about 6 minutes long :-( and my personal patience measurement says me that everything that takes longer than a cup of coffee is major ;-)) Hmm, the time is spent on getting the largest files from the installation source. Even the mount itself takes IMHO quite a long time (3 sec.) If you mount the source separatelly after package manager gets initialized, and copy the file /suse/setup/descr/packages.DU from this source to your local disk, how long does it take? When the choise fresh install/update was displayed, I switched to TTY2 and mounted a harddisk partition (after a "modprobe ext3") and the NFS share. Mounting the NFS share took less than one second. Copying the file took about 2 seconds. (sorry for not having exact times - "time ..." unfortunately didn't put it's output in the "|tee logfile" pipe and I don't want to reboot again.) I'm afraid this is not what you wanted to hear ;-) I have just reproduced the problem with Beta5. The log says more precisely where the problem is (see attachement for whole log): 2006-02-24 03:59:43 <1> 137.65.65.9(3161) [TagFileParser] TagFileParser.cc(parse):101 Started parsing /var/adm/mount/AP_0x00000001/suse/setup/descr/packages 2006-02-24 03:59:58 <1> 137.65.65.9(3161) [TagFileParser] TagFileParser.cc(parse):162 Done parsing /var/adm/mount/AP_0x00000001/suse/setup/descr/packages Parsing packages file took more than 15 seconds. Duncan, do you think we can do something about it? Created attachment 70236 [details]
Log from update run
Even though it probably doesn't help much...
The problem did _not_ appear when updating beta3 -> beta6... Was this fortuity or was it "accidently" fixed? We're constantly improving on performance (and reducing log size). The main reason for speedup is the language information available to the solver which greatly reduces the number of scenarious to check, I didn't notice large delays in beta >= 6 and the RCs, therefore I can verify that this is fixed. Thanks! |