| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| wiki:system_configuration [2021/03/01 21:29] – [sysctl.conf] autostatic | wiki:system_configuration [2021/03/05 12:52] – [Disabling resource-intensive daemons, services and processes] autostatic |
|---|
| |
| You could also add a line to your ''/etc/rc.local'' file for instance to set the governor to //performance// at boot time: | You could also add a line to your ''/etc/rc.local'' file for instance to set the governor to //performance// at boot time: |
| echo -n performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor |
| | |
| | Another option is to create a Systemd Unit that does this for you. Example of an audio-setup Unit file: |
| | [Unit] |
| | Description=Prepare system for audio |
| | |
| | [Service] |
| | Type=oneshot |
| | ExecStart=/usr/local/bin/audio-setup |
| | RemainAfterExit=yes |
| | |
| | [Install] |
| | WantedBy=multi-user.target |
| | |
| | This will start ''/usr/local/bin/audio-setup'' at boot so you can add the aformentioned line regarding setting the CPU's to the //performance// scaling governor there, make the file executable, enable the Systemd service and start it. |
| | echo 'echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor' | sudo tee /usr/local/bin/audio-setup |
| | sudo chmod +x /usr/local/bin/audio-setup |
| | sudo systemctl enable audio-setup |
| | sudo systemctl start audio-setup |
| | |
| | The ''audio-setup'' script could then also be used to set up other things. |
| |
| == Ubuntu == | == Ubuntu == |
| |
| On Ubuntu systems the command in your ''/etc/rc.local'' file only works if you disable the ondemand service: | On Ubuntu systems the command in your ''/etc/rc.local'' or ''/usr/local/bin/audio-setup'' file only works if you disable the ondemand service: |
| sudo update-rc.d ondemand disable | sudo systemctl mask ondemand.service |
| | |
| Another option would be to modify the ''ondemand'' init script and rename it to ''performance'': | |
| sudo sed -i 's/ondemand/performance/g' /etc/init.d/ondemand | |
| sudo update-rc.d ondemand disable | |
| sudo cp /etc/init.d/ondemand /etc/init.d/performance | |
| sudo update-rc.d performance defaults | |
| |
| == Debian == | == Debian == |
| This setting changes the so-called swappiness of your system, or in other words, the moment when your system starts to use its swap partition. You can check the current value with ''cat /proc/sys/vm/swappiness'', in most cases it is set to 60. This is too high, it will make your system start using swap too fast which might influence the overall performance. | This setting changes the so-called swappiness of your system, or in other words, the moment when your system starts to use its swap partition. You can check the current value with ''cat /proc/sys/vm/swappiness'', in most cases it is set to 60. This is too high, it will make your system start using swap too fast which might influence the overall performance. |
| |
| There are references on the net on adjusting the ''fs.inotify.max_user_watches'' value also for enhanced performance. The ''max_user_watches'' parameter sets the maximum number of files your system can monitor with inotify (which is part of the kernel) for changes. Setting this parameter too low results in inotify failing. Setting it too high can make inotify needlessly consume memory. The advise of increasing this value might originate from for example DAW's or samplers that watch a lot of files and if the system runs out of watchers these DAW's or samplers fall back to polling the file system which increases disk IO which could in turn cause jitter. And since modern systems have mostly enough memory these days increasing this value should cause no issues. | There are references on the net on adjusting the ''fs.inotify.max_user_watches'' value also for enhanced performance. The ''max_user_watches'' parameter sets the maximum number of files your system can monitor with inotify (which is part of the kernel) for changes. Setting this parameter too low results in inotify failing. Setting it too high can make inotify needlessly consume memory. The advise of increasing this value might originate from for example DAW's or samplers that watch a lot of files and if the system runs out of watchers these DAW's or samplers fall back to polling the file system which increases disk IO which could in turn cause jitter((https://linuxmusicians.com/viewtopic.php?p=129194#p129194)). And since modern systems have mostly enough memory these days increasing this value should cause no issues. |
| |
| ==== audio group ==== | ==== audio group ==== |
