Understood.
What about other versions? Is this behavior specific to 4.11 or to all later
RPM versions as well?
P.S. We rebuilt the DB immediately when we saw the slowness, showed no
difference at all. Running `rpm -qf --nosignature --nodigest` takes exactly
same as just `rpm -qf`
--
You are
Lots of people have gone ZOMG over the stat()'s. That's not where the time is
spent, it's spent on database hits and verifying fetched headers and whatnot.
BDB performance can degrade badly over time, --rebuilddb can make a *huge*
difference to performance, and also --nosignature --nodigest
@pmatilai Sorry, I have to disagree. It's not that cheap, as I said in the
ticket itself:
> when the former query takes 0.03s, the latter can take up to 2 seconds.
In my company, as everything is distributed as RPM packages, we need to query
that a lot during the build, to get the RPM
Closed #1770.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1770#event-5263952591___
Rpm-maint mailing list
Rpm looks up paths starting by the basename, which is why something ending in
"lib" will turn up a huge amount of results whereas "1.100" probably doesn't.
And then when you apply all the symlink checking etc... it turns out to be a
lot of stat()'s. But stat() is cheap, trying to optimize a few
@ffesti Well, it doesn't do it for other queries...
What if I have a symlink /opt/pkg/mylibxxx/1.100 -> /opt/pkg/mylib/1.100? But
as I said before, RPM does exactly one stat() in this case, it doesn't try to
find other possible symlinks.
Also, a symlink can have a different name, e.g.
The reason for this behaviour is that RPM checks if the file is available at a
different location as a symlink. But I am not 100% sure if all those checks are
really necessary but it is quite possible that just one stat call is not
sufficient.
--
You are receiving this because you are
@DemiMarie I'll leave the gpg configuration to our IT guys (in our firm, we use
RPM to distribute internally developed packages and can't download external
RPMs, so RPM security is not the highest priority).
This ticket is about the query performance as it really affects my everyday
work.
--
> Are there any known workarounds for rpm 4.11.3 (as it's a system version so
> I'm stuck with it in the office)?
> Maybe there is a patch that could be applied to 4.11.3 without a full upgrade
> (so I could convince our admins to apply it)?
RPM 4.11.3 is horribly insecure, so unless you are
I'm seeing a problem with executing "rpm -qf " (rpm 4.11.3)
When I do strace on that command and watch stat() calls, it shows very
different behavior depending on what I'm querying for.
If I do "rpm -qf /opt/pkg/mylib/1.100" it does exactly one stat() on the
directory I requested.
If I do "rpm
10 matches
Mail list logo
