Ich muss die Leistung einer Anwendung profilieren, für die ich Strace verwende. Ich weiß jedoch nicht wirklich, wie ich die verschiedenen Systemaufrufe interpretieren soll, die strace ausgibt. Beispiele für einige von ihnen sind unten:
Ich wäre dankbar, wenn jemand kurz im Klartext erklären könnte, was diese Zeilen von (A) bis (F) wirklich in Bezug auf E / A, übertragene Daten, Bedeutung für die Leistung usw. bedeuten.
Ich habe die Manpages von strace durchgesehen, bin aber immer noch nicht sehr zuversichtlich. Wenn Sie weitere Hinweise für mich zum Lesen hätten, wäre das großartig.
Ich habe einige Hintergrundinformationen zu Betriebssystemen und verstehe, was Systemaufrufe, Speicher, virtueller Speicher, Scheduling usw. sind.
strace ist eher ein Debugging-Tool als ein Profiler. Suchen Sie wirklich nach so etwas wie gprof?
– Ente
13. Juni 2011 um 19:24 Uhr
Ich stimme zu. Da ‘strace’ Ihnen nur Systemaufrufe zeigt, ist das Beste, was Sie tun können, eine große Zeitlücke zwischen Systemaufrufen zu sehen und herauszufinden, was das Programm zwischen diesen Aufrufen gemacht hat, die so lange gedauert haben. Dies ist kein guter Weg, um ein Profil zu erstellen. Verwenden Sie stattdessen ‘callgrind’ (Teil von ‘valgrind’) und analysieren Sie die Ergebnisse mit ‘kcachegrind’. Oder verwenden Sie gprof, sysprof, oprofile oder ähnliches.
– David Schwartz
14. August 2011 um 17:44 Uhr
Sie sollten die Manpage der Systemaufrufe lesen, die hier vorgeformt ist. Lauf man lseek , man open , man mmap usw.
– Nr
23. Februar 2014 um 18:26 Uhr
Blagovest Buyukliev
Um diese zu verstehen, müssen Sie sich mit den POSIX-Systemaufrufen vertraut machen. Sie sind die Schnittstelle, die ein User-Space-Programm verwendet, um mit dem Kernel zu interagieren.
lseek, write, close, mmap, munmap und fstat sind alle Systemaufrufe und sind in Abschnitt 2 des Linux-Handbuchs dokumentiert.
Knapp, lseek verschiebt den internen Zeiger des bereitgestellten Dateideskriptors auf das Byte mit der Position, auf die das zweite Argument zeigt, beginnend mit SEEK_SET (der Anfang), SEEK_CUR (aktuelle Position) bzw SEEK_END (das Ende). Beliebig aufeinanderfolgend read und write Anrufe auf denselben Deskriptor starten ihre Aktion von dieser Position aus. Beachten Sie, dass lseek ist nicht für alle Arten von Deskriptoren implementiert – es macht Sinn für eine Datei auf der Festplatte, aber nicht für einen Socket oder eine Pipe.
write kopiert den bereitgestellten Puffer in den Kernelspace und gibt die Anzahl der tatsächlich geschriebenen Bytes zurück. Abhängig von der Art des Deskriptors kann der Kernel die Daten auf die Festplatte schreiben oder sie über das Netzwerk senden. Dies ist im Allgemeinen ein kostspieliger Vorgang, da dieser Puffer an den Kernel übertragen werden muss.
close schließt den bereitgestellten Deskriptor und alle zugehörigen Ressourcen im Kernel werden freigegeben. Beachten Sie, dass jeder Prozess eine Begrenzung der Anzahl gleichzeitig geöffneter Deskriptoren hat, daher ist es manchmal notwendig, Deskriptoren zu schließen, um diese Begrenzung nicht zu erreichen.
mmap ist ein komplexer Systemaufruf und wird für viele Zwecke verwendet, einschließlich gemeinsam genutzten Speichers. Die allgemeine Verwendung besteht jedoch darin, dem Prozess mehr Speicher zuzuweisen. Das malloc und calloc Bibliotheksfunktionen verwenden es normalerweise intern.
munmap befreit die mmap‘Pädagogik.
fstat gibt verschiedene Informationen zurück, die das Dateisystem über eine Datei speichert – Größe, letzte Änderung, Berechtigungen usw.
Danke für eine schnelle Antwort. Meinst du mit Linux-Handbuch die Manpages oder ist es ein separates Dokument?
– Ketan Maheshwari
13. Juni 2011 um 18:30 Uhr
Ja, die Manpages. Zum Beispiel, man 2 write oder man 2 mmap.
– Blagovest Buyukliev
13. Juni 2011 um 18:30 Uhr
Okay, ich habe mir diese angeschaut. Sie erklären jedoch nur, was die Anrufe bewirken. Woher weiß ich die relative Bedeutung dieser Anrufe in Bezug auf die Gesamtleistung?
– Ketan Maheshwari
13. Juni 2011 um 18:41 Uhr
@ketan: durch das Bestehen der -r Option zu strace
– ninjalj
13. Juni 2011 um 19:47 Uhr
kenorb
Für jeden Befehl gibt es eine Handbuchseite, die Sie durch Eintippen lesen können man und der Name der C-Funktion, zB man lseek (auch prüfen apropos). Sie haben auch eine Beschreibung der übergebenen Parameter.
Hier kurze Zusammenfassungen:
lseek – Lese-/Schreibdatei-Offset des Dateideskriptors neu positionieren
write – Schreiben in einen Dateideskriptor aus dem Puffer
close – Löschen eines Deskriptors aus der Objektreferenztabelle pro Prozess
mmap – Weisen Sie Speicher zu oder ordnen Sie Dateien oder Geräten dem Speicher zu
munmap – Entfernen Sie eine Zuordnung für den angegebenen Adressbereich
fstat – Dateistatus erhalten, auf den der Pfad zeigt
Bitte beachten Sie, dass die Interpretation einzelner/zufälliger Syscals in Bezug auf die Leistung nicht sinnvoll ist. Um die Signifikanz der Leistung dieser Systemaufrufe zu testen, sollten Sie verwenden -c Parameter, der Zeit, Aufrufe und Fehler für jeden Systemaufruf zählen und die Zusammenfassung melden kann. Dann können Sie mehr darüber lesen, welche die längste Zeit in Anspruch nehmen.
Um mehr über Ausgabe und zu erfahren strace Parameter, überprüfen man strace.
Siehe auch: Wie parse ich strace in der Shell in reinen Text?
13866900cookie-checkWie interpretiert man die Strace-Ausgabe?yes
strace ist eher ein Debugging-Tool als ein Profiler. Suchen Sie wirklich nach so etwas wie gprof?
– Ente
13. Juni 2011 um 19:24 Uhr
Ich stimme zu. Da ‘strace’ Ihnen nur Systemaufrufe zeigt, ist das Beste, was Sie tun können, eine große Zeitlücke zwischen Systemaufrufen zu sehen und herauszufinden, was das Programm zwischen diesen Aufrufen gemacht hat, die so lange gedauert haben. Dies ist kein guter Weg, um ein Profil zu erstellen. Verwenden Sie stattdessen ‘callgrind’ (Teil von ‘valgrind’) und analysieren Sie die Ergebnisse mit ‘kcachegrind’. Oder verwenden Sie gprof, sysprof, oprofile oder ähnliches.
– David Schwartz
14. August 2011 um 17:44 Uhr
Sie sollten die Manpage der Systemaufrufe lesen, die hier vorgeformt ist. Lauf
man lseek
,man open
,man mmap
usw.– Nr
23. Februar 2014 um 18:26 Uhr