Bagian dari tugas administrator sistem adalah menganalisis kinerja sistem dan menemukan serta menyelesaikan masalah yang menyebabkan kinerja buruk dan waktu mulai yang lama. Sysadmin juga perlu memeriksa aspek lain dari konfigurasi dan penggunaan systemd.
Sistem init systemd menyediakan systemd-analyze alat yang dapat membantu mengungkap masalah kinerja dan informasi sistem penting lainnya. Di artikel sebelumnya, Menganalisis kalender dan rentang waktu sistem , saya menggunakan systemd-analyze untuk menganalisis stempel waktu dan rentang waktu di pengatur waktu systemd, tetapi alat ini memiliki banyak kegunaan lain, beberapa di antaranya akan saya jelajahi dalam artikel ini.
Ikhtisar permulaan
Urutan startup Linux adalah tempat yang baik untuk mulai menjelajah karena banyak systemd-analyze fungsi alat ditargetkan saat startup. Tetapi pertama-tama, penting untuk memahami perbedaan antara boot dan startup. Urutan boot dimulai dengan BIOS power-on self test (POST) dan berakhir ketika kernel selesai memuat dan mengambil kendali dari sistem host, yang merupakan awal dari startup dan titik ketika jurnal systemd dimulai.
Pada artikel kedua dalam seri ini, Memahami systemd saat startup di Linux , saya membahas startup secara lebih mendetail sehubungan dengan apa yang terjadi dan dalam urutan apa. Dalam artikel ini, saya ingin memeriksa urutan startup untuk melihat jumlah waktu yang diperlukan untuk melalui startup dan tugas mana yang paling memakan waktu.
Hasil yang akan saya tunjukkan di bawah ini berasal dari workstation utama saya, yang jauh lebih menarik daripada hasil mesin virtual. Workstation ini terdiri dari motherboard ASUS TUF X299 Mark 2, CPU Intel i9-7960X dengan 16 core dan 32 CPU (thread), dan RAM 64GB. Beberapa perintah di bawah ini dapat dijalankan oleh pengguna non-root, tetapi saya akan menggunakan root dalam artikel ini untuk mencegah keharusan beralih antar pengguna.
Ada beberapa opsi untuk memeriksa urutan startup. Bentuk paling sederhana dari systemd-analyze perintah menampilkan ikhtisar jumlah waktu yang dihabiskan di setiap bagian utama startup, startup kernel, memuat dan menjalankan initrd (yaitu, ramdisk awal, citra sistem sementara yang digunakan untuk menginisialisasi beberapa perangkat keras dan memasang / [root] filesystem), dan userspace (di mana semua program dan daemon yang diperlukan untuk membawa host ke status yang dapat digunakan dimuat). Jika tidak ada sub-perintah yang diteruskan ke perintah, systemd-analyze time tersirat:
[root@david ~]$ systemd-analyze
Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233s
graphical.target reached after 10.071s in userspace
[root@david ~]#
Data yang paling menonjol dalam output ini adalah jumlah waktu yang dihabiskan dalam firmware (BIOS):hampir 54 detik. Ini adalah jumlah waktu yang luar biasa, dan tidak ada sistem fisik saya yang lain yang membutuhkan waktu lama untuk melewati BIOS.
Laptop System76 Oryx Pro saya hanya menghabiskan 8,506 detik di BIOS, dan semua sistem buatan rumah saya membutuhkan waktu kurang dari 10 detik. Setelah beberapa pencarian online, saya menemukan bahwa motherboard ini dikenal dengan waktu booting BIOS yang sangat lama. Motherboard saya tidak pernah "hanya boot." Itu selalu hang, dan saya perlu melakukan siklus mati/hidup, dan kemudian BIOS dimulai dengan kesalahan, dan saya perlu menekan F1 untuk masuk ke konfigurasi BIOS, dari mana saya dapat memilih drive boot dan menyelesaikan boot. Dari sinilah waktu ekstra itu berasal.
Tidak semua host menampilkan data firmware. Eksperimen tidak ilmiah saya membuat saya percaya bahwa data ini hanya ditampilkan untuk prosesor Intel generasi 9 atau lebih tinggi. Tapi itu bisa saja salah.
Ikhtisar proses boot startup ini menarik dan memberikan informasi yang baik (walaupun terbatas), tetapi ada lebih banyak informasi yang tersedia tentang startup, seperti yang akan saya jelaskan di bawah.
Menetapkan kesalahan
Anda dapat menggunakan systemd-analyze blame untuk menemukan unit systemd mana yang membutuhkan waktu paling banyak untuk inisialisasi. Hasilnya ditampilkan secara berurutan berdasarkan jumlah waktu yang diperlukan untuk inisialisasi, dari yang paling banyak hingga yang paling sedikit:
[root@david ~]$ systemd-analyze blame
5.417s NetworkManager-wait-online.service
3.423s dracut-initqueue.service
2.715s systemd-udev-settle.service
2.519s fstrim.service
1.275s udisks2.service
1.271s smartd.service
996ms upower.service
637ms lvm2-monitor.service
533ms lvm2-pvscan@8:17.service
520ms dmraid-activation.service
460ms vboxdrv.service
396ms initrd-switch-root.service
<SNIP – removed lots of entries with increasingly small times>
Karena banyak dari layanan ini dimulai secara paralel, jumlahnya mungkin bertambah jauh lebih banyak daripada total yang diberikan oleh systemd-analyze time untuk semuanya setelah BIOS. Semua ini adalah angka kecil, jadi saya tidak dapat menemukan penghematan yang signifikan di sini.
Data dari perintah ini dapat memberikan indikasi tentang layanan mana yang mungkin Anda pertimbangkan untuk meningkatkan waktu boot. Layanan yang tidak digunakan dapat dinonaktifkan. Tampaknya tidak ada layanan tunggal yang memakan waktu terlalu lama selama urutan startup ini. Anda mungkin melihat hasil yang berbeda untuk setiap boot dan startup.
Rantai kritis
Seperti jalur kritis dalam manajemen proyek, rantai kritis menunjukkan rantai waktu kritis peristiwa yang terjadi selama startup. Ini adalah unit systemd yang ingin Anda lihat jika startup lambat, karena merekalah yang akan menyebabkan penundaan. Alat ini tidak menampilkan semua unit yang dimulai, hanya unit yang berada dalam rangkaian peristiwa penting ini:
[root@david ~]# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @10.071s
└─lxdm.service @10.071s
└─plymouth-quit.service @10.047s +22ms
└─systemd-user-sessions.service @10.031s +7ms
└─remote-fs.target @10.026s
└─remote-fs-pre.target @10.025s
└─nfs-client.target @4.636s
└─gssproxy.service @4.607s +28ms
└─network.target @4.604s
└─NetworkManager.service @4.383s +219ms
└─dbus-broker.service @4.434s +136ms
└─dbus.socket @4.369s
└─sysinit.target @4.354s
└─systemd-update-utmp.service @4.345s +9ms
└─auditd.service @4.301s +42ms
└─systemd-tmpfiles-setup.service @4.254s +42ms
└─import-state.service @4.233s +19ms
└─local-fs.target @4.229s
└─Virtual.mount @4.019s +209ms
└─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s +274ms
└─local-fs-pre.target @3.726s
└─lvm2-monitor.service @356ms +637ms
└─dm-event.socket @319ms
└─-.mount
└─system.slice
└─-.slice
[root@david ~]#
Angka yang diawali dengan @ menunjukkan jumlah detik mutlak sejak startup dimulai saat unit menjadi aktif. Angka yang diawali dengan + tunjukkan jumlah waktu yang dibutuhkan unit untuk memulai.
Status sistem
Terkadang Anda perlu menentukan status sistem saat ini. systemd-analyze dump perintah membuang besar jumlah data tentang status sistem saat ini. Ini dimulai dengan daftar stempel waktu boot utama, daftar setiap unit systemd, dan deskripsi lengkap tentang status masing-masing:
[root@david ~]# systemd-analyze dump
Timestamp firmware: 1min 7.983523s
Timestamp loader: 3.872325s
Timestamp kernel: Wed 2020-08-26 12:33:35 EDT
Timestamp initrd: Wed 2020-08-26 12:33:38 EDT
Timestamp userspace: Wed 2020-08-26 12:33:42 EDT
Timestamp finish: Wed 2020-08-26 16:33:56 EDT
Timestamp security-start: Wed 2020-08-26 12:33:42 EDT
Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT
Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT
Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT
-> Unit system.slice:
Description: System Slice
Instance: n/a
Unit Load State: loaded
Unit Active State: active
State Change Timestamp: Wed 2020-08-26 12:33:38 EDT
Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Exit Timestamp: n/a
Inactive Enter Timestamp: n/a
May GC: no
<SNIP – Deleted a bazillion lines of output>
Di stasiun kerja utama saya, perintah ini menghasilkan aliran 49.680 baris dan sekitar 1,66MB. Perintah ini sangat cepat, jadi Anda tidak perlu menunggu hasilnya.
Lebih banyak sumber daya Linux
- Lembar contekan perintah Linux
- Lembar contekan perintah Linux tingkat lanjut
- Kursus online gratis:Ikhtisar Teknis RHEL
- Lembar contekan jaringan Linux
- Lembar contekan SELinux
- Lembar contekan perintah umum Linux
- Apa itu container Linux?
- Artikel Linux terbaru kami
Saya suka kekayaan detail yang disediakan untuk berbagai perangkat yang terhubung, seperti penyimpanan. Setiap unit systemd memiliki bagian dengan detail seperti mode untuk berbagai runtime, cache, dan direktori log, baris perintah yang digunakan untuk memulai unit, ID proses (PID), stempel waktu mulai, serta batas memori dan file.
Halaman manual untuk systemd-analyze menunjukkan systemd-analyze --user dump opsi, yang dimaksudkan untuk menampilkan informasi tentang keadaan internal manajer pengguna. Ini gagal untuk saya, dan pencarian internet menunjukkan bahwa mungkin ada masalah dengannya. Di systemd, --user instance digunakan untuk mengelola dan mengontrol sumber daya untuk hierarki proses milik setiap pengguna. Proses untuk setiap pengguna adalah bagian dari grup kontrol, yang akan saya bahas di artikel mendatang.
Grafik analitik
Kebanyakan bos berambut runcing (PHB) dan banyak manajer yang baik menemukan grafik yang cantik lebih mudah dibaca dan dipahami daripada data kinerja sistem berbasis teks yang biasanya saya sukai. Namun, terkadang saya menyukai grafik yang bagus, dan systemd-analyze menyediakan kemampuan untuk menampilkan data boot/startup dalam grafik grafik vektor SVG.
Perintah berikut menghasilkan file grafik vektor yang menampilkan peristiwa yang terjadi selama boot dan startup. Hanya perlu beberapa detik untuk menghasilkan file ini:
[root@david ~]# systemd-analyze plot > /tmp/bootup.svgPerintah ini membuat SVG, yang merupakan file teks yang mendefinisikan serangkaian vektor grafik yang digunakan aplikasi, termasuk Penampil Gambar, Ristretto, Okular, Eye of Mate, LibreOffice Draw, dan lainnya, untuk menghasilkan grafik. Aplikasi ini memproses file SVG untuk membuat gambar.
Saya menggunakan LibreOffice Draw untuk membuat grafik. Grafiknya sangat besar, dan Anda perlu memperbesar untuk melihat detail apa pun. Ini sebagian kecilnya:
Urutan boot-up berada di sebelah kiri nol (0) pada garis waktu dalam grafik, dan urutan startup berada di sebelah kanan nol. Bagian kecil ini menunjukkan kernel, initrd , dan proses initrd dimulai.
Grafik ini menunjukkan sekilas apa yang dimulai kapan, berapa lama waktu yang dibutuhkan untuk memulai, dan dependensi utama. Jalur kritis disorot dengan warna merah.
Perintah lain yang menghasilkan output grafis adalah systemd-analyze plot . Ini menghasilkan deskripsi grafik ketergantungan tekstual dalam format DOT. Aliran data yang dihasilkan kemudian disalurkan melalui dot utilitas, yang merupakan bagian dari keluarga program yang dapat digunakan untuk menghasilkan file grafik vektor dari berbagai jenis data. File SVG ini juga dapat diproses oleh alat yang tercantum di atas.
Pertama, buat file . Ini memakan waktu hampir sembilan menit di stasiun kerja utama saya:
[root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg
Color legend: black = Requires
dark blue = Requisite
dark grey = Wants
red = Conflicts
green = After
real 8m37.544s
user 8m35.375s
sys 0m0.070s
[root@david ~]#
Saya tidak akan mereproduksi output di sini karena grafik yang dihasilkan cukup banyak spageti. Tetapi Anda harus mencobanya dan melihat hasilnya untuk melihat apa yang saya maksud.
Ketentuan
Salah satu kemampuan yang lebih menarik, namun agak umum, yang saya temukan saat membaca systemd-analyze(1) halaman manual adalah condition sub-perintah. (Ya—saya memang membaca halaman manual, dan sungguh menakjubkan apa yang telah saya pelajari dengan cara ini!) condition ini subcommand dapat digunakan untuk menguji kondisi dan pernyataan yang dapat digunakan dalam file unit systemd.
Ini juga dapat digunakan dalam skrip untuk mengevaluasi satu atau lebih kondisi—ini mengembalikan nol (0) jika semua terpenuhi atau satu (1) jika ada kondisi yang tidak terpenuhi. Dalam kedua kasus, itu juga memuntahkan teks tentang temuannya.
Contoh di bawah, dari halaman manual, agak rumit. Ini menguji versi kernel antara 4.0 dan 5.1, bahwa host berjalan pada daya AC, bahwa arsitektur sistem tidak lain adalah ARM, dan bahwa direktori /etc/os-release ada. Saya menambahkan echo $? pernyataan untuk mencetak kode pengembalian.
[root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release' ; \
echo $?
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
0
[root@david ~]#
Daftar kondisi dan pernyataan dimulai sekitar baris 600 pada systemd.unit(5) halaman manual.
Mendaftarkan file konfigurasi
systemd-analyze alat menyediakan cara untuk mengirim konten berbagai file konfigurasi ke STDOUT , seperti yang ditunjukkan di sini. Direktori dasarnya adalah /etc/ :
[root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service
# /etc/systemd/system/display-manager.service
[Unit]
Description=LXDM (Lightweight X11 Display Manager)
#Documentation=man:lxdm(8)
[email protected]
After=systemd-user-sessions.service [email protected] plymouth-quit.service livesys-late.service
#Conflicts=plymouth-quit.service
[Service]
ExecStart=/usr/sbin/lxdm
Restart=always
IgnoreSIGPIPE=no
#BusName=org.freedesktop.lxdm
[Install]
Alias=display-manager.service
[root@david ~]#
Ini banyak mengetik untuk melakukan tidak lebih dari cat standar perintah tidak. Saya menemukan perintah selanjutnya sedikit membantu. Itu dapat mencari file dengan pola yang ditentukan dalam lokasi systemd standar:
[root@david ~]# systemctl cat backup*
# /etc/systemd/system/backup.timer
# This timer unit runs the local backup program
# (C) David Both
# Licensed under GPL V2
#
[Unit]
Description=Perform system backups
Requires=backup.service
[Timer]
Unit=backup.service
OnCalendar=*-*-* 00:15:30
[Install]
WantedBy=timers.target
# /etc/systemd/system/backup.service
# This service unit runs the rsbu backup program
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Backup services using rsbu
Wants=backup.timer
[Service]
Type=oneshot
Environment="HOME=/root"
ExecStart=/usr/local/bin/rsbu -bvd1
ExecStart=/usr/local/bin/rsbu -buvd2
[Install]
WantedBy=multi-user.target
[root@david ~]#
Kedua perintah ini mengawali isi setiap file dengan baris komentar yang berisi path lengkap dan nama file.
Verifikasi file unit
Setelah membuat file unit baru, akan sangat membantu untuk memverifikasi bahwa sintaksnya benar. Inilah yang verify sub-perintah tidak. Itu dapat mencantumkan arahan yang dieja dengan salah dan memanggil unit layanan yang hilang:
[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.serviceMengikuti filosofi Unix/Linux bahwa "diam adalah emas", kurangnya pesan keluaran berarti tidak ada kesalahan dalam file yang dipindai.
Keamanan
security subcommand memeriksa tingkat keamanan layanan tertentu. Ini hanya berfungsi pada unit layanan dan tidak pada jenis file unit lainnya:
[root@david ~]# systemd-analyze security display-manager
NAME DESCRIPTION >
✗ PrivateNetwork= Service has access to the host's network >
✗ User=/DynamicUser= Service runs as root user >
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities >
✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges >
✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities >
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets >
✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces >
✗ RestrictAddressFamilies=~… Service may allocate exotic sockets >
✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres>
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks >
✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges >
✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules
<SNIP>
✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() >
✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system >
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets >
→ Overall exposure level for backup.service: 9.6 UNSAFE ?
lines 34-81/81 (END)
Ya, emoji adalah bagian dari output. Namun, tentu saja, banyak layanan membutuhkan akses yang cukup lengkap ke segala sesuatu untuk melakukan pekerjaan mereka. Saya menjalankan program ini terhadap beberapa layanan, termasuk layanan cadangan saya sendiri; hasilnya mungkin berbeda, tetapi intinya tampaknya sebagian besar sama.
Alat ini akan sangat berguna untuk memeriksa dan memperbaiki unit layanan ruang pengguna di lingkungan yang kritis terhadap keamanan. Saya tidak berpikir itu memiliki banyak hal untuk ditawarkan bagi kebanyakan dari kita.
Pemikiran terakhir
Alat canggih ini menawarkan beberapa opsi yang menarik dan sangat berguna. Sebagian besar dari apa yang dieksplorasi artikel ini adalah tentang menggunakan systemd-analyze untuk memberikan wawasan tentang kinerja startup Linux menggunakan systemd. Itu juga dapat menganalisis aspek lain dari systemd.
Beberapa dari alat ini penggunaannya terbatas, dan beberapa harus dilupakan sepenuhnya. Tetapi sebagian besar dapat digunakan untuk efek yang baik saat menyelesaikan masalah dengan startup dan fungsi systemd lainnya.
Sumber daya
Ada banyak informasi tentang systemd yang tersedia di internet, tetapi banyak yang singkat, tumpul, atau bahkan menyesatkan. Selain sumber daya yang disebutkan dalam artikel ini, halaman web berikut menawarkan informasi yang lebih detail dan andal tentang startup systemd. Daftar ini telah berkembang sejak saya memulai rangkaian artikel ini untuk mencerminkan penelitian yang telah saya lakukan.
- Halaman manual systemd.unit(5) berisi daftar bagian file unit yang bagus dan opsi konfigurasinya bersama dengan deskripsi singkat masing-masing.
- Proyek Fedora memiliki panduan praktis yang baik untuk systemd. Ini memiliki hampir semua yang perlu Anda ketahui untuk mengonfigurasi, mengelola, dan memelihara komputer Fedora menggunakan systemd.
- Proyek Fedora juga memiliki lembar contekan bagus yang merujuk silang perintah SystemV lama ke perintah systemd yang sebanding.
- Dokumentasi Red Hat berisi deskripsi yang baik tentang struktur file Unit serta informasi penting lainnya.
- Untuk informasi teknis terperinci tentang systemd dan alasan pembuatannya, lihat deskripsi Freedesktop.org tentang systemd.
- "Lebih banyak sistem menyenangkan" dari Linux.com menawarkan informasi dan tips sistem yang lebih canggih.
Ada juga serangkaian artikel yang sangat teknis untuk sysadmin Linux oleh Lennart Poettering, perancang dan pengembang utama systemd. Artikel-artikel ini ditulis antara April 2010 dan September 2011, tetapi masih relevan sekarang seperti dulu. Banyak hal bagus lainnya yang telah ditulis tentang systemd dan ekosistemnya didasarkan pada makalah ini.
- Memikirkan kembali PID 1
- systemd untuk Administrator, Bagian I
- systemd untuk Administrator, Bagian II
- systemd untuk Administrator, Bagian III
- systemd untuk Administrator, Bagian IV
- systemd untuk Administrator, Bagian V
- systemd untuk Administrator, Bagian VI
- systemd untuk Administrator, Bagian VII
- systemd untuk Administrator, Bagian VIII
- systemd untuk Administrator, Bagian IX
- systemd untuk Administrator, Bagian X
- systemd untuk Administrator, Bagian XI