JanJans Blog

Gentoo is a popular and flexible Linux distribution that emphasizes customization, performance, and user control. It is known for its advanced package management system and source-based installation, allowing users to compile software from source code optimized for their specific hardware.

Some key features of Gentoo include:

[snipp blah blah blah]

OK, es hat also schon mal das Marketing-Matertial gelesen und kann mir eine Zusammenfassung geben. Das war mein Test, ob das Teil überhaupt weiß, wovon ich rede.

Ein Real World Problem, bei dem ich unterschiedliche Ansichten im Netz gefunden habe. Mal sehen, was es dazu zu sagen hat.

Yes, when you resume an interrupted package installation using the emerge --resume command in Gentoo, it will reload the MAKEOPTS from /etc/make.conf.

The MAKEOPTS variable in /etc/make.conf sets the number of parallel jobs that can be run during the package compilation process. When you use emerge --resume to continue an interrupted package installation, the compilation process will pick up where it left off, and the number of parallel jobs will be determined by the MAKEOPTS variable in /etc/make.conf.

It's worth noting that emerge --resume will not reload all variables from /etc/make.conf, only MAKEOPTS and a few other variables that are necessary for the package installation process. If you have made changes to other variables in /etc/make.conf since the package installation was interrupted, those changes will not take effect when you resume the installation with emerge --resume.

OK, ich glaube auch, dass es das tut, aber bist du dir auch sicher? Besser mal in die Quelle gucken!

Certainly! Here's the relevant information from the Gentoo documentation:

• From the official Gentoo Handbook (https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Resuming_an_interrupted_emerge):
  "When an emerge process is interrupted, it is possible to resume it later with the --resume option. When resuming, Portage will re-parse /etc/portage/make.conf and /etc/portage/package.use, but not /etc/portage/package.keywords. This means that any changes to USE flags, ACCEPT_KEYWORDS or other make.conf settings will be applied, but changes to package keywords will not."
• From the Gentoo Portage Features page (https://wiki.gentoo.org/wiki/Portage_Features#Resume_support):
  "When resuming a merge, Portage re-parses /etc/portage/make.conf and some other configuration files in order to determine the correct compilation environment. This means that any changes made to these configuration files will be recognized when the merge is resumed."

Both of these sources indicate that emerge --resume will reload the MAKEOPTS and other variables necessary for package compilation from /etc/make.conf.

Gut, die Quellen kannte ich vorher schon, aber nett, dass es mir die noch mal zusammenfasst. Gehen wir also mal davon aus, dass die Dokumentation richtig ist und portage auch tatsächlich das tut, was dokumentiert wurde. (Man merkt, ich habe mal Informatik studiert und die beiden Aussagen sind nicht immer äquivalent! )

Dann wollen wir mal sehen, was es zu meinem eigentichen Problem zu sagen hat.

Yes, there is a limit to the number of build jobs that can be effectively distributed to other systems using distcc. The limit is primarily determined by the available network bandwidth between the host system and the distcc servers.

When you use distcc to distribute build jobs to other systems, the host system sends the source code and build instructions to the distcc servers, which then compile the code and return the compiled binaries to the host system. This process requires a significant amount of network bandwidth, especially for large packages with many source files.

If you set the -j option in MAKEOPTS too high, the host system may saturate the network connection to the distcc servers, which can lead to slower build times and reduced overall performance. In general, it's recommended to set the -j option in MAKEOPTS to a value that is roughly equal to the number of physical cores on the host system, and then experiment with higher values to see if there is any performance gain.

Another factor that can limit the number of build jobs that can be effectively distributed using distcc is the computational power of the distcc servers themselves. If the distcc servers are significantly slower than the host system, then increasing the number of build jobs may not result in a proportional increase in performance. It's important to ensure that the distcc servers are adequately provisioned with CPU, memory, and disk resources to handle the workload.

In summary, while there is no hard limit to the number of build jobs that can be distributed using distcc, the effective limit is determined by the available network bandwidth and the computational power of the distcc servers. It's important to experiment with different -j values and to ensure that the distcc servers are adequately provisioned for the workload.

Danke, Captain Obvious! Das sollte jetzt alles eigentlich jedem klar sein, der weiß, was ich da versuche. OK, kann es ja nicht wissen, dass ich zumindest ein bisschen Ahung habe, aber ich hab schon distcc benutzt, als dein neuronales Netz noch der feuchte Traum eines KI-Profs war!

Proben wir einfach mal tiefer, mal sehen, ob noch was Vernünftiges dabei raus kommt.

Given that the host has 2 cores and 4 threads available, a good starting point for the -j option in MAKEOPTS would be 4. This will allow the host to utilize all available threads and should provide a good balance between network bandwidth usage and computational resources.

However, since the server has 6 cores and 12 threads available, it may be possible to increase the -j option to a higher value to better utilize the server's resources. It's important to experiment with different values and monitor system performance to find the optimal setting for your particular setup.

Here are a few recommendations for experimenting with the -j option:

• Start with a conservative value for the -j option, such as 4, and monitor system performance during package builds. If you find that the server's CPUs are idle for significant periods of time, you may be able to increase the -j value to better utilize the server's resources.
• Increase the -j value gradually, monitoring system performance after each increase. Keep in mind that increasing the -j value too much can saturate the network connection and lead to slower build times.
• Consider using the --jobs option with emerge to set the number of parallel build jobs for a specific package. This can be useful for packages that are particularly resource-intensive or that require more or less parallelism than the default value set in MAKEOPTS.

Ja, nein. -j4 macht gar keinen Sinn, denn dann nutzt distcc nur die lokalen Kerne und dafür brauche ich das nicht. Also, unter -j16 brauchen wir eigentlich gar nicht anfangen, meiner Meinung nach.

Important to experiment? Was glaubst Du, was ich in den letzten zwei Stunden gemacht habe, hm? Und ja, Deine Tipps sind zwar grundsätzlich korrekt, aber doch ein bisschen oberflächlich. Wo es das her hat, dass man dem emerge direkt ein --jobs mit geben kann? Hat wohl auch dessen Doku gelesen. Das hilft allerdings nur beim Fine Tuning einzelner Pakete, ich will erstmal, dass überhaupt mal alle Kerne ausgelastet werden, zumnindest hin und wieder.

Konfrontiere ich es doch einfach mal mit meinen eigenen Quellen, vielleicht hat es dann ja noch Ideen.

If you've already tried increasing the -j value and you're not seeing a corresponding increase in performance, it's possible that you've hit a bottleneck in your system that is preventing you from fully utilizing all available resources.

Here are a few things you could try:

• Check the CPU usage on the remote distcc servers during a build. If the remote servers are not fully utilized, you may need to increase the -j value even further to better utilize their resources. If the remote servers are fully utilized, however, increasing the -j value further may not help and could actually lead to decreased performance.
• Check the network bandwidth usage during a build. If the network usage is consistently lower than the available bandwidth, you may be able to increase the -j value further without saturating the network. However, if the network usage is already close to or at the maximum bandwidth, increasing the -j value further may not help and could actually lead to decreased performance.
• Check the disk usage during a build. If the build is heavily disk-bound, increasing the number of build jobs may not help and could actually lead to decreased performance due to increased contention for disk I/O. If this is the case, consider upgrading your disk subsystem or optimizing your build process to reduce disk I/O.
• Consider using a different build system, such as Icecream, that may be better suited to your particular setup. Icecream is a distributed build system similar to distcc, but it uses a more sophisticated scheduler that can better balance the workload across multiple machines.

In summary, there may be a bottleneck in your system that is preventing you from fully utilizing all available resources. Check the CPU usage, network bandwidth usage, and disk usage during a build to identify the bottleneck, and consider using a different build system if necessary.

You have hit a bottleneck? Ya think? Was glaubst Du denn, weshalb ich überhaupt mit dir rede? Jesses...

Der Rest ist einfach nur aus irgendeinem Forumsthread abgeschrieben, das sind Dinge, auf die man auch so schon kommen kann und in meinem Fall einfach viel zu allgemein gehalten. Allerdings bietet er mir tatsächlich von sich aus eine Alternative zu distcc an. Dann erzähl mal, Schatz!

Icecream is a distributed build system similar to distcc that allows you to distribute compilation jobs across multiple machines on a network. Like distcc, Icecream allows you to reduce build times by utilizing unused CPU capacity on other machines. However, Icecream offers some additional features and advantages over distcc:

• Load balancing: Icecream uses a more sophisticated scheduler than distcc, which can better balance the workload across multiple machines. This means that Icecream can more efficiently utilize all available resources, even when the available machines have different CPU speeds or memory capacities.
• Compression: Icecream compresses the data that is sent over the network, which can significantly reduce the amount of network bandwidth required. This means that Icecream can work well even over slower or congested networks.
• Zero-configuration setup: Icecream does not require any manual configuration of the build environment. Instead, it automatically discovers other machines on the network that are running the Icecream daemon and begins using them for compilation.
• Prioritization: Icecream allows you to prioritize certain machines over others, which can be useful if you have a mix of fast and slow machines on your network.
• Integration with make: Icecream integrates with the GNU make build system, which means that you can continue to use your existing makefiles without modification.

Overall, Icecream can be a good choice if you have a heterogeneous network with machines of different CPU speeds or memory capacities, or if you want a build system that is easy to set up and use without manual configuration.

OK, klingt ja, als könnte man das tatsächlich als Alternative verwenden. Aber ach:

If you're looking for a stable and reliable distributed build system for Gentoo, you might want to consider using distcc instead of Icecream. Distcc has been around for many years and is well-established, with a large user community and widespread support across many different platforms.

Another option you might consider is using the Gentoo-specific tool called crossdev, which allows you to cross-compile packages for different architectures using a remote machine. This approach is different from using a distributed build system like distcc or Icecream, as it involves compiling packages on one machine for use on another machine with a different architecture.

Finally, you might consider using a cloud-based build service like Google Cloud Build or AWS CodeBuild. These services allow you to spin up virtual machines with custom build environments and perform builds in a highly scalable and distributed manner. This approach can be especially useful if you have highly variable or unpredictable build workloads, as you can easily add or remove build instances as needed to keep up with demand. However, cloud-based build services can be more expensive than running builds on your own hardware, and may require more configuration and setup time.

Really? Du meinst, distcc wäre eine tolle Alternative zu Icecram? Wovon reden wir eigentlich die ganze Zeit? Und ich sag ihm, dass ich eine stabile Umgebung will und es empfiehlt mir die Cloud? Ja, nein, danke, so viel Geld wollte ich jetzt nciht in die Hand nehmen, um nachher nicht zu wissen, wer da alles am Code rum gespielt und rein geguckt und seine AI damit trainiert hat. Fail.