Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
c111a721
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
c111a721
编写于
3月 25, 2008
作者:
N
Neil Conway
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update documentation for recent DTrace changes. Patch from Robert Lor.
上级
220db7cc
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
131 addition
and
81 deletion
+131
-81
doc/src/sgml/installation.sgml
doc/src/sgml/installation.sgml
+3
-3
doc/src/sgml/monitoring.sgml
doc/src/sgml/monitoring.sgml
+128
-78
未找到文件。
doc/src/sgml/installation.sgml
浏览文件 @
c111a721
<
!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.30
4 2008/03/10 20:06:27 tgl
Exp $ -->
<
!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.30
5 2008/03/25 22:50:27 neilc
Exp $ -->
<
chapter
id
=
"installation"
>
<
title
><
![%standalone-include[<productname>PostgreSQL</>]]>
...
...
@@ -1193,8 +1193,8 @@ su - postgres
<
primary
>
DTrace
</
primary
>
</
indexterm
>
Compiles
with
support
for
the
dynamic
tracing
tool
DTrace
.
Operating
system
support
for
DTrace
is
currently
only
available
in
Solaris
.
Operating
system
support
for
DTrace
is
currently
available
in
Solaris
and
Mac
OS
X
Leopard
.
</
para
>
<
para
>
...
...
doc/src/sgml/monitoring.sgml
浏览文件 @
c111a721
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.5
5 2007/11/28 15:42:31 petere
Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.5
6 2008/03/25 22:50:27 neilc
Exp $ -->
<chapter id="monitoring">
<title>Monitoring Database Activity</title>
...
...
@@ -947,26 +947,26 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
</para>
<para>
A number of
trace points, often called probes,
are already inserted
into the source code. By default these probes are
disabled, and
the user needs to explicitly tell the configure script to make th
e
probes available in <productname>PostgreSQL</productname>.
A number of
probes or trace points
are already inserted
into the source code. By default these probes are
not compiled into the
binary, and the user needs to explicitly tell the configure script to mak
e
the
probes available in <productname>PostgreSQL</productname>.
</para>
<para>
Currently, only the DTrace utility is supported, which is
only
available
on Solaris Express
and Solaris 10+. It is expected that DTrace will
be available in the future on FreeBSD and Mac OS X
.
Currently, only the DTrace utility is supported, which is available
on Solaris Express
, Solaris 10, and Mac OS X Leopard. It is expected that
DTrace will be available in the future on FreeBSD
.
Supporting other dynamic tracing utilities is theoretically possible by
changing the definitions for the
<literal>PG_TRACE</>
macros in
<filename>src/include/
pg_trace
.h</>.
changing the definitions for the macros in
<filename>src/include/
utils/probes
.h</>.
</para>
<sect2 id="compiling-for-trace">
<title>Compiling for Dynamic Tracing</title>
<para>
By default,
trace points are disabled
, so you will need to
By default,
probes are not available
, so you will need to
explicitly tell the configure script to make the probes available
in <productname>PostgreSQL</productname>. To include DTrace support
specify <option>--enable-dtrace</> to configure. See <xref
...
...
@@ -975,16 +975,16 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
</sect2>
<sect2 id="trace-points">
<title>Built-in
Trace Point
s</title>
<title>Built-in
Probe
s</title>
<para>
A few standard
trace point
s are provided in the source code
A few standard
probe
s are provided in the source code
(of course, more can be added as needed for a particular problem).
These are shown in <xref linkend="trace-point-table">.
</para>
<table id="trace-point-table">
<title>Built-in
Trace Point
s</title>
<title>Built-in
Probe
s</title>
<tgroup cols="3">
<thead>
<row>
...
...
@@ -996,67 +996,67 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
<tbody>
<row>
<entry>transaction
__
start</entry>
<entry>transaction
-
start</entry>
<entry>(int transactionId)</entry>
<entry>The start of a new transaction.</entry>
</row>
<row>
<entry>transaction
__
commit</entry>
<entry>transaction
-
commit</entry>
<entry>(int transactionId)</entry>
<entry>The successful completion of a transaction.</entry>
</row>
<row>
<entry>transaction
__
abort</entry>
<entry>transaction
-
abort</entry>
<entry>(int transactionId)</entry>
<entry>The unsuccessful completion of a transaction.</entry>
</row>
<row>
<entry>lwlock
__
acquire</entry>
<entry>lwlock
-
acquire</entry>
<entry>(int lockid, int mode)</entry>
<entry>An LWLock has been acquired.</entry>
</row>
<row>
<entry>lwlock
__
release</entry>
<entry>lwlock
-
release</entry>
<entry>(int lockid, int mode)</entry>
<entry>An LWLock has been released.</entry>
</row>
<row>
<entry>lwlock
__
startwait</entry>
<entry>lwlock
-
startwait</entry>
<entry>(int lockid, int mode)</entry>
<entry>An LWLock was not immediately available and a backend
has begun to wait for the lock to become available.
</entry>
</row>
<row>
<entry>lwlock
__
endwait</entry>
<entry>lwlock
-
endwait</entry>
<entry>(int lockid, int mode)</entry>
<entry>A backend has been released from its wait for an LWLock.
</entry>
</row>
<row>
<entry>lwlock
__
condacquire</entry>
<entry>lwlock
-
condacquire</entry>
<entry>(int lockid, int mode)</entry>
<entry>An LWLock was successfully acquired when the caller specified no
waiting.
</entry>
</row>
<row>
<entry>lwlock
__condacquire__
fail</entry>
<entry>lwlock
-condacquire-
fail</entry>
<entry>(int lockid, int mode)</entry>
<entry>An LWLock was not successfully acquired when the caller specified
no waiting.
</entry>
</row>
<row>
<entry>lock
__
startwait</entry>
<entry>lock
-
startwait</entry>
<entry>(int locktag_field2, int lockmode)</entry>
<entry>A request for a heavyweight lock (lmgr lock) has begun to wait
because the lock is not available.
</entry>
</row>
<row>
<entry>lock
__
endwait</entry>
<entry>lock
-
endwait</entry>
<entry>(int locktag_field2, int lockmode)</entry>
<entry>A request for a heavyweight lock (lmgr lock) has finished waiting
(i.e., has acquired the lock).
...
...
@@ -1068,7 +1068,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
</sect2>
<sect2 id="using-trace-points">
<title>Using
Trace Point
s</title>
<title>Using
Probe
s</title>
<para>
The example below shows a DTrace script for analyzing transaction
...
...
@@ -1096,11 +1096,9 @@ postgresql$1:::transaction-commit
self->ts=0;
}
</programlisting>
Note how the double underline in trace point names needs to
be replaced by a hyphen when using D script.
When executed, the example D script gives output such as:
<screen>
# ./txn_count.d `pgrep -n postgres`
# ./txn_count.d `pgrep -n postgres`
or ./txn_count.d <PID>
^C
Start 71
...
...
@@ -1109,7 +1107,7 @@ Total time (ns) 2312105013
</screen>
</para>
<para>
You should remember that
trace program
s need to be carefully written and
You should remember that
DTrace script
s need to be carefully written and
debugged prior to their use, otherwise the trace information collected might
be meaningless. In most cases where problems are found it is the
instrumentation that is at fault, not the underlying system. When
...
...
@@ -1119,30 +1117,86 @@ Total time (ns) 2312105013
</sect2>
<sect2 id="defining-trace-points">
<title>Defining
Trace Point
s</title>
<title>Defining
New Probe
s</title>
<para>
New trace points can be defined within the code wherever the developer
desires, though this will require a recompilation.
New probes can be defined within the code wherever the developer
desires, though this will require a recompilation. Below are the steps
for inserting new probes:
</para>
<para>
A trace point can be inserted by using one of the
trace macros. These are chosen according to how many variables will
be made available for inspection at that trace point. Tracing the
occurrence of an event can be achieved with a single line, using
just the trace point name, e.g.:
<programlisting>
PG_TRACE (my__new__trace__point);
</programlisting>
More complex trace points can be provided with one or more variables
for inspection by the dynamic tracing utility by using the
<literal>PG_TRACE</><replaceable>n</> macro that corresponds to the number
of parameters after the trace point name:
<procedure>
<step>
<para>
Decide on probe names and data to be made available through the probes
</para>
</step>
<step>
<para>
Add the probe definitons to <filename>src/backend/src/utils/probes.d</>
</para>
</step>
<step>
<para>
Insert a one-line probe macros at the desired locations in the source code
</para>
</step>
<step>
<para>
Recompile and verify that the new probes are available
</para>
</step>
</procedure>
<formalpara>
<title>Example:</title>
<para>
Here is an example of how you would add a probe to trace all new transactions by transaction ID.
</para>
</formalpara>
<procedure>
<step>
<para>
Name the probe transaction-start and give it a parameter of type integer (type of transaction ID)
</para>
</step>
<step>
<para>
Add <quote>probe transaction__start(int);</quote> to
<filename>src/backend/src/utils/probes.d</>, and it should look like the following:
<programlisting>
PG_TRACE3 (my__complex__event, varX, varY, varZ);
provider postgresql {
...
probe transaction__start(int);
...
};
</programlisting>
The definition of the transaction__start trace point is shown below:
Note the use of the double underline in the probe name. In the DTrace
script, the double underline needs to be replaced with a hyphen.
</para>
<para>
You should take care that the data types specified for the probe arguments
match the data types of the variables used in the macro. Otherwise, you
will get compilation errors.
</para>
</step>
<step>
<para>
At compile time, transaction__start is converted to a macro called
TRACE_POSTGRESQL_TRANSACTION_START, and it resides in
<filename>src/backend/src/utils/probes.h</>. Before recompiling, add
the single line macro to the appropriate location in the source code.
In this case, it looks like the following:
</para>
<para>
<programlisting>
static void
StartTransaction(void)
...
...
@@ -1150,44 +1204,40 @@ StartTransaction(void)
...
/*
* generate a new transaction id
* Advertise it in the proc array. We assume assignment of
* LocalTransactionID is atomic, and the backendId should be set already.
*/
s->transactionId = GetNewTransactionId(false);
Assert(MyProc->backendId == vxid.backendId);
MyProc->lxid = vxid.localTransactionId;
XactLockTableInsert(s->transactionId);
PG_TRACE1(transaction__start, s->transactionId);
TRACE_POSTGRESQL_TRANSACTION_START(vxid.localTransactionId);
...
}
</programlisting>
Note how the transaction ID is made available to the dynamic tracing
utility.
</para>
Note how the transaction ID is made available to the dynamic tracing
utility.
</para>
</step>
<para>
The dynamic tracing utility might require you to further define these trace
points. For example, DTrace requires you to add new probes to the file
<filename>src/backend/utils/probes.d</> as shown here:
<programlisting>
provider postgresql {
...
probe transaction__start(int);
...
};
</programlisting>
</para>
<step>
<para>
After recompiling and running the new binary, check that your newly added
probe is available by executing the following DTrace command, and you
should see similar output.
<screen>
# dtrace -ln transaction-start
ID PROVIDER MODULE FUNCTION NAME
18705 postgresql49878 postgres StartTransactionCommand transaction-start
18755 postgresql49877 postgres StartTransactionCommand transaction-start
18805 postgresql49876 postgres StartTransactionCommand transaction-start
18855 postgresql49875 postgres StartTransactionCommand transaction-start
18986 postgresql49873 postgres StartTransactionCommand transaction-start
</screen>
</para>
</step>
</procedure>
<para>
You should take care that the data types specified for the probe arguments
match the data types of the variables used in the <literal>PG_TRACE</>
macro. This is not checked at compile time. You can check that your newly
added trace point is available by recompiling, then running the new binary,
and as root, executing a DTrace command such as:
<programlisting>
dtrace -l -n transaction-start
</programlisting>
</para>
</sect2>
</sect1>
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录