1. 程式人生 > >系統技術非業餘研究 » GLIBC 2.16 支援systemtap靜態檢查點

系統技術非業餘研究 » GLIBC 2.16 支援systemtap靜態檢查點

剛@淘寶雕樑 告訴我 GLIBC 2.16 支援systemtap靜態檢查點,訊息源在這裡, 摘抄相關部分如下:

* New configure option –enable-systemtap builds SystemTap static probes
into libc for setjmp and longjmp and into libpthread for various operations.
So far the setjmp/longjmp probes and some of the libpthread probes are
provided only for i*86 and x86_64.
Implemented by Roland McGrath and Rayson Ho.

目前主要是在setjmp/longjmp和pthread相關的鎖操作,而且只支援 i*86 and x86_64 平臺。我們到原始碼驗證下:

這裡下載原始碼glibc-2.16.0.tar.gz, 解開後簡單的grep下:

[~/glibc-2.16.0]$grep -rin LIBC_PROBE .
./sysdeps/i386/__longjmp.S:35:  LIBC_PROBE (longjmp, 3, [email protected]%eax, [email protected](%esp), [email protected]%edx)
./sysdeps/i386/__longjmp.S:53:  LIBC_PROBE (longjmp_target, 3, 
[email protected]
%eax, [email protected](%esp), [email protected]%edx) ./sysdeps/i386/__longjmp.S:61: LIBC_PROBE (longjmp, 3, [email protected]%ecx, [email protected]%eax, [email protected]%edx) ./sysdeps/i386/__longjmp.S:68: LIBC_PROBE (longjmp_target, 3, [email protected]
%ecx, [email protected]%ecx, [email protected]%edx) ./sysdeps/i386/bsd-_setjmp.S:50: LIBC_PROBE (setjmp, 3, [email protected]%edx, [email protected]$0, [email protected]%ecx) ./sysdeps/i386/setjmp.S:46: LIBC_PROBE (setjmp, 3, [email protected]%eax, [email protected](%esp), [email protected]%ecx) ./sysdeps/i386/bsd-setjmp.S:52: LIBC_PROBE (setjmp, 3, [email protected]%eax, [email protected]$1, [email protected]%ecx) ./sysdeps/unix/sysv/linux/i386/____longjmp_chk.S:83: LIBC_PROBE (longjmp, 3, [email protected]%ecx, [email protected](%esp), [email protected]%edx) ./sysdeps/unix/sysv/linux/i386/____longjmp_chk.S:107: LIBC_PROBE (longjmp_target, 3, [email protected]%ecx, [email protected]%eax, [email protected]%edx) ./sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:108: LIBC_PROBE (longjmp, 3, [email protected]%RDI_LP, [email protected]%esi, [email protected]%RDX_LP) ./sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:128: LIBC_PROBE (longjmp_target, 3, ./sysdeps/x86_64/__longjmp.S:45: LIBC_PROBE (longjmp, 3, [email protected]%RDI_LP, [email protected]%esi, [email protected]%RDX_LP) ./sysdeps/x86_64/__longjmp.S:65: LIBC_PROBE (longjmp_target, 3, ./sysdeps/x86_64/setjmp.S:51: LIBC_PROBE (setjmp, 3, [email protected]%RDI_LP, [email protected]%esi, [email protected]%RAX_LP) ./include/stap-probe.h:26:/* Our code uses one macro LIBC_PROBE (name, n, arg1, ..., argn). ./include/stap-probe.h:41: other headers that use LIBC_PROBE inside their own macros. We ./include/stap-probe.h:47:# define LIBC_PROBE(name, n, ...) \ ./include/stap-probe.h:48: LIBC_PROBE_1 (IN_LIB, name, n, ## __VA_ARGS__) ./include/stap-probe.h:50:# define LIBC_PROBE_1(lib, name, n, ...) \ ./include/stap-probe.h:55:# define LIBC_PROBE_ASM(name, template) \ ./include/stap-probe.h:58:# define LIBC_PROBE_ASM_OPERANDS STAP_PROBE_ASM_OPERANDS ./include/stap-probe.h:64:# define LIBC_PROBE(name, n, ...) \ ./include/stap-probe.h:66: _Bool __libc_probe_args[] = { 0, ## __VA_ARGS__ }; \ ./include/stap-probe.h:67: _Bool __libc_probe_verify_n[(sizeof __libc_probe_args / sizeof (_Bool)) \ ./include/stap-probe.h:69: (void) __libc_probe_verify_n; \ ./include/stap-probe.h:72:# define LIBC_PROBE(name, n, ...) /* Nothing. */ ./include/stap-probe.h:75:# define LIBC_PROBE_ASM(name, template) /* Nothing. */ ./include/stap-probe.h:76:# define LIBC_PROBE_ASM_OPERANDS(n, ...) /* Nothing. */ ./nptl/pthread_join.c:59: LIBC_PROBE (pthread_join, 1, threadid); ./nptl/pthread_join.c:116: LIBC_PROBE (pthread_join_ret, 3, threadid, result, pd->result); ./nptl/pthread_rwlock_wrlock.c:34: LIBC_PROBE (wrlock_entry, 1, rwlock); ./nptl/pthread_rwlock_wrlock.c:47: LIBC_PROBE (wrlock_acquire_write, 1, rwlock); ./nptl/ChangeLog:175: * pthread_create.c (start_thread): Define pthread_start LIBC_PROBE. ./nptl/pthread_mutex_lock.c:52: LIBC_PROBE (mutex_entry, 1, mutex); ./nptl/pthread_mutex_lock.c:133: LIBC_PROBE (mutex_acquired, 1, mutex); ./nptl/pthread_mutex_lock.c:475: LIBC_PROBE (mutex_acquired, 1, mutex); ./nptl/sysdeps/unix/sysv/linux/i386/lowlevellock.h:230: LIBC_PROBE (lll_futex_wake, 3, futex, nr, private); \ ./nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:63: LIBC_PROBE (cond_timedwait, 3, %ebx, 24(%esp), %ebp) ./nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_rwlock_rdlock.S:44: LIBC_PROBE (rdlock_entry, 1, %ebx) ./nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:95:1: LIBC_PROBE (lll_lock_wait_private, 1, %ebx) ./nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_broadcast.S:52: LIBC_PROBE (cond_broadcast, 1, %edx) ./nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:64: LIBC_PROBE (cond_wait, 2, 24(%esp), %ebx) ./nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_signal.S:47: LIBC_PROBE (cond_signal, 1, %edi) ./nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_rwlock_wrlock.S:44: LIBC_PROBE (wrlock_entry, 1, %ebx) ./nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.h:231: LIBC_PROBE (lll_futex_wake, 3, futex, nr, private); \ ./nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:71: LIBC_PROBE (cond_timedwait, 3, %rdi, %rsi, %rdx) ./nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_rdlock.S:34: LIBC_PROBE (rdlock_entry, 1, %rdi) ./nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:91:1: LIBC_PROBE (lll_lock_wait_private, 1, %rdi) ./nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:131:1: LIBC_PROBE (lll_lock_wait, 2, %rdi, %rsi) ./nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_broadcast.S:36: LIBC_PROBE (cond_broadcast, 1, %rdi) ./nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:69: LIBC_PROBE (cond_wait, 2, %rdi, %rsi) ./nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_signal.S:37: LIBC_PROBE (cond_signal, 1, %rdi) ./nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_wrlock.S:34: LIBC_PROBE (wrlock_entry, 1, %rdi) ./nptl/pthread_cond_destroy.c:32: LIBC_PROBE (cond_destroy, 1, cond); ./nptl/pthread_cond_broadcast.c:35: LIBC_PROBE (cond_broadcast, 1, cond); ./nptl/pthread_cond_signal.c:38: LIBC_PROBE (cond_signal, 1, cond); ./nptl/pthread_rwlock_destroy.c:27: LIBC_PROBE (rwlock_destroy, 1, rwlock); ./nptl/pthread_mutex_init.c:138: LIBC_PROBE (mutex_init, 1, mutex); ./nptl/pthread_rwlock_rdlock.c:34: LIBC_PROBE (rdlock_entry, 1, rwlock); ./nptl/pthread_rwlock_rdlock.c:55: LIBC_PROBE (rdlock_acquire_read, 1, rwlock); ./nptl/pthread_mutex_timedlock.c:38: LIBC_PROBE (mutex_timedlock_entry, 2, mutex, abstime); ./nptl/pthread_mutex_timedlock.c:178: LIBC_PROBE (mutex_timedlock_acquired, 1, mutex); ./nptl/pthread_mutex_timedlock.c:250: LIBC_PROBE (mutex_timedlock_acquired, 1, mutex); ./nptl/pthread_mutex_timedlock.c:387: LIBC_PROBE (mutex_timedlock_acquired, 1, mutex); ./nptl/pthread_mutex_timedlock.c:490: LIBC_PROBE (mutex_timedlock_acquired, 1, mutex); ./nptl/pthread_mutex_unlock.c:54: LIBC_PROBE (mutex_release, 1, mutex); ./nptl/pthread_mutex_unlock.c:279: LIBC_PROBE (mutex_release, 1, mutex); ./nptl/pthread_mutex_unlock.c:288: LIBC_PROBE (mutex_release, 1, mutex); ./nptl/pthread_cond_wait.c:104: LIBC_PROBE (cond_wait, 2, cond, mutex); ./nptl/pthread_cond_init.c:44: LIBC_PROBE (cond_init, 2, cond, cond_attr); ./nptl/pthread_create.c:304: LIBC_PROBE (pthread_start, 3, (pthread_t) pd, pd->start_routine, pd->arg); ./nptl/pthread_create.c:563: LIBC_PROBE (pthread_create, 4, newthread, attr, start_routine, arg); ./nptl/pthread_rwlock_unlock.c:30: LIBC_PROBE (rwlock_unlock, 1, rwlock); ./nptl/pthread_mutex_destroy.c:29: LIBC_PROBE (mutex_destroy, 1, mutex);

確實驗證了官方的說法。 那麼這個特性如何的啟用呢?

在編譯libc的時候 configure –enable-systemtap 就好了。
那麼如何驗證這些檢查點的存在呢? 參看systemtap官網的這篇文章,詳細的介紹了靜態檢查點,參看這裡
簡單的說就是用 stap -L ‘process(“libc.so”).mark(“*”)’ 看可否列出所有的檢查點。

那麼這些檢查點如何使用呢? 引數如何呢?
文件在這裡 ./nptl/DESIGN-systemtap-probes.txt
我們來看下:

Systemtap is a dynamic tracing/instrumenting tool available on Linux. Probes
that are not fired at run time have close to zero overhead.

The following probes are available for NPTL:

Thread creation & Join Probes
=============================
pthread_create – probe for pthread_create
arg1 = pointer (pthread_t*) to thread
arg2 = pointer (pthread_attr_t*) to attr
arg3 = pointer (void *) to start_routine
arg4 = arguments to start_routine
pthread_start – probe for actual thread creation
arg1 = struct pthread (members include thread ID, process ID)
arg2 = address of start_routine
arg3 = pointer to the list of arguments
pthread_join – probe for pthread_join
arg1 = thread ID
pthread_join_ret – probe for pthread_join return
arg1 = thread ID
arg2 = return value

Lock-related Probes
===================
mutex_init – probe for pthread_mutex_init
arg1 = address of mutex lock
mutex_acquired – probe for succ. return of pthread_mutex_lock
arg1 = address of mutex lock
mutex_timedlock_acquired – probe for succ. return of pthread_mutex_timedlock
arg1 = address of mutex lock
mutex_entry – probe for entry to the pthread_mutex_lock function
arg1 = address of mutex lock
mutex_timedlock_entry – probe for entry to the pthread_mutex_timedlock function
arg1 = address of mutex lock, arg2 = address of timespec
mutex_release – probe for pthread_mutex_unlock after the successful release of a
mutex lock
arg1 = address of mutex lock
mutex_destroy – probe for pthread_mutex_destroy
arg1 = address of mutex lock

wrlock_entry – probe for entry to the pthread_rwlock_wrlock function
arg1 = address of rw lock
rdlock_entry – probe for entry to the pthread_rwlock_rdlock function
arg1 = address of rw lock

rwlock_destroy – probe for pthread_rwlock_destroy
arg1 = address of rw lock
wrlock_acquire_write – probe for pthread_rwlock_wrlock (after getting the lock)
arg1 = address of rw lock
rdlock_acquire_read – probe for pthread_rwlock_rdlock after successfully getting
the lock
arg1 = address of rw lock
rwlock_unlock – probe for pthread_rwlock_unlock
arg1 = address of rw lock

lll_lock_wait – probe in low-level (assembly language) locking code, only fired
when futex/FUTEX_WAIT is called (i.e. when trying to acquire a
contented lock)
arg1 = pointer to futex
arg2 = flags passed to the futex system call
lll_lock_wait_private – probe in low-level (assembly language) locking code,
only fired when futex/FUTEX_WAIT is called (i.e. when
trying to acquire a contented lock)
arg1 = pointer to futex

lll_futex_wake – probe in low-level (assembly language) locking code, only fired
when futex (FUTEX_WAKE) is called
arg1 = pointer to futex
arg2 = number of processes to wake
arg3 = additional flags

Condition variable Probes
=========================
cond_init – probe for pthread_cond_init
arg1 = condition
arg2 = attr
cond_destroy – probe for pthread_cond_destroy
arg1 = cond
cond_wait – probe for pthread_cond_wait
arg1 = condition
arg2 = mutex lock
cond_timedwait – probe for pthread_cond_timedwait
arg1 = condition
arg2 = mutex lock
arg3 = timespec
cond_signal – probe for pthread_cond_signal
arg1 = condition
cond_broadcast – probe for pthread_cond_broadcast
arg1 = condition

還是很詳細的。setjmp/longjmp不常用就算了。

有這些靜態檢查點的幫助,我們定位libc相關鎖的問題就非常方便了,而且只有使用的時候才需要付出效能代價。

祝玩得開心!

Post Footer automatically generated by wp-posturl plugin for wordpress.

相關推薦

系統技術業餘研究 » GLIBC 2.16 支援systemtap靜態查點

剛@淘寶雕樑 告訴我 GLIBC 2.16 支援systemtap靜態檢查點,訊息源在這裡, 摘抄相關部分如下: * New configure option –enable-systemtap builds SystemTap static probes into libc for setj

系統技術業餘研究 » Linux 2.6.38 User

Linux核心裡面自帶非常多的加密模組,這是模組經過調優效能非常高, 而且現在又很多硬體本身支援加密功能,比如intel的CPU支援AES加密指令,那些核心的那幫人知道更好如何利用這些硬體更快的完成加密功能的, 他們寫的這些硬體的驅動在drivers/crypto目錄裡. 所以如果我們能在使用者

系統技術業餘研究 » Literal XML in Erlang with parse_transform/2

One of the things I dislike about Erlang is that it severely impairs bragging opportunities. Yesterday I wrote a module that allows writing literal

系統技術業餘研究

ItPub寫的文章“2017 年度 DB-Engines 資料庫冠軍得主:PostgreSQL 封王!”, 點選 這裡 進一步閱讀 升的最快的幾個資料庫,我簡單的無責任點評: PG資料庫是很老的資料庫,不過這幾年冉冉升起,因為是學院派的,有很好的學術和智力的支援,一直以來在資料庫的體系結構,程式碼

系統技術業餘研究 » MySQL資料庫架構的演化觀察

MySQL資料庫架構的演化觀察 December 14th, 2017 Categories: 資料庫 Tags: mysql

系統技術業餘研究 » inet_dist_connect_options

Erlang 17.5版本引入了inet_dist_{listen,connect}_options,對於結點間的互聯socket可以有更精細的控制,RPC的時候效能可以微調: raimo/inet_tcp_dist-priority-option/OTP-12476: Document ke

系統技術業餘研究 » 推薦工作機會

最後更新時間:2014/11/28 請賜簡歷至:[email protected], 感謝您對加入我們公司有興趣,我們希望能早日和您共事。 以下幾個職位1年內有效,歡迎內部轉崗:
 資深資料工程師 公司:阿里(核心系統資料庫組) 工作地點:杭州(西溪園區) 崗位描述: 分析雲服務產生的海

系統技術業餘研究 » 新的工作和研究方向

和大家更新下: 做了將近8年資料庫後,我的工作和研究方向將會延伸到虛擬化和計算相關的雲服務,希望能夠和大家一起進步,Happy New Year! 預祝大家玩得開心! Post Footer automatically generated by wp-posturl plugin for w

系統技術業餘研究 » 叢集引入inet_dist_{listen,connect}_options更精細引數微調

Erlang 17.5版本引入了inet_dist_{listen,connect}_options,對於結點間的互聯socket可以有更精細的控制,RPC的時候效能可以微調: raimo/inet_tcp_dist-priority-option/OTP-12476: Document ke

系統技術業餘研究 » 2017升的最快的幾個資料庫無責任點評

ItPub寫的文章“2017 年度 DB-Engines 資料庫冠軍得主:PostgreSQL 封王!”, 點選 這裡 進一步閱讀 升的最快的幾個資料庫,我簡單的無責任點評: PG資料庫是很老的資料庫,不過這幾年冉冉升起,因為是學院派的,有很好的學術和智力的支援,一直以來在資料庫的體系結構,程式碼

系統技術業餘研究 » Erlang 17.5引入+hpds命令列控制程序預設字典大小

Erlang 17.5釋出引入控制程序預設字典大小的命令列引數: Erlang/OTP 17.5 has been released Written by Henrik, 01 Apr 2015 Some highlights of the release are: ERTS: Added co

系統技術業餘研究 » inet_dist_listen_options

Erlang 17.5版本引入了inet_dist_{listen,connect}_options,對於結點間的互聯socket可以有更精細的控制,RPC的時候效能可以微調: raimo/inet_tcp_dist-priority-option/OTP-12476: Document ke

系統技術業餘研究 » 老生常談: ulimit問題及其影響

ulimit最初設計是用來限制程序對資源的使用情況的,因為早期的系統系統資源包括記憶體,CPU都是非常有限的,系統要保持公平,就要限制大家的使用,以達到一個相對公平的環境。以下是典型的機器預設的限制情況: $ ulimit -a core file size (blocks,

系統技術業餘研究 » 求賢帖

原創文章,轉載請註明: 轉載自系統技術非業餘研究 本文連結地址: 求賢帖 作為一個優秀的工程師,你其實不缺少才華,你缺少的是神一樣的隊友、充滿挑戰的世界級技術難題,和一個可以施展自己才華的大舞臺。加入阿里核心系統資料庫開發團隊吧,你缺的這裡都有。來吧,戳這裡,給我們見識你的機會:http://b

系統技術業餘研究 » Erlang R16B03釋出,R17已發力

Erlang R16B03釋出了,通常03版本是bug fix版本,進入生產版本,官方的說明如下: OTP R16B03 is a service release with mostly a number of small corrections and user contributions. B

系統技術業餘研究 » Erlang R13B04 Installation

R13B04後erlang的原始碼編譯為了考慮移植性,就改變了編譯方式,以下是官方wiki上的安裝文件: 1. Cloning Here are the basic steps to build Erlang/OTP in the Git repository. Start by cloning:

系統技術業餘研究 » Understanding Linux CPU Load 資料彙總

最近關注線上CPU load的人挺多,很多人覺得load太高系統就有問題,就想各種辦法來折騰。其實在我看來load只是系統CPU執行佇列的在執行程序數的近似值, 如下圖: 對於Unix發展的初期,機器的效能比較差,CPU核數也少,參考意義比較大。現在的機器都是非常強悍的,CPU,記憶體,IO各個

系統技術業餘研究 » Erlang R15的記憶體delayed dealloc特性對訊息密集型程式的影響

在新的NUMA體系結構下,每個CPU都有自己的本地記憶體,如果要訪問其他CPU的記憶體,那算remote了,要走CPU之間的QPI通道,通常這樣速度會有40%的下降。 那麼對於多執行緒的程式來講,這個硬體的變化對軟體也有很大的影響。在多執行緒程式裡面,通常一個執行緒會為一個物件分配記憶體,然後把這

系統技術業餘研究 » Erlang R17新特性淺評

Erlang R17RC2 原始碼已經就緒, 參見 這裡 後續版本的釋出時間,官方的時間安排參見 這裡,摘抄如下: Preliminary dates for the upcoming release: Release: erts, emu,comp |Code stop

系統技術業餘研究 » Erlang R16支援帶顏色的控制檯

Erlang通過fix tty驅動的過濾,在R16版本支援帶顏色的控制檯,這個特性在我們做各種監控工具高亮非常有幫助,參見R16的Readme: Support ANSI in console Unix platforms will no longer filter control sequenc