diff --git a/documentation/content/de/books/handbook/dtrace/_index.adoc b/documentation/content/de/books/handbook/dtrace/_index.adoc index 4b3c0c7237..ebbc6f46a1 100644 --- a/documentation/content/de/books/handbook/dtrace/_index.adoc +++ b/documentation/content/de/books/handbook/dtrace/_index.adoc @@ -1,240 +1,240 @@ --- title: Kapitel 24. DTrace part: Teil III. Systemadministration prev: books/handbook/cutting-edge next: books/handbook/usb-device-mode showBookMenu: true weight: 28 path: "/books/handbook/dtrace/" --- [[dtrace]] = DTrace :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 24 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/dtrace/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[dtrace-synopsis]] == Überblick DTrace, auch bekannt als Dynamic Tracing, wurde von Sun(TM) als ein Werkzeug zur Analyse von Performance-Problemen in Produktiv- und Entwicklungssystemen entwickelt. Zusätzlich zur Diagnose von Performance-Problemen kann DTrace auch verwendet werden, um bei der Untersuchung und Behebung von unerwartetem Verhalten im FreeBSD-Kernel und den Anwenderprogrammen zu helfen. DTrace ist ein bemerkenswertes Werkzeug zur Profilerstellung, mit einer beeindruckenden Palette von Eigenschaften zur Diagnose von Systemereignissen. Es kann auch dazu verwendet werden, bestehende Skripte ablaufen zu lassen, um einen Nutzen aus deren Möglichkeiten zu ziehen. Nutzer können mittels der Programmiersprache D von DTrace ihre eigenen Hilfsmittel schreiben, was es ermöglicht, die eigenen Profile nach Ihren Bedürfnissen anzupassen. Die DTrace-Implementierung in FreeBSD bietet experimentelle Unterstützung für DTrace im Userland. Userland DTrace erlaubt es Anwendern, function boundary tracing für Anwendungsprogramme über den `pid`-Provider hinweg vorzunehmen und um statische Sonden in Anwendungsprogramme für die spätere Aufzeichnung einzufügen. Manche Ports, wie beispielsweise package:databases/postgresql12-server[] und package:lang/php74[] besitzen eine DTrace-Option, um statische Sonden zu aktivieren. -Eine offizielle Anleitung für DTrace wird vom Illumos Projekt im http://dtrace.org/guide[DTrace Guide] bereitgestellt. +Eine offizielle Anleitung für DTrace wird vom Illumos Projekt im https://illumos.org/books/dtrace/bookinfo.html[DTrace Guide] bereitgestellt. Nachdem Sie dieses Kapitel gelesen haben, werden Sie Folgendes wissen: * Was DTrace ist und welche Funktionen es zur Verfügung stellt. * Unterschiede zwischen der Solaris(TM) DTrace Implementierung und derjenigen, die FreeBSD bereitstellt. * Wie man DTrace auf FreeBSD aktiviert und verwendet. Bevor Sie dieses Kapitel lesen, sollten Sie: * UNIX(R) und FreeBSD Grundlagen verstehen (crossref:basics[basics,Grundlagen des FreeBSD Betriebssystems]). * Vertraut sein mit Sicherheitsaspekten und wie diese FreeBSD betreffen (crossref:security[security,Sicherheit]). [WARNING] ==== Diese Funktion ist als experimentell anzusehen. Manche Einstellungen enthalten möglicherweise nicht alle Funktionalitäten, andere Teile könnten gar nicht laufen. Mit der Zeit, wenn diese Funktion als für den Produktivbetrieb geeignet erscheint, wird auch diese Dokumentation geändert, um diesem Umstand gerecht zu werden. ==== [[dtrace-implementation]] == Unterschiede in der Implementierung Obwohl DTrace in FreeBSD sehr ähnlich zu dem in Solaris(TM) ist, existieren doch Unterschiede. Der Hauptunterschied besteht darin, dass in FreeBSD DTrace als eine Menge von Kernelmodulen implementiert ist und DTrace nicht verwendet werden kann, bis diese Module geladen wurden. Um alle nötigen Module zu laden, geben Sie ein: [source,shell] .... # kldload dtraceall .... Beginnend mit FreeBSD 10.0-RELEASE werden die Module automatisch geladen, sobald `dtrace` aufgerufen wird. FreeBSD verwendet die Kerneloption `DDB_CTF`, um die Unterstützung im Kernel für das Laden von CTF-Daten aus Kernelmodulen und dem Kernel selbst zu ermöglichen. CTF ist das Compact C Type Format von Solaris(TM), welches eine reduzierte Form von Debug-Informationen kapselt, ähnlich zu DWARF und den antiken Stabs. Diese CTF-Daten werden dem Binärcode von den `ctfconvert` und `ctfmerge` Befehlen den Werkzeugen zum Bauen des Systems hinzugefügt. Das `ctfconvert`-Dienstprogramm parst die vom Compiler erstellten DWARFELF Debug-Abschnitte und `ctfmerge` vereint CTFELF-Abschnitte aus Objekten, entweder in ausführbare Dateien oder Shared-Libraries. Einige Provider in FreeBSD unterscheiden sich von der Solaris(TM)-Implementierung. Am deutlichsten wird das beim `dtmalloc`-Provider, welcher das Aufzeichnen von `malloc()` nach Typen im FreeBSD-Kernel ermöglicht. Manche der Provider in Solaris(TM) wie `cpc` und `mib` sind in FreeBSD nicht vorhanden. Diese können in zukünftigen FreeBSD-Versionen auftauchen. Weiterhin sind manche der Provider in beiden Betriebssystemen nicht zueinander kompatibel, in dem Sinne daß deren Sonden unterschiedliche Argumenttypen aufweisen. Dadurch können D-Skripte, die unter Solaris(TM) geschrieben wurden, evtl. unter FreeBSD funktionieren oder auch nicht, umgekehrt ist das genauso. In FreeBSD darf DTrace wegen unterschiedlicher Sicherheitskonzepte nur von `root` verwendet werden. Solaris(TM) besitzt ein paar Audit-Funktionen auf den unteren Ebenen, die noch nicht in FreeBSD implementiert sind. Deshalb kann nur `root` auf [.filename]#/dev/dtrace/dtrace# zugreifen. Zum Schluss muss noch erwähnt werden, dass die DTrace-Software unter die CDDL Lizenz fällt. Die `Common Development and Distribution License` wird von FreeBSD mitgeliefert, sehen Sie sich dazu [.filename]#/usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE# an, oder lesen Sie die Online-Version unter http://opensource.org/licenses/CDDL-1.0[http://opensource.org/licenses/CDDL-1.0]. Während der FreeBSD-Kernel mit den DTrace-Optionen immer noch BSD-lizenziert ist, tritt die CDDL in Kraft, wenn Module in Binärform vertrieben werden oder die Binärdateien geladen werden. [[dtrace-enable]] == Die DTrace Unterstützung aktivieren In FreeBSD 9.2 und 10.0 ist die Unterstützung von DTrace im [.filename]#GENERIC#-Kernel bereits eingebaut. Nutzer von früheren Versionen sollten die folgenden Zeilen in eine eigene Kernelkonfigurationsdatei einfügen und den Kernel mittels der Anleitung in crossref:kernelconfig[kernelconfig,Konfiguration des FreeBSD-Kernels] neu übersetzen: [.programlisting] .... options KDTRACE_HOOKS options DDB_CTF makeoptions DEBUG=-g makeoptions WITH_CTF=1 .... Besitzer der AMD64-Architektur werden wahrscheinlich noch die folgende Zeile zur Kernelkonfigurationsdatei hinzufügen: [.programlisting] .... options KDTRACE_FRAME .... Diese Option liefert die Unterstützung für die FBT-Eigenschaft. DTrace wird auch ohne diese Option funktionieren; jedoch wird dann Function Boundary Tracing nur eingeschränkt unterstützt. Sobald FreeBSD in den neuen Kernel gebootet oder die DTrace-Kernelmodule mittels `kldload dtraceall` geladen wurden, benötigt das System Unterstützung für die Korn-Shell, da DTrace mehrere Dienstprogramme enthält, die in `ksh` implementiert sind. Vergewissern Sie sich, dass das Paket oder der Port package:shells/ksh93[] installiert ist. Es ist auch möglich, diese Werkzeuge unter package:shells/pdksh[] oder package:shells/mksh[] laufen zu lassen. Zum Schluss sollten Sie noch den aktuellen DTrace-Werkzeugsatz beschaffen. Die DTrace-Werkzeugsammlung enthält gebrauchsfertige Skripte, um Systeminformationen zu sammeln. Es gibt Skripte zum Überprüfen von offenen Dateien, Speicher- und CPU-Gebrauch und noch viel mehr. FreeBSD 10 installiert ein paar dieser Skripte in [.filename]#/usr/shared/dtrace#. Für andere FreeBSD-Versionen oder um die volle DTrace-Werkzeugsammlung zu installieren, verwenden Sie den package:sysutils/dtrace-toolkit[] Port oder das Paket. [NOTE] ==== Die Skripte in [.filename]#/usr/shared/dtrace# wurden speziell für FreeBSD portiert. Nicht alle Skripte in der DTrace-Werkzeugsammlung werden in FreeBSD unverändert funktionieren und manche Skript benötigen einigen Aufwand, damit diese auf FreeBSD funktionieren. ==== Der DTrace-Werkzeugsatz beinhaltet viele Skripte in der speziellen Sprache von DTrace. Diese Sprache wird die D-Sprache genannt und ist sehr ähnlich zu C++. Eine detaillierte Beschreibung dieser Sprache würde den Rahmen dieses Dokuments sprengen. Im http://www.dtrace.org/guide[Illumos Dynamic Tracing Guide] wird diese Sprache ausführlich beschrieben. [[dtrace-using]] == DTrace verwenden DTrace-Skripte bestehen aus einer Liste von einer oder mehreren _Sonden_ oder Instrumentationspunkten, an denen jede Sonde mit einer Aktion verknüpft ist. Jedesmal, wenn die Bedingung für eine Sonde zutrifft, wird die verknüpfte Aktion ausgeführt. Beispielsweise könnte eine Aktion ausgeführt werden, wenn eine Datei geöffnet, ein Prozess gestartet oder eine Codezeile ausgeführt wird. Die Aktion könnte die Protokollierung von Informationen sein oder die Änderung von Kontextvariablen. Das Lesen und Schreiben von Kontextvariablen erlaubt es den Sonden, Informationen auszutauschen und kooperativ die Korrelation bestimmter Ereignisse zu analysieren. Um alle Sonden anzuzeigen, kann der Administrator nun den folgenden Befehl eingeben: [source,shell] .... # dtrace -l | more .... Jede Sonde besitzt eine `ID`, einen `PROVIDER` (dtrace oder fbt), ein `MODULE` und einen `FUNCTION NAME`. Lesen Sie man:dtrace[1] für weitere Informationen zu diesem Kommando. Die Beispiele in diesem Abschnitt geben einen Überblick, wie man zwei dieser voll funktionsfähigen Skripte aus der DTrace-Werkzeugsammlung verwendet: die Skripte [.filename]#hotkernel# und [.filename]#procsystime#. Das [.filename]#hotkernel# Skript wurde entworfen, um zu identifizieren, welche Funktion die meiste Kernelzeit beansprucht. Es wird es Ausgaben ähnlich der Folgenden produzieren: [source,shell] .... # cd /usr/local/share/dtrace-toolkit # ./hotkernel Sampling... Hit Ctrl-C to end. .... Verwenden Sie wie angegeben die Tastenkombination kbd:[Ctrl+C] drücken, um den Prozess zu stoppen. Nach dem Abbruch wird das Skript eine Liste von Kernelfunktionen und Zeitmessungen ausgeben, aufsteigend sortiert nach den Zeiten: [source,shell] .... kernel`_thread_lock_flags 2 0.0% 0xc1097063 2 0.0% kernel`sched_userret 2 0.0% kernel`kern_select 2 0.0% kernel`generic_copyin 3 0.0% kernel`_mtx_assert 3 0.0% kernel`vm_fault 3 0.0% kernel`sopoll_generic 3 0.0% kernel`fixup_filename 4 0.0% kernel`_isitmyx 4 0.0% kernel`find_instance 4 0.0% kernel`_mtx_unlock_flags 5 0.0% kernel`syscall 5 0.0% kernel`DELAY 5 0.0% 0xc108a253 6 0.0% kernel`witness_lock 7 0.0% kernel`read_aux_data_no_wait 7 0.0% kernel`Xint0x80_syscall 7 0.0% kernel`witness_checkorder 7 0.0% kernel`sse2_pagezero 8 0.0% kernel`strncmp 9 0.0% kernel`spinlock_exit 10 0.0% kernel`_mtx_lock_flags 11 0.0% kernel`witness_unlock 15 0.0% kernel`sched_idletd 137 0.3% 0xc10981a5 42139 99.3% .... Dieses Skript funktioniert auch mit Kernelmodulen. Um diese Eigenschaft zu verwenden, starten Sie das Skript mit `-m`: [source,shell] .... # ./hotkernel -m Sampling... Hit Ctrl-C to end. ^C MODULE COUNT PCNT 0xc107882e 1 0.0% 0xc10e6aa4 1 0.0% 0xc1076983 1 0.0% 0xc109708a 1 0.0% 0xc1075a5d 1 0.0% 0xc1077325 1 0.0% 0xc108a245 1 0.0% 0xc107730d 1 0.0% 0xc1097063 2 0.0% 0xc108a253 73 0.0% kernel 874 0.4% 0xc10981a5 213781 99.6% .... Das [.filename]#procsystime# Skript fängt die Systemaufruf-Zeiten für eine gegebene Prozess-ID (PID) oder einen Prozessnamen ab und gibt diese aus. Im folgenden Beispiel wurde eine neue Instanz von [.filename]#/bin/csh# erzeugt. Dann wurde [.filename]#procsystime# ausgeführt und verbleibt so, während ein paar Befehle in die andere Instanz von `csh` eingegeben werden. Dies sind die Ergebnisse dieses Versuchs: [source,shell] .... # ./procsystime -n csh Tracing... Hit Ctrl-C to end... ^C Elapsed Times for processes csh, SYSCALL TIME (ns) getpid 6131 sigreturn 8121 close 19127 fcntl 19959 dup 26955 setpgid 28070 stat 31899 setitimer 40938 wait4 62717 sigaction 67372 sigprocmask 119091 gettimeofday 183710 write 263242 execve 492547 ioctl 770073 vfork 3258923 sigsuspend 6985124 read 3988049784 .... Wie aus der Ausgabe ersichtlich ist, verbraucht der `read()`-Systemaufruf die meiste Zeit in Nanosekunden, während der Systemaufruf `getpid()` hingegen am schnellsten läuft. diff --git a/documentation/content/en/books/handbook/dtrace/_index.adoc b/documentation/content/en/books/handbook/dtrace/_index.adoc index 797d27606c..36f45e95a3 100644 --- a/documentation/content/en/books/handbook/dtrace/_index.adoc +++ b/documentation/content/en/books/handbook/dtrace/_index.adoc @@ -1,290 +1,290 @@ --- title: Chapter 27. DTrace part: Part III. System Administration prev: books/handbook/cutting-edge next: books/handbook/usb-device-mode description: This chapter explains how to use DTrace in FreeBSD tags: ["DTrace", "features", "guide", "tutorial", "kldload"] showBookMenu: true weight: 31 path: "/books/handbook/dtrace/" --- [[dtrace]] = DTrace :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 27 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/dtrace/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[dtrace-synopsis]] == Synopsis DTrace, also known as Dynamic Tracing, was developed by Sun(TM) as a tool for locating performance bottlenecks in production and pre-production systems. In addition to diagnosing performance problems, DTrace can be used to help investigate and debug unexpected behavior in both the FreeBSD kernel and in userland programs. DTrace is a remarkable profiling tool, with an impressive array of features for diagnosing system issues. It may also be used to run pre-written scripts to take advantage of its capabilities. Users can author their own utilities using the DTrace D Language, allowing them to customize their profiling based on specific needs. The FreeBSD implementation provides full support for kernel DTrace and experimental support for userland DTrace. Userland DTrace allows users to perform function boundary tracing for userland programs using the `pid` provider, and to insert static probes into userland programs for later tracing. Some ports, such as package:databases/postgresql12-server[] and package:lang/php74[] have a DTrace option to enable static probes. -The official guide to DTrace is maintained by the Illumos project at http://dtrace.org/guide[DTrace Guide]. +The official guide to DTrace is maintained by the Illumos project at https://illumos.org/books/dtrace/bookinfo.html[DTrace Guide]. After reading this chapter, you will know: * What DTrace is and what features it provides. * Differences between the Solaris(TM) DTrace implementation and the one provided by FreeBSD. * How to enable and use DTrace on FreeBSD. Before reading this chapter, you should: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). * Have some familiarity with security and how it pertains to FreeBSD (crossref:security[security,Security]). [[dtrace-implementation]] == Implementation Differences While the DTrace in FreeBSD is similar to that found in Solaris(TM), differences do exist. The primary difference is that in FreeBSD, DTrace is implemented as a set of kernel modules and DTrace can not be used until the modules are loaded. To load all of the necessary modules: [source,shell] .... # kldload dtraceall .... Beginning with FreeBSD 10.0-RELEASE, the modules are automatically loaded when `dtrace` is run. FreeBSD uses the `DDB_CTF` kernel option to enable support for loading `CTF` data from kernel modules and the kernel itself. `CTF` is the Solaris(TM) Compact C Type Format which encapsulates a reduced form of debugging information similar to `DWARF` and the venerable stabs. `CTF` data is added to binaries by the `ctfconvert` and `ctfmerge` build tools. The `ctfconvert` utility parses `DWARF``ELF` debug sections created by the compiler and `ctfmerge` merges `CTF``ELF` sections from objects into either executables or shared libraries. Some different providers exist for FreeBSD than for Solaris(TM). Most notable is the `dtmalloc` provider, which allows tracing `malloc()` by type in the FreeBSD kernel. Some of the providers found in Solaris(TM), such as `cpc` and `mib`, are not present in FreeBSD. These may appear in future versions of FreeBSD. Moreover, some of the providers available in both operating systems are not compatible, in the sense that their probes have different argument types. Thus, `D` scripts written on Solaris(TM) may or may not work unmodified on FreeBSD, and vice versa. Due to security differences, only `root` may use DTrace on FreeBSD. Solaris(TM) has a few low level security checks which do not yet exist in FreeBSD. As such, the [.filename]#/dev/dtrace/dtrace# is strictly limited to `root`. DTrace falls under the Common Development and Distribution License (`CDDL`) license. To view this license on FreeBSD, see [.filename]#/usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE# or view it online at http://opensource.org/licenses/CDDL-1.0[http://opensource.org/licenses/CDDL-1.0]. While a FreeBSD kernel with DTrace support is `BSD` licensed, the `CDDL` is used when the modules are distributed in binary form or the binaries are loaded. [[dtrace-enable]] == Enabling DTrace Support In FreeBSD 9.2 and 10.0, DTrace support is built into the [.filename]#GENERIC# kernel. Users of earlier versions of FreeBSD or who prefer to statically compile in DTrace support should add the following lines to a custom kernel configuration file and recompile the kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]: [.programlisting] .... options KDTRACE_HOOKS options DDB_CTF makeoptions DEBUG=-g makeoptions WITH_CTF=1 .... Users of the AMD64 architecture should also add this line: [.programlisting] .... options KDTRACE_FRAME .... This option provides support for `FBT`. While DTrace will work without this option, there will be limited support for function boundary tracing. Once the FreeBSD system has rebooted into the new kernel, or the DTrace kernel modules have been loaded using `kldload dtraceall`, the system will need support for the Korn shell as the DTrace Toolkit has several utilities written in `ksh`. Make sure that the package:shells/ksh93[] package or port is installed. It is also possible to run these tools under package:shells/pdksh[] or package:shells/mksh[]. Finally, install the current DTrace Toolkit, a collection of ready-made scripts for collecting system information. There are scripts to check open files, memory, `CPU` usage, and a lot more. FreeBSD 10 installs a few of these scripts into [.filename]#/usr/share/dtrace#. On other FreeBSD versions, or to install the full DTrace Toolkit, use the package:sysutils/dtrace-toolkit[] package or port. [NOTE] ==== The scripts found in [.filename]#/usr/share/dtrace# have been specifically ported to FreeBSD. Not all of the scripts found in the DTrace Toolkit will work as-is on FreeBSD and some scripts may require some effort in order for them to work on FreeBSD. ==== The DTrace Toolkit includes many scripts in the special language of DTrace. This language is called the D language and it is very similar to C++. An in depth discussion of the language is beyond the scope of this document. It is covered extensively in the http://www.dtrace.org/guide[Illumos Dynamic Tracing Guide]. [[dtrace-out-of-kernel]] == Enabling DTrace in Out-of-Kernel Modules To add DTrace support to an out-of-kernel module, which is useful for development and debugging, include the following line in the module's Makefile: [.programlisting] .... CFLAGS+= -DKDTRACE_HOOKS .... This flag enables DTrace hooks during compilation, allowing for advanced debugging and monitoring of the module. Ensure to recompile the module after this modification to activate DTrace functionality. [[dtrace-using]] == Using DTrace DTrace scripts consist of a list of one or more _probes_, or instrumentation points, where each probe is associated with an action. Whenever the condition for a probe is met, the associated action is executed. For example, an action may occur when a file is opened, a process is started, or a line of code is executed. The action might be to log some information or to modify context variables. The reading and writing of context variables allows probes to share information and to cooperatively analyze the correlation of different events. To view all probes, the administrator can execute the following command: [source,shell] .... # dtrace -l | more .... Each probe has an `ID`, a `PROVIDER` (dtrace or fbt), a `MODULE`, and a `FUNCTION NAME`. Refer to man:dtrace[1] for more information about this command. The examples in this section provide an overview of how to use two of the fully supported scripts from the DTrace Toolkit: the [.filename]#hotkernel# and [.filename]#procsystime# scripts. The [.filename]#hotkernel# script is designed to identify which function is using the most kernel time. It will produce output similar to the following: [source,shell] .... # cd /usr/local/share/dtrace-toolkit # ./hotkernel Sampling... Hit Ctrl-C to end. .... As instructed, use the kbd:[Ctrl+C] key combination to stop the process. Upon termination, the script will display a list of kernel functions and timing information, sorting the output in increasing order of time: [source,shell] .... kernel`_thread_lock_flags 2 0.0% 0xc1097063 2 0.0% kernel`sched_userret 2 0.0% kernel`kern_select 2 0.0% kernel`generic_copyin 3 0.0% kernel`_mtx_assert 3 0.0% kernel`vm_fault 3 0.0% kernel`sopoll_generic 3 0.0% kernel`fixup_filename 4 0.0% kernel`_isitmyx 4 0.0% kernel`find_instance 4 0.0% kernel`_mtx_unlock_flags 5 0.0% kernel`syscall 5 0.0% kernel`DELAY 5 0.0% 0xc108a253 6 0.0% kernel`witness_lock 7 0.0% kernel`read_aux_data_no_wait 7 0.0% kernel`Xint0x80_syscall 7 0.0% kernel`witness_checkorder 7 0.0% kernel`sse2_pagezero 8 0.0% kernel`strncmp 9 0.0% kernel`spinlock_exit 10 0.0% kernel`_mtx_lock_flags 11 0.0% kernel`witness_unlock 15 0.0% kernel`sched_idletd 137 0.3% 0xc10981a5 42139 99.3% .... This script will also work with kernel modules. To use this feature, run the script with `-m`: [source,shell] .... # ./hotkernel -m Sampling... Hit Ctrl-C to end. ^C MODULE COUNT PCNT 0xc107882e 1 0.0% 0xc10e6aa4 1 0.0% 0xc1076983 1 0.0% 0xc109708a 1 0.0% 0xc1075a5d 1 0.0% 0xc1077325 1 0.0% 0xc108a245 1 0.0% 0xc107730d 1 0.0% 0xc1097063 2 0.0% 0xc108a253 73 0.0% kernel 874 0.4% 0xc10981a5 213781 99.6% .... The [.filename]#procsystime# script captures and prints the system call time usage for a given process `ID` (`PID`) or process name. In the following example, a new instance of [.filename]#/bin/csh# was spawned. Then, [.filename]#procsystime# was executed and remained waiting while a few commands were typed on the other incarnation of `csh`. These are the results of this test: [source,shell] .... # ./procsystime -n csh Tracing... Hit Ctrl-C to end... ^C Elapsed Times for processes csh, SYSCALL TIME (ns) getpid 6131 sigreturn 8121 close 19127 fcntl 19959 dup 26955 setpgid 28070 stat 31899 setitimer 40938 wait4 62717 sigaction 67372 sigprocmask 119091 gettimeofday 183710 write 263242 execve 492547 ioctl 770073 vfork 3258923 sigsuspend 6985124 read 3988049784 .... As shown, the `read()` system call used the most time in nanoseconds while the `getpid()` system call used the least amount of time. diff --git a/documentation/content/pl/books/handbook/dtrace/_index.adoc b/documentation/content/pl/books/handbook/dtrace/_index.adoc index f396c272c3..38d1b4d02b 100644 --- a/documentation/content/pl/books/handbook/dtrace/_index.adoc +++ b/documentation/content/pl/books/handbook/dtrace/_index.adoc @@ -1,234 +1,234 @@ --- title: Rozdział 25. DTrace part: Część III. Administracja systemem prev: books/handbook/cutting-edge next: books/handbook/usb-device-mode showBookMenu: true weight: 29 path: "/books/handbook/dtrace/" --- [[dtrace]] = DTrace :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 25 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/dtrace/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[dtrace-synopsis]] == Synopsis DTrace, also known as Dynamic Tracing, was developed by Sun(TM) as a tool for locating performance bottlenecks in production and pre-production systems. In addition to diagnosing performance problems, DTrace can be used to help investigate and debug unexpected behavior in both the FreeBSD kernel and in userland programs. DTrace is a remarkable profiling tool, with an impressive array of features for diagnosing system issues. It may also be used to run pre-written scripts to take advantage of its capabilities. Users can author their own utilities using the DTrace D Language, allowing them to customize their profiling based on specific needs. The FreeBSD implementation provides full support for kernel DTrace and experimental support for userland DTrace. Userland DTrace allows users to perform function boundary tracing for userland programs using the `pid` provider, and to insert static probes into userland programs for later tracing. Some ports, such as package:databases/postgresql12-server[] and package:lang/php74[] have a DTrace option to enable static probes. -The official guide to DTrace is maintained by the Illumos project at http://dtrace.org/guide[DTrace Guide]. +The official guide to DTrace is maintained by the Illumos project at https://illumos.org/books/dtrace/bookinfo.html[DTrace Guide]. After reading this chapter, you will know: * What DTrace is and what features it provides. * Differences between the Solaris(TM) DTrace implementation and the one provided by FreeBSD. * How to enable and use DTrace on FreeBSD. Before reading this chapter, you should: * Understand UNIX(R) and FreeBSD basics (crossref:basics[basics,FreeBSD Basics]). * Have some familiarity with security and how it pertains to FreeBSD (crossref:security[security,Security]). [[dtrace-implementation]] == Implementation Differences While the DTrace in FreeBSD is similar to that found in Solaris(TM), differences do exist. The primary difference is that in FreeBSD, DTrace is implemented as a set of kernel modules and DTrace can not be used until the modules are loaded. To load all of the necessary modules: [source,shell] .... # kldload dtraceall .... Beginning with FreeBSD 10.0-RELEASE, the modules are automatically loaded when `dtrace` is run. FreeBSD uses the `DDB_CTF` kernel option to enable support for loading `CTF` data from kernel modules and the kernel itself. `CTF` is the Solaris(TM) Compact C Type Format which encapsulates a reduced form of debugging information similar to `DWARF` and the venerable stabs. `CTF` data is added to binaries by the `ctfconvert` and `ctfmerge` build tools. The `ctfconvert` utility parses `DWARF``ELF` debug sections created by the compiler and `ctfmerge` merges `CTF``ELF` sections from objects into either executables or shared libraries. Some different providers exist for FreeBSD than for Solaris(TM). Most notable is the `dtmalloc` provider, which allows tracing `malloc()` by type in the FreeBSD kernel. Some of the providers found in Solaris(TM), such as `cpc` and `mib`, are not present in FreeBSD. These may appear in future versions of FreeBSD. Moreover, some of the providers available in both operating systems are not compatible, in the sense that their probes have different argument types. Thus, `D` scripts written on Solaris(TM) may or may not work unmodified on FreeBSD, and vice versa. Due to security differences, only `root` may use DTrace on FreeBSD. Solaris(TM) has a few low level security checks which do not yet exist in FreeBSD. As such, the [.filename]#/dev/dtrace/dtrace# is strictly limited to `root`. DTrace falls under the Common Development and Distribution License (`CDDL`) license. To view this license on FreeBSD, see [.filename]#/usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE# or view it online at http://opensource.org/licenses/CDDL-1.0[http://opensource.org/licenses/CDDL-1.0]. While a FreeBSD kernel with DTrace support is `BSD` licensed, the `CDDL` is used when the modules are distributed in binary form or the binaries are loaded. [[dtrace-enable]] == Enabling DTrace Support In FreeBSD 9.2 and 10.0, DTrace support is built into the [.filename]#GENERIC# kernel. Users of earlier versions of FreeBSD or who prefer to statically compile in DTrace support should add the following lines to a custom kernel configuration file and recompile the kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]: [.programlisting] .... options KDTRACE_HOOKS options DDB_CTF makeoptions DEBUG=-g makeoptions WITH_CTF=1 .... Users of the AMD64 architecture should also add this line: [.programlisting] .... options KDTRACE_FRAME .... This option provides support for `FBT`. While DTrace will work without this option, there will be limited support for function boundary tracing. Once the FreeBSD system has rebooted into the new kernel, or the DTrace kernel modules have been loaded using `kldload dtraceall`, the system will need support for the Korn shell as the DTrace Toolkit has several utilities written in `ksh`. Make sure that the package:shells/ksh93[] package or port is installed. It is also possible to run these tools under package:shells/pdksh[] or package:shells/mksh[]. Finally, install the current DTrace Toolkit, a collection of ready-made scripts for collecting system information. There are scripts to check open files, memory, `CPU` usage, and a lot more. FreeBSD 10 installs a few of these scripts into [.filename]#/usr/shared/dtrace#. On other FreeBSD versions, or to install the full DTrace Toolkit, use the package:sysutils/dtrace-toolkit[] package or port. [NOTE] ==== The scripts found in [.filename]#/usr/shared/dtrace# have been specifically ported to FreeBSD. Not all of the scripts found in the DTrace Toolkit will work as-is on FreeBSD and some scripts may require some effort in order for them to work on FreeBSD. ==== The DTrace Toolkit includes many scripts in the special language of DTrace. This language is called the D language and it is very similar to C++. An in depth discussion of the language is beyond the scope of this document. It is covered extensively in the http://www.dtrace.org/guide[Illumos Dynamic Tracing Guide]. [[dtrace-using]] == Using DTrace DTrace scripts consist of a list of one or more _probes_, or instrumentation points, where each probe is associated with an action. Whenever the condition for a probe is met, the associated action is executed. For example, an action may occur when a file is opened, a process is started, or a line of code is executed. The action might be to log some information or to modify context variables. The reading and writing of context variables allows probes to share information and to cooperatively analyze the correlation of different events. To view all probes, the administrator can execute the following command: [source,shell] .... # dtrace -l | more .... Each probe has an `ID`, a `PROVIDER` (dtrace or fbt), a `MODULE`, and a `FUNCTION NAME`. Refer to man:dtrace[1] for more information about this command. The examples in this section provide an overview of how to use two of the fully supported scripts from the DTrace Toolkit: the [.filename]#hotkernel# and [.filename]#procsystime# scripts. The [.filename]#hotkernel# script is designed to identify which function is using the most kernel time. It will produce output similar to the following: [source,shell] .... # cd /usr/local/share/dtrace-toolkit # ./hotkernel Sampling... Hit Ctrl-C to end. .... As instructed, use the kbd:[Ctrl+C] key combination to stop the process. Upon termination, the script will display a list of kernel functions and timing information, sorting the output in increasing order of time: [source,shell] .... kernel`_thread_lock_flags 2 0.0% 0xc1097063 2 0.0% kernel`sched_userret 2 0.0% kernel`kern_select 2 0.0% kernel`generic_copyin 3 0.0% kernel`_mtx_assert 3 0.0% kernel`vm_fault 3 0.0% kernel`sopoll_generic 3 0.0% kernel`fixup_filename 4 0.0% kernel`_isitmyx 4 0.0% kernel`find_instance 4 0.0% kernel`_mtx_unlock_flags 5 0.0% kernel`syscall 5 0.0% kernel`DELAY 5 0.0% 0xc108a253 6 0.0% kernel`witness_lock 7 0.0% kernel`read_aux_data_no_wait 7 0.0% kernel`Xint0x80_syscall 7 0.0% kernel`witness_checkorder 7 0.0% kernel`sse2_pagezero 8 0.0% kernel`strncmp 9 0.0% kernel`spinlock_exit 10 0.0% kernel`_mtx_lock_flags 11 0.0% kernel`witness_unlock 15 0.0% kernel`sched_idletd 137 0.3% 0xc10981a5 42139 99.3% .... This script will also work with kernel modules. To use this feature, run the script with `-m`: [source,shell] .... # ./hotkernel -m Sampling... Hit Ctrl-C to end. ^C MODULE COUNT PCNT 0xc107882e 1 0.0% 0xc10e6aa4 1 0.0% 0xc1076983 1 0.0% 0xc109708a 1 0.0% 0xc1075a5d 1 0.0% 0xc1077325 1 0.0% 0xc108a245 1 0.0% 0xc107730d 1 0.0% 0xc1097063 2 0.0% 0xc108a253 73 0.0% kernel 874 0.4% 0xc10981a5 213781 99.6% .... The [.filename]#procsystime# script captures and prints the system call time usage for a given process `ID` (`PID`) or process name. In the following example, a new instance of [.filename]#/bin/csh# was spawned. Then, [.filename]#procsystime# was executed and remained waiting while a few commands were typed on the other incarnation of `csh`. These are the results of this test: [source,shell] .... # ./procsystime -n csh Tracing... Hit Ctrl-C to end... ^C Elapsed Times for processes csh, SYSCALL TIME (ns) getpid 6131 sigreturn 8121 close 19127 fcntl 19959 dup 26955 setpgid 28070 stat 31899 setitimer 40938 wait4 62717 sigaction 67372 sigprocmask 119091 gettimeofday 183710 write 263242 execve 492547 ioctl 770073 vfork 3258923 sigsuspend 6985124 read 3988049784 .... As shown, the `read()` system call used the most time in nanoseconds while the `getpid()` system call used the least amount of time. diff --git a/documentation/content/zh-tw/books/handbook/dtrace/_index.adoc b/documentation/content/zh-tw/books/handbook/dtrace/_index.adoc index 81fa1ca79e..2b827a8698 100644 --- a/documentation/content/zh-tw/books/handbook/dtrace/_index.adoc +++ b/documentation/content/zh-tw/books/handbook/dtrace/_index.adoc @@ -1,278 +1,278 @@ --- title: 章 24. DTrace part: 部 III. 系統管理 prev: books/handbook/cutting-edge next: books/handbook/usb-device-mode description: This chapter explains how to use DTrace in FreeBSD tags: ["DTrace", "features", "guide", "tutorial", "kldload"] showBookMenu: true weight: 30 path: "/books/handbook/dtrace/" aliases: ["/en/books/handbook/dtrace-implementation/","/en/books/handbook/dtrace-enable/","/en/books/handbook/dtrace-using/"] --- [[dtrace]] = DTrace :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 24 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/dtrace/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[dtrace-synopsis]] == 概述 DTrace，又被稱作 Dynamic Tracing ，由 Sun(TM) 開發，用在生產 (production) 跟預生產 (pre-production) 系統中找出效能瓶頸的工具。 除了診斷性能問題外，DTrace 還可以用於查詢以及除錯 FreeBSD 核心和使用者層級程式的未預期行為。 DTrace 是一個卓越的分析工具，具有一系列令人驚豔、用於診斷系統問題的功能。 它還可以執行預先寫好的腳本，以使用其功能。 使用者可以用 DTrace D 語言編寫自己的工具，從而允許他們根據特定的需求客製化。 FreeBSD 實做提供對核心層級的 DTrace 全面的支援，以及對使用者層級的 DTrace 實驗性的支援。 使用者層級的 DTrace 允許使用者使用 `pid` 執行函式邊界追蹤 (function boundary tracing)，並將 static probes 插入到使用者程式以供之後追蹤。 一些 ports，像是 package:databases/postgresql12-server[] 和 package:lang/php74[] 提供 DTrace 選項，以提供 static probes 功能。 -DTrace 的官方指南由 Illumos 維護，在 http://dtrace.org/guide[DTrace Guide]。 +DTrace 的官方指南由 Illumos 維護，在 https://illumos.org/books/dtrace/bookinfo.html[DTrace Guide]。 讀完這章，您將了解： * 什麼是 DTrace 以及其提供的功能。 * Solaris(TM) 實做的 DTrace 跟 FreeBSD 提供的 DTrace 之間的不同之處。 * 如何在 FreeBSD 上啟用和使用 DTrace。 在開始閱讀這章之前，您需要： * 了解 UNIX(TM) 及 FreeBSD 基礎 (crossref:basics[basics,FreeBSD 基礎])。 * 了解安全性以及其跟 FreeBSD 的關係 (crossref:security[security,安全性])。 [[dtrace-implementation]] == 實作差異 雖然 FreeBSD 的 DTrace 和 Solaris(TM) 的 DTrace 類似，但是還是有存在差異。 最重要的區別為，在 FreeBSD 中，DTrace 是作為一組核心模組 (kernel modules) 實做的，並且在載入模組之前無法使用。 要載入所有需要的模組: [source,shell] .... # kldload dtraceall .... 從 FreeBSD 10.0-RELEASE 之後，模組會在執行 `dtrace` 時自動載入。 FreeBSD 使用 `DDB_CTF` 核心選項來支援從核心模組和核心本身載入 `CTF` 資料。 `CTF` 是 Solaris(TM) Compact C Type Format，它封裝了一種簡化形式的除錯資訊，類似於 `DWARF` 和 古老的 stabs。 `CTF` 資料通過`ctfconvert` and `ctfmerge` 建構工具，加入到二進制文件中。 `ctfconvert` 工具分析編譯器創建的 `DWARF``ELF` 除錯部份，而 `ctfmerge` 將目標的 `CTF``ELF` 部份合併到執行檔或函式庫中。 與 Solaris(TM) 相比，FreeBSD 存在一些不同的 providers。 最值得注意的是 `dtmalloc` provider 允許在 FreeBSD 核心中按照類型 (type) 追蹤 `malloc()`。 Solaris(TM) 中的一些 providers，例如 `cpc` 和 `mib`，在 FreeBSD 中則不存在。 這些可能會在 FreeBSD 未來的版本中出現。 此外，兩個作業系統中一些可用的 providers 是不相容的，因為他們具有不同的參數類型。 因此，在 Solaris(TM) 上拓寫的 `D` 腳本在未經修改的情況下可能可以或不可以在 FreeBSD 上執行，反之亦然。 因為安全的差異，只有 `root` 可以在 FreeBSD 上使用 DTrace。 Solaris(TM) 擁有一些 FreeBSD 中還不存在的低階 (low level) 安全檢查。 因此 [.filename]#/dev/dtrace/dtrace# 被嚴格限制成 `root`。 DTrace 使用 Common Development and Distribution License (`CDDL`) 授權。 要在 FreeBSD 上查看此授權, 請參閱 [.filename]#/usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE# 或者在 http://opensource.org/licenses/CDDL-1.0[http://opensource.org/licenses/CDDL-1.0] 線上查看。 雖然具有 DTrace 支援的 FreeBSD 核心使用 `BSD` 授權，但當模組使用二進制形式或者二進制文件發布時，將使用 `CDDL` 授權。 [[dtrace-enable]] == 開啟 DTrace 支援 在 FreeBSD 9.2 和 10.0 中，DTrace 內建於 [.filename]#GENERIC# 核心裡。 FreeBSD 早期版本的使用者或喜歡在 DTrace 支援下靜態編譯的使用者應加入下列幾行到客製化核心配置文件，並根據 crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel] 中的說明重新編譯核心: [.programlisting] .... options KDTRACE_HOOKS options DDB_CTF makeoptions DEBUG=-g makeoptions WITH_CTF=1 .... AMD64 架構的使用者應加入下列幾行: [.programlisting] .... options KDTRACE_FRAME .... 此選項提供對 `FBT` 的支援， 雖然 DTrace 可以在沒有此選項的情況下運作，但對函式邊界追蹤的支援有限。 一旦 FreeBSD 系統使用新的核心重新啟動，或者使用 `kldload dtraceall` 載入 DTrace 核心模組後，系統需要支援 Korn shell，因為 DTrace 工具箱有幾個用 `ksh` 拓寫的工具。 確保已經安裝 package:shells/ksh93[] 套件或者 port， 也可以在 package:shells/pdksh[] 或者 package:shells/mksh[] 下執行這些工具。 最後，安裝目前的 DTrace 工具箱，這是一組用於收集系統資訊的現成腳本， 有一些腳本可以檢查打開的文件、記憶體、`CPU` 使用情況等等。 FreeBSD 10 將其中一些腳本安裝在 [.filename]#/usr/share/dtrace# 中。 在其他 FreeBSD 的版本中，要安裝 DTrace 工具箱，請使用 package:sysutils/dtrace-toolkit[] 套件或者 port。 [NOTE] ==== [.filename]#/usr/share/dtrace# 中的腳本已專門移植到 FreeBSD， 並非所有在 DTrace 工具箱中的所有腳本都能在 FreeBSD 上按照原樣運作，一些腳本可能需要一些修改才能在 FreeBSD 上運作。 ==== DTrace 工具箱包含許多使用 DTrace 特殊語言的腳本， 這種語言被稱為 D 語言，它與 C++ 非常類似， 對於該語言的深度討論超出了此文件的範圍， 他在 http://www.dtrace.org/guide[Illumos Dynamic Tracing Guide] 有廣泛的介紹。 [[dtrace-using]] == 使用 DTrace DTrace 腳本由一個或多個 _probes_ 或檢查點 (instrumentation points) 的列表組成，其中每個 probe 都與一個行為有關， 只要能滿足 probe 的條件，就會執行相關的行為， 舉例來說，打開文件、啟動一個行程或執行一行程式。 該行為可能是紀錄一些資訊，或修改上下文變數 (context variables)， 上下文變數的讀寫允許 probes 分享資訊和共同分析不同事件的相關性。 想要查看所有的 probes，系統管理員可以執行以下指令: [source,shell] .... # dtrace -l | more .... 每個 probe 都有一個 `ID`、一個 `PROVIDER` (dtrace 或者 fbt)、一個 `MODULE` 和一個 `FUNCTION NAME`。 有關此指令的更多資訊，請參閱 man:dtrace[1]。 本節中的例子概述如何使用 DTrace 工具箱中完全支援的兩個腳本: [.filename]#hotkernel# 和 [.filename]#procsystime# 腳本。 [.filename]#hotkernel# 腳本設計成觀察哪個函式使用的核心時間最多， 它會產生類似於以下內容的輸出: [source,shell] .... # cd /usr/local/share/dtrace-toolkit # ./hotkernel Sampling... Hit Ctrl-C to end. .... 按照說明，使用 kbd:[Ctrl+C] 組合鍵停止行程， 中止後，腳本將顯示一整列的核心函式和時間資訊，按照時間遞增排序: [source,shell] .... kernel`_thread_lock_flags 2 0.0% 0xc1097063 2 0.0% kernel`sched_userret 2 0.0% kernel`kern_select 2 0.0% kernel`generic_copyin 3 0.0% kernel`_mtx_assert 3 0.0% kernel`vm_fault 3 0.0% kernel`sopoll_generic 3 0.0% kernel`fixup_filename 4 0.0% kernel`_isitmyx 4 0.0% kernel`find_instance 4 0.0% kernel`_mtx_unlock_flags 5 0.0% kernel`syscall 5 0.0% kernel`DELAY 5 0.0% 0xc108a253 6 0.0% kernel`witness_lock 7 0.0% kernel`read_aux_data_no_wait 7 0.0% kernel`Xint0x80_syscall 7 0.0% kernel`witness_checkorder 7 0.0% kernel`sse2_pagezero 8 0.0% kernel`strncmp 9 0.0% kernel`spinlock_exit 10 0.0% kernel`_mtx_lock_flags 11 0.0% kernel`witness_unlock 15 0.0% kernel`sched_idletd 137 0.3% 0xc10981a5 42139 99.3% .... 此腳本也是用於核心模組， 要使用此功能，請使用 `-m` 執行腳本: [source,shell] .... # ./hotkernel -m Sampling... Hit Ctrl-C to end. ^C MODULE COUNT PCNT 0xc107882e 1 0.0% 0xc10e6aa4 1 0.0% 0xc1076983 1 0.0% 0xc109708a 1 0.0% 0xc1075a5d 1 0.0% 0xc1077325 1 0.0% 0xc108a245 1 0.0% 0xc107730d 1 0.0% 0xc1097063 2 0.0% 0xc108a253 73 0.0% kernel 874 0.4% 0xc10981a5 213781 99.6% .... [.filename]#procsystime# 抓取和輸出系統調用時間，給設定行程 ID (PID) 或行程名稱的行程。 在以下的例子中，生成了 [.filename]#/bin/csh# 新物件， 然後，[.filename]#procsystime# 被執行並一直等待，同時在 `csh` 的另一個化身上輸入一些指令， 以下是本次測試的結果: [source,shell] .... # ./procsystime -n csh Tracing... Hit Ctrl-C to end... ^C Elapsed Times for processes csh, SYSCALL TIME (ns) getpid 6131 sigreturn 8121 close 19127 fcntl 19959 dup 26955 setpgid 28070 stat 31899 setitimer 40938 wait4 62717 sigaction 67372 sigprocmask 119091 gettimeofday 183710 write 263242 execve 492547 ioctl 770073 vfork 3258923 sigsuspend 6985124 read 3988049784 .... 如圖所示，`read()` 系統調用使用的時間最多（以奈秒為單位），而 `getpid()` 系統調用使用的時間最少。