Questa è la traduzione di un recente articolo di Lennart Poettering, creatore e sviluppatore di Systemd.

systemd può già offrire tempi di avvio inferiori ai 2s in computer portatili (ma moderni, ad esempio con SSD) con ambienti desktop aggiornati se configurato correttamente (esempio: http://git.fenrus.org/tmp/bootchart-20120512-1036.svg).
In questa pagina vogliamo suggerire un paio di idee su come raggiungere tale ottimizzazione e se i tempi di avvio risultanti non sono sufficienti come noi crediamo, ci sono margini di miglioramento, che in futuro ci piacerebbe vedere implementati. Se siete interessati ad investire in risorse umane di ingegneria per systemd in modo da raggiungere tempi di avvio più brevi, questo elenco comprende qualche suggerimento buono per iniziare.

...

Si noti che le prestazioni veloci di systemd sono un aspetto secondario, non l'obiettivo primario di progettazione. Allo stato attuale systemd (e Fedora) è stato ottimizzato molto poco ed è potenzialmente migliorabile.

Siamo molto interessati a far confluire il lavoro di ottimizzazione in systemd a monte. Si noti comunque che non siamo concentrati a limitare drasticamente l'utilità generale o l'affidabilità del nostro codice che farebbero systemd più difficile da mantenere.

Le distribuzioni hanno adottato systemd a diversi livelli. Mentre ci sono molti script di compatibilità del processo d'avvio per esempio su Debian, in Fedora ce ne sono molti meno (ma sempre troppi). Per migliorare le prestazioni disabilitare questi script o usare una diversa distribuzione.

E' nostra intenzione ottimizzare le distribuzioni a monte di default (in particolare in Fedora) in modo che queste ottimizzazioni non saranno più necessarie. Tuttavia per questo ci vorrà del tempo, soprattutto perché fare questi cambiamenti spesso non è banale quando l'utilità in generale non può essere compromessa.

Che cosa si può ottimizzare (in loco) senza scrivere alcun codice:

1.     Assicurarsi di non utilizzare alcun dispositivo di immagazzinamento come LVM (installato per impostazione predefinita in varie distribuzioni, tra cui Fedora) in quanto systemd-udev-settle.service verrà tirato dentro all'avvìo. Il settling è lento e soprattutto obsoleto.
2.     Dal momento che LVM (ancora) non è stato aggiornato per gestire udev basato su Linux, la settling device enumeration delle periferiche è ancora necessaria, ma rallenterà l'avvio sostanzialmente. In Fedora, usare systemctl mask fedora-wait-storage.service fedora-storage-init-late.service fedora-storage-init.service per sbarazzarsi di tutte quelle tecnologie di storage. Naturalmente, non provateci se LVM è effettivamente installato. (L'unica tecnologia di archiviazione che attualmente gestisce tutto questo correttamente e non necessita della settling device enumeration è la cifratura del disco LUKS.)
3.  Considerare il bypass di initrd, se ne utilizza uno. In Fedora, assicurarsi di installare il sistema operativo su un disco normale senza crittografia e senza LVM/RAID/... (Cifrare la /home va bene). Quindi è sufficiente modificare grub.conf e rimuovere l'initrd dalla configurazione, modificare il parametro root= del kernel in modo che utilizzi i nomi dei dispositivi del kernel invece degli UUID, cioé root=/dev/sda5 ad esempio o ciò che è appropriato per il sistema. Inoltre specificare il tipo di filesystem di root ad esempio rootfstype=ext4. Si noti che l'uso dei nomi kernel dei dispositivi potrebbe non essere corretto se si dispone di più dischi rigidi, ma se si sta usando un portatile (cioè con un hdd singolo), dovrebbe andare bene. Si noti che non dovrebbe essere necessario ricompilare il kernel in modo da bypassare initrd. I kernel delle distribuzioni (almeno quelli di Fedora) funzionano bene con e senza initrd, e systemd supporta entrambe le modalità di avvio.
4.     Considerate la disabilitazione di SELinux. Si consiglia di tenerlo abilitato per ragioni di sicurezza, anche se a dire la verità è possibile salvare 100ms del vostro boot.
5.     Considerate la disabilitazione di Plymouth. Se lo userspace (lo spazio utente) parte in meno di 2s, un bootsplash di avvio è poco utile, quindi prendere in considerazione l'uso dell'opzione plymouth.enable=0 sulla riga di comando del kernel. Plymouth è in genere abbastanza veloce, ma al momento forza ancora l'enumerazione dei dispositivi per le schede grafiche, rallentando.
6.     Considerate la disabilitazione del syslog. Il journal è comunque utilizzato sui nuovi sistemi systemd e di solito è più che sufficiente per i desktop, gli embedded e anche molti server. Basta disinstallare tutte le implementazioni syslog e ricordate che journalctl otterrà una copia perfetta di /var/log/messagges. Per rendere il journal log persistente (per non perderli durante il boot) assicurarsi di eseguire mkdir-p /var/log/journal
7.     Si consideri il mask di un paio di script di avvio ridondanti di distribuzione, che artificialmente rallentano il boot. Ad esempio, su Fedora è una buona idea mascherare fedora-autoswap.service fedora-configure.service fedora-loadmodules.service fedora-readonly.service. Inoltre rimuovere tutti i pacchetti LVM/RAID/FCoE/iSCSI collegati che rallentano l'avvio o almeno mascherarne i rispettivi servizi.
8.  L'output della console è lento. Quindi assicurarsi di utilizzare quiet sulla riga di comando e di disabilitare la registrazione systemd debug (se abilitata prima).
9.     Provare a rimuovere cron dal sistema ed usare invece le unità timer systemd. Le Unit Timer al momento non hanno il supporto per i tempi del calendario, ma per i soliti /etc/cron.daily/, /etc/cron.weekly/, ... dovrebbe essere abbastanza buono, se l'ora del giorno dell'esecuzione non importa (basta aggiungere quattro servizio di piccole dimensioni e le unità di timer per sostenere questi dirs. Alla fine potremmo sostenere questi out of the box, ma fino ad allora, basta scrivere le proprie scriplets per questo).
10.     Se si lavora su un dispositivo, disabilitare la readahead collection, ma lasciare il replay readahead abilitato.
11.     Se si lavora su un dispositivo, assicurarsi di compilare tutti i driver necessari nel kernel, in quanto il caricamento del modulo è lento.
12.     Se funziona, utilizzare libahci.ignore_sss=1 all'avvio.
13.     Usare un desktop moderno. Per esempio GNOME 3,4.
14.     Sbarazzarsi di MTA locali, se si sta costruendo un desktop. Su Fedora togliere gli RPM sendmail che sono (ancora!) installati di default.
15.     Se si sta creando un apparecchio, non dimenticate che i vari componenti di systemd sono opzionali e possono essere disattivati ​​durante la compilazione, vedere "./configure --help" per i dettagli. Ad esempio, sbarazzarsi del setup della console virtuale (questa è una delle principali fonti di lentezza, in realtà). Inoltre, se non si dispone di utenti locali del tutto, prendere in considerazione la disattivazione di logind. E ci sono altre componenti spesso inutili.
16.     Va da sé: il boot-up diventa più veloce se è stato avviata meno roba all'avvio. Quindi eseguire systemctl e controllare se c'è roba non necessaria e disattivarla o addirittura rimuovere il suo pacchetto.
17.     Non usare il kernel debug in quanto lenti. Fedora utilizza esclusivamente i kernel debug durante la fase di sviluppo di ogni release. Se vi preoccupate per le prestazioni di avvio, ricompilare i kernel con il debug disattivato o attendere il rilascio della distribuzione finale. Ciò significa anche che se si pubblicano i dati di performance di avvio di una pre-release della distribuzione Fedora stai facendo qualcosa di sbagliato.

Documento originale: systemd Optimizations