Searching in Pamac painfully slow when AUR support is on

Support
,
1

I just updated my Manjaro KDE, and after that searching in Pamac is almost unusable.

Typing a few letters in the search field, after the third letter or so Pamac kind of freezes and literally takes several minutes to return any hits. When those hits appear, clicking one takes minutes before actually showing the results.

After unticking Preferences > Third Party > Enable AUR Support, searching is fast again. I don’t know how to determine if this has to do with Pamac or the AUR server.

Anything I can do to improve the speed of searching?

2

The problem is addressed. That happens due to the fact, that the AUR is now a local database and not a query-request on the website. The change happens due to the high workload on the AUR-Server which was known as the great Manjaro DDOS Attack, due to the numbers of requests and how many users used it. :clown_face:

3

Thanks for those pointers. Since I’m experiencing delays of several minutes, not just 1-2 seconds, I’m not convinced my problem is the same. Maybe I’ll add a post at gitlab anyway.

4

The search is not efficiently implemented and the parsed json structure needs a large amount of RAM. Maybe you have not enough?

5

Yeah that highly depends on your system power. For me it is just 1 sec, but note that after 3 letters, the whole database get loaded for a search.

At least what I can test is this:

# drop ram cache, to get real read times.
sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

# read and decompress the databases
time zcat /var/tmp/pamac/dbs/sync/*.{db,files} >/dev/null; time zcat /var/tmp/pamac-build-$USER/packages-meta-ext-v1.json.gz >/dev/null

Result:

zcat /var/tmp/pamac/dbs/sync/*.{db,files} > /dev/null  1,92s user 0,02s system 99% cpu 1,950 total
zcat /var/tmp/pamac-build-$USER/packages-meta-ext-v1.json.gz > /dev/null  0,23s user 0,01s system 99% cpu 0,238 total

That is together about ~2sec for me. Note that /var/tmp is a tmpfs on my system and only exists in my ram, which improves the load time.

1 Like
6

I should have enough (32 GB), but obviously something else was wrong.

Yesterday the issue persisted across several reboots, today I can’t reproduce this behavior and searches give close-to-instant results.

I’m happy things work again, of course, but also quite puzzled how hmm, hickups? like this can happen. Thanks for trying to help!

7

Maybe the first search builds the index and 8s therefore slow, subsequent searches can use this index and will be faster.

After each db update (every 5 minutes), it has to rebuild the index. Maybe it’s this?

8 
time zcat /var/tmp/pamac/dbs/sync/*.{db,files} >/dev/null; time zcat /var/tmp/pamac-build-$USER/packages-meta-ext-v1.json.gz >/dev/null

real	0m2,287s
user	0m2,223s
sys		0m0,032s
gzip: /var/tmp/pamac-build-$USER/packages-meta-ext-v1.json.gz: No such file or directory

real	0m0,004s
user	0m0,004s
sys		0m0,000s

There was an emty folder aur-$user so I changed the command accordingly and got gzip: /var/tmp/pamac-aur-$USER/packages-meta-ext-v1.json.gz: No such file or directory

None the wiser, but happy it works now anyway :slight_smile: