Summary: | eupdatedb in esearch 0.5.2 *extremely slow* | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Narada Sage <narada.sage> |
Component: | Conceptual/Abstract Ideas | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | radek, sachse |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Screenshot whhich shows now load but zombie |
Description
Narada Sage
2004-01-27 08:27:14 UTC
Perhaps it was manifested by load on the machines as one of them it has resumed normal speed. If it works for you all it may indicate a rare scenario in my case where it was slow. You may mark as WORKSFORME if you think so. I've noticed a speed decrease some time ago, eupdatedb was/is running for 2 hours. Haven't really investigated it further as I thought it's caused by my NFS setup. well, since esearch uses portage as it's backend, any speed hits is more of a portage problem isnt it ? I tried eupdatedb twice from the commandline. The first time, I happened to also emerge other packages (not during the whole update though) and it took 19,5 minutes. I run top, and I saw, besides the eupdatedb command, a lot of /usr/sbin/ebuild.sh depend processes running one after the other (i.e. not concurrently). The second time, eupdatedb was running with no other load, and it completed within 1,5 minutes. I run top, but no ebuild.sh was noticed running. I own a 1,5GHz Pentium-M (Centrino). HTH right, all that `/usr/sbin/ebuild.sh depend` stuff is from portage, not eupdatedb Hi, I did some benchmarks on eupdate some weeks ago, and I found out, that this is a (really annoying) problem of portage. I think the problem is the save_eclassdb() method in portage.py. This function is called ~10000 times during an eupdatedb. I have not found out what it is doing exactly, but it takes a lot of time. I hope this will be fixed in some of the following portage updates altough it's not that important for me, because I run eupdatedb (esync) once a day, and it only takes me about 2 minutes averagely. David I solved it by executing emerge metadata Kind regards, DQ and metadata should be properly created after `emerge sync` Created attachment 509014 [details]
Screenshot whhich shows now load but zombie
With esearch 1.3-r1 i see the problem again.
It starts with >100/s but after a few thousands it goes to 1/s max 3/s.
In this case a ebuild.sh zombie can be found.
There will no CPU time consumed this seems only waiting times.
I think there is a bug in the part which is calling ebuild.sh.
It seems to die. This produces the zombie and the part which called the crashed part is waiting of its child.
This slow down the whole process of updating the database.
cpuinfo: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
If it's taking a log time then that means that metadata cache needs to be generated. You can use `emerge --regen --jobs=NUM` to generate the cache using multiple cpu cores. |