Solved "pkg" is hella slow (not internet speed)

First_Law_of_Unix

First_Law_of_Unix

Hello everyone,

have been using FreeBSD for a long time. I just downloaded and installed FreeBSD 13.1

When I use "pkg install" to install basic applications, "pkg" takes like 2 mins to update repository catalogue and when installing an application which has like 5 dependencies, it will fetch and download each package super fast but will pause or hang after each download fetch like 30secs to 1 min. So installing basic apps like "vim" or nano will literally take 5 mins, which is crazy. Installing "firefox" via "pkg" will take an hour since it has to fetch like 135 dependencies.

So the issue is not the internet (I have fast low latency fiber optic internet) and speeds from the repository servers are fast.
I see that "pkg" downloads each fetch dependency super fast but pauses or freeze after each fetch for 30 secs to 1 min. This is where the issue relies.

I tried the same for FreeBSD 13 and 12.1 and have the same exact issue. (This wasn't the case when I used FreeBSD 13 and 12.1 when they were first released, "pkg" was super fast back then).

It seems like the latest "pkg" build has a bug. I haven't tried downgrading it and use a previous version of "pkg" but something is clearly wrong with the current "pkg".

I just installed GhostBSD and when I type on the terminal "freebsd-version" it shows "13.0-STABLE".
The odd thing is that installing applications using "pkg" is super fast and functioning properly. Would also like to point out that GhostBSD have already preinstalled "pkg", so I am assuming I am not using the latest version of "pkg" when I installed GhostBSD.

So with this said, I am convinced something is wrong with "pkg" after when it is installed manually from a fresh install of FreeBSD.

Thanks.

EDIT:

Here is the video captured, take a look.

I did a fresh install of FreeBSD 13.1

View: https://youtu.be/WT-h6HNlVe8


Around timestamp "9:00" is when I do a "pkg install firefox"... and you can clearly see fetch downloads are super fast, but unpacking takes forever...
 
Last edited:
I cannot confirm this. The FreeBSD pkg mirror my system uses does have a faster speed (I am in continental Europe, by the way).

GhostBSD uses its own repos. If they are faster than that may depend on your geolocation. Where I live these repositories were ultra slow when I tested it.
 
First_Law_of_Unix said:
I see that "pkg" downloads each fetch dependency super fast but pauses or freeze after each fetch for 30 secs to 1 min.
Click to expand...
It's probably unpacking the package at this point. That takes quite a bit of I/O, so if you have really slow I/O this can take a while, especially with a big package.
 
Is there some kind of "troll campaign" against pkg? Cause I keep seeing these posts...

Maybe some official mirrors don't have the connection quality they should have, I can't verify this. But then, this would be, kind of, "internet speed".

Do a simple test: Build your own repo with poudriere. Now install from there, e.g. using a decent ethernet LAN. It will be fast. It's what I'm doing and it was always fast. Then, the only way pkg could ever be slow is connectivity.
 
Zirias said:
Do a simple test: Build your own repo with poudriere. Now install from there, e.g. using a decent ethernet LAN. It will be fast. It's what I'm doing and it was always fast. Then, the only way pkg could ever be slow is connectivity.
Click to expand...
That test is anything but simple. Sure, once you have it going correctly, then testing the speed is a simple matter. I'm still working on having a correct setup for a Poudriere-built repo, nearly 9 months into the project by now, self-signed SSL certs are my current hurdle. And of course I would expect my own poudriere-built repo to be fast. Yeah, other factors that impede speed will be eliminated, but it does take a truckload of effort to set things up with that goal in mind.

I guess the simple part is to pretend that you actually have your own Poudriere-built repo, and to make some logical extensions from that scenario.
 
astyle said:
I'm still working on having a correct setup for a Poudriere-built repo, nearly 9 months into the project by now,
Click to expand...
it took me an hour back then (plus 24 hours to actually build something to populate it the first time). ?‍♂️
astyle said:
self-signed SSL certs are my current hurdle.
Click to expand...
Just, why? What's to gain signing your local repo? Or do you intend making it "public" (on the internet)?
 
Zirias said:
it took me an hour back then (plus 24 hours to actually build something to populate it the first time). ?‍♂️
Click to expand...
My goal for my Poudriere repo is to have KDE built with my own make config flags, and make it upgradeable independently of the rest of the system. If I just wanted to compile KDE with my own flags, and didn't care about being forced into upgrading the rest of the system, then I could just go with defaults, and have a workable Poudriere setup in an hour or so.
Zirias said:
Just, why? What's to gain signing your local repo? Or do you intend making it "public" (on the internet)?
Click to expand...
pkg(8) requires an SSL cert. If I were to make my repo available on the public Internet, then I'd go with Let's Encrypt! service. My scenario, however involves pointing a clean base install of FreeBSD (one that does not even have a bootstrapped pkg yet) to my Poudriere repo on my home network. I want to bootstrap against that custom Poudriere repo that I'm building.
 
astyle said:
pkg(8) requires an SSL cert.
Click to expand...
it doesn't

Code: 
% cat /usr/local/etc/pkg/repos/local.conf 
local: {
  url: "pkg+http://pkg.rostwald.lan/packages/${ABI}-latest",
  mirror_type: "srv",
  signature_type: "pubkey",
  pubkey: "/usr/local/etc/pkg/keys/pkg.rostwald.lan.key",
  enabled: yes,
  priority: 5
}
 
Yep, works just fine on HTTP. Even a signing key isn't required.

Code: 
dicelan: {
        enabled: yes
        url: http://ports.dicelan.home/packages/130-release-server
}
 
Which leads me back to my initial question: what's to gain from that in your private LAN?

astyle said:
My goal for my Poudriere repo is to have KDE built with my own make config flags, and make it upgradeable independently of the rest of the system.
Click to expand...
This sounds a bit mysterious. But if your actual goal is to only compile packages you're using custom build options for, you might want to give poudriere-devel a try.
 
Zirias said:
This sounds a bit mysterious. But if your actual goal is to only compile packages you're using custom build options for, you might want to give poudriere-devel a try.
Click to expand...
It's actually the same idea as upgrading your favorite app on your phone, without being forced to upgrade the entire phone. I want not just to compile with my own flags - I want to be able to repeat the compilation with the next version, and make sure it can be installed seamlessly, too. Pre-compiled stuff from official repos will pull in updated deps and create conflicts.
Zirias said:
Which leads me back to my initial question: what's to gain from that in your private LAN?
Click to expand...
That's my own twist on things.... I do want to set things up with at least some 'Best practice' security on my private LAN. Yeah, that is making things harder on myself, but I think I still learn some useful stuff along the way. I do see that as an 'educational venture', so to speak. There might not be anything to really gain for the immediate project, but I see 'benefits in the future'.
 
SirDice said:
It's probably unpacking the package at this point. That takes quite a bit of I/O, so if you have really slow I/O this can take a while, especially with a big package.
Click to expand...

Yes, this is exactly a better explanation.

Seems like unpacking the package after each fetch is causing some 30sec to 1min delay and it could be slow I/O. It is weird, package sizes of 12 KB to 50MB all have around similar 30sec to 1 min delay.
When "pkg" is downloading each package fetch is super fast however, just that "pkg" pauses when it is unpacking each fetch.

I'm no expert (someday... someday... will be a pro :cool:), have no clue how to solve this. I haven't tried downgrading "pkg" yet, will try this and will let know if it did the trick.

This is my build:

Processor: AMD FX(tm)-8350 Eight-Core Processor, 4000 Mhz, 4 Core(s), 8 Logical Processor(s)
Mobo: ASRock 970 Extreme3
RAM: 32 GB DDR3
Hard Drive: Kingston SSD 256GB

Thanks.
 
tux2bsd said:
What hardware is this on? Something is wrong with the CPU, RAM, or IO on the system you've installed it on. Smells like ZFS and very low specs.
Click to expand...

Yes, I was assuming ZFS could be the issue... I am recording a video of a screen capture to show exactly what's going on with "pkg"...
 
This is a network issue.
The pauses do not happen in the install phase, they happen in the download phase. And the happen before each individual download, consistently. There is no unpacking at that point, the received files are just dumped into /var/cache/pkg.
The download itself is fast, so this is most likely a DNS timeout or delay.
If I watched it properly, You did DHCP for network config (and there was also an error message shown there). Check what you get as the DNS settings (/etc/resolv.conf), and check if these work properly.
Further steps to try:
  • put a known working external resolver in /etc/resolv.conf (e.g. 8.8.8.8)
  • get rid of DHCP and do the network config manually with settings that are known to work
  • check if that interface card has difficulties negotiating linkspeed (some of them do)
  • run a tcpdump and capture what is happening during these pauses
 
I’ve not watched the video but the YouTube thumbnail is showing a warning about ada1 (and I see the same warning if I start the video) so might be worth checking that out.

But as others have said 30 seconds is often a network timeout.

Did you follow the link Alexander88207 sent - that looked very similar to your issue?
 
Try adding -4 to the pkg(8) command, do you still get the delay? If the delay is gone it's likely an IPv6 issue.

Code: 
     -4      pkg will use IPv4 for fetching repository and packages.
 
You must log in or register to reply here.
Back
Top