# System very slow while compile



## zilion (Jul 4, 2016)

I know that compiling a program requires a lot of machine, especially the processor. I've done a lot of adjustments in my system (tunning kernel, boot, and others..) and still remains very slow while compiling software. Is possible minimize this lag?

My specs; i3 2600 / 4GB Ram / FreeBSD 10-3


----------



## Murph (Jul 4, 2016)

Using nice(1) is the traditional way to do something like that, when the CPU is the limiting factor.  With modern CPUs, however, there's a good chance of the disk subsystem being a bottleneck.  Compiling involves a great deal of random reading and writing to/from the filesystem.

Many standard desktop drives are optimised to be cheap, rather than for performance or reliability, so can very easily get bogged down by a heavy random workload.  Don't believe the hype on the drive's spec sheet, e.g. a SATA-150 drive with internal peak transfer rate stated as 75MB/s or more sometimes actually delivers just 1–2MB/s under a heavy random workload.  The drives can only deliver their advertised performance on long continuous and contiguous streaming reads (which is extremely rare under general purpose workloads).  As soon as there's lots of head movement (seeking), you are lucky if they deliver 10% of advertised data rate.  Compiling a large project (e.g. `make buildkernel` or `make buildworld`) guarantees lots of seeking as there are a huge number of individual inodes and data blocks involved.

top(1) will let you get a fair idea of whether it is saturating CPU.  gstat(8) will let you get a fair idea of whether it is saturating disk.

Lastly, be careful with kernel tuning.  Recent versions of FreeBSD (and most recent versions of most Unix variants) really shouldn't need a great deal of tuning for many normal workloads.  It is very easy to kill the performance through kernel tuning. Some of the tuning guides you may find on the web may well be out of date and counterproductive (e.g. some of the old advice for tuning the network stack actually kills performance on current versions).  The days of tuning being a requirement before you could get good performance are essentially banished into the past, although there are exceptions to that.  Current Unix versions should generally only receive the absolute minimum of kernel tuning, to address specific known / observed issues, or enable specific functionality that you understand and want/need (or similarly to disable stuff).


----------



## tomxor (Jul 4, 2016)

I know it's purely anecdotal but to backup Murph's suggestions: I've noticed my macbook appears to be completely responsive when recompiling kernel, even though it's quite old (core 2 duo) but it also has an old intel SSD with good random I/O performance (max contiguous read/write throughput is o-k by today's standards but I care little about that).

I can carry on using my DE and browser or do something that's not excessively CPU intensive without any obvious slowdown.


----------



## blackhaz (Oct 27, 2018)

Resurrecting old thread but I have the same experience: 
ThinkPad X1 Yoga (1st gen, 2016) on Core i7 with SSD and FreeBSD: System slows down significantly with poor DE response when building something from ports.
MacBook Pro 2015 on Core i5 with SSD and MacOS: No problems at all. 

Perhaps, the user processes are allowed to seize too much CPU resources by default?


----------



## rigoletto@ (Oct 27, 2018)

Watch memory and swap usage. The only time I have slowness while compiling is when I run out of memory and the thing start swaping.


----------



## blackhaz (Oct 27, 2018)

No, plenty of free memory. Xfce's task manager shows 2.7 GB used out of 7.2 GB. Not an issue at all.


----------



## rigoletto@ (Oct 27, 2018)

Try setting `sysctl kern.sched.preempt_thresh=224`. If it works add to /etc/systemctl.conf.


----------



## blackhaz (Oct 27, 2018)

Already set.


----------



## shkhln (Oct 27, 2018)

blackhaz said:


> Perhaps, the user processes are allowed to seize too much CPU resources by default?



Perhaps you are expecting too much from a thin-and-light notebook, aka _always_ throttling piece of shit. (Yeah, I basically hate notebooks.)


----------



## rigoletto@ (Oct 27, 2018)

You may find something useful in HERE or HERE (a bit outdated but still ok).


----------



## blackhaz (Oct 27, 2018)

No, shkhln, that definitely has something to do with how resources are allocated. This X1 has faster CPU than the MacBook I'm comparing it with. Same amount of RAM, and comparable SSD performance. It spins the fan a lot, but it's definitely not a PoS machine.


----------



## shkhln (Oct 27, 2018)

I have nothing against this model per se, it's rather what I think about ultrabooks in general.



blackhaz said:


> This X1 has faster CPU than the MacBook I'm comparing it with.



Did you determine that from specs or benchmarking?


----------



## Phishfry (Oct 27, 2018)

The CPU's do look like they are closely matched.
I thought the same as shkhln that maybe a dog tablet chip but its not the case:
Apple:https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-5257U+@+2.70GHz
Yoga:https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-6600U+@+2.60GHz&id=2608


----------



## trev (Oct 27, 2018)

blackhaz said:


> System slows down significantly with poor DE response when building something from ports.



Limit the number of concurrent ports build jobs ... add `MAKE_JOBS_NUMBER?=n` to /etc/make.conf  where n is the number of jobs to run. For my late-2009 Mac Mini (Intel Core 2 Duo 2.53GHz, 750GB Seagate ST750LX003 7200RPM hybrid drive, 8GB RAM) I use 2 otherwise it defaults to 4 and noticeably slows down X Window usage (eg web browsing, mail).


----------



## fernandel (Oct 28, 2018)

blackhaz said:


> It spins the fan a lot, but it's definitely not a PoS machine.


Maybe is something overheated?
I had the problem with HD temperature and it compailing became so slow.


----------



## blackhaz (Oct 28, 2018)

Thanks, trev. I've just learned that MAKE_JOBS_NUMBER uses the number of available CPUs (sysctl -n kern.smp.cpus) to set the default. Indeed, on desktop systems we might want to set that to a more conservative value, so nothing is wrong with my machine. It's just FreeBSD is optimized to seize all the resources by default when building ports. I wonder why port building jobs aren't launched with some sort of nice setting to lower their priority by default.


----------

