1 |
On Saturday, 20 June 2020 04:18:24 BST urpion@×××.com wrote: |
2 |
> On Sat, Jun 20, 2020 at 08:56:52AM +1000, urpion@×××.com wrote: |
3 |
> > On Fri, Jun 19, 2020 at 06:08:49PM +0100, Michael wrote: |
4 |
|
5 |
> > > A single compile job on a big package can eat >3G of RAM. I don't know |
6 |
> > > what spidermonkey jobs may grow up to, but drop it down to '-j1' and |
7 |
> > > see what you get. |
8 |
> > > |
9 |
> > > A swapfile which you enable on a per ebuild basis if required, can be |
10 |
> > > handy. You can configure this in a package.profile file. On an ext4 fs |
11 |
> > > you could do this as root: |
12 |
> > > |
13 |
> > > touch swapfile |
14 |
> > > dd if=/dev/zero of=swapfile bs=4096 count=400000 |
15 |
> > > mkswap -L Swappage swapfile |
16 |
> > > swapon swapfile |
17 |
> > > |
18 |
> > > If it is a btrfs you'll need to tweak things to be able to used it as a |
19 |
> > > swap: |
20 |
> > > |
21 |
> > > https://wiki.archlinux.org/index.php/Swap#Swap_file |
22 |
> > |
23 |
> > Wow. Thanks Micheal. That's really cool. I will try that. |
24 |
> |
25 |
> I tried to merge the package again with -j1, just to see, but no go. |
26 |
> Making a swap file just as Micheal said did the trick. Thanks a bunch. |
27 |
> I made it in /home. Is that a bad idea? I guess I need to review my |
28 |
> partion scheme. Thanks everyuone, it's great to be back on Gentoo again |
29 |
> |
30 |
> (-: :-) |
31 |
|
32 |
OK, you're definitely short on RAM then, but only for big monster compiles. |
33 |
I'd suggest you give Chromium a miss! ;-) |
34 |
|
35 |
Here's some general thoughts on this topic: |
36 |
|
37 |
Big packages can consume a lot of RAM even for a single job. A swap partition |
38 |
or file will help, but you could soon arrive in a temporary race condition if |
39 |
you use higher counts for MAKEOPTS jobs or if you're also using heavily the PC |
40 |
at the time, placing demands on memory. If you have opened up a mail client, |
41 |
a dozen tabs on a browser, some music/video players, and are running a |
42 |
database & webserver, transcoding, etc. you'll find even a single job on a |
43 |
hungry compile will start paging in and out of swap continuously, thrashing |
44 |
the disk and applications/desktop will become unresponsive for minutes at a |
45 |
time. |
46 |
|
47 |
Memory management then becomes necessary to avoid situations like this. |
48 |
|
49 |
1. SWAP |
50 |
|
51 |
You can add a swap partition, although this will require repartitioning. |
52 |
Alternatively, add a swapfile as I mentioned above. It doesn't matter if you |
53 |
have the file under / or under /home, or some other data partition(s). What |
54 |
matters is the file is owned by root:root and for security is set with 0600 |
55 |
access rights. If you're paranoid about security then the file can be placed |
56 |
on an encrypted partition. I think I had set up a swapfile on a MSWindows |
57 |
NTFS partition once, because there was spare capacity there, so it pretty much |
58 |
does not matter where you set it up - although security may be a concern. |
59 |
|
60 |
It is worth discussing the fs on which you place a swapfile. As I have |
61 |
mentioned already BTRFS can be a problem, especially if you are running older |
62 |
kernels: |
63 |
|
64 |
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F |
65 |
|
66 |
Defragging the fs before you create a swapfile may also be beneficial on |
67 |
spinning disks, to avoid fragmentation. Other than these points, with modern |
68 |
kernels there shouldn't be much difference between a swapfile or a swap |
69 |
partition in performance terms. If anything the swapfile has the benefit of |
70 |
being able to resize it if you need more space - or add a second swapfile too, |
71 |
on the same or different fs. |
72 |
|
73 |
You don't have to use the swapfile every day, every time, if it only becomes |
74 |
necessary for large compiles. In this case you don't need to add it in /etc/ |
75 |
fstab. However, having some swap available at all times it won't hurt your |
76 |
system either. The Linux kernel is intelligent enough to use it when needed. |
77 |
You could always interfere with swappiness to specify yourself how much and |
78 |
how often RAM is copied over to swap. The default is 60: |
79 |
|
80 |
$ sysctl vm.swappiness |
81 |
vm.swappiness = 60 |
82 |
|
83 |
You can reduce it to swap less aggressively, or increase it to swap more so. |
84 |
|
85 |
|
86 |
2. I/O BLOCK SCHEDULER |
87 |
|
88 |
If at some point swapping starts (heavily) and you already have -j=1, you may |
89 |
discover the machine becomes less responsive. Changing the kernel's block |
90 |
scheduler will help on spinning disks. |
91 |
|
92 |
On a spinning disk the input/output queuing and buffering of data as is |
93 |
written and read off the disk can become a constraint, especially during heavy |
94 |
swapping, or heavy stints of writing on /var/tmp/portage, thereby slowing |
95 |
everything down to the point of frustration. Changing the kernel block |
96 |
scheduler for a given disk or partition can help here. The default is mq- |
97 |
deadline: |
98 |
|
99 |
$ cat /sys/class/block/sda/queue/scheduler |
100 |
[mq-deadline] kyber bfq none |
101 |
|
102 |
Changing this to bfq will improve responsiveness: |
103 |
|
104 |
# echo bfq > cat /sys/class/block/sda/queue/scheduler |
105 |
|
106 |
The above pointers ought to get you out of sticky situations when compiling |
107 |
large packages. |
108 |
|
109 |
Happy emerging! :-) |