dtrace of a Samba nbench run shows
Hi folks, I have been using dtrace, and particularly procsystime, to measure Samba system call usage stuff. This is what I get: cs-cc1# ./procsystime -n smbd Tracing... Hit Ctrl-C to end... ^C Elapsed Times for processes smbd, SYSCALL TIME (ns) sysarch 1492 thr_self 2636 __getcwd 5695 getsockname 5778 accept 6952 sendto 8019 getpeername 8273 setsockopt 9394 pipe 13567 kenv 15151 umask 16400 sigaction 23504 msync 24068 mprotect 26960 getpid 29888 socket 38078 dup2 42323 chdir 49643 getgroups 74299 wait4 108578 connect 148649 sigprocmask 150443 __sysctl 215389 getegid 243731 mmap 257379 setregid 260529 setgroups 270894 thr_new 376349 munmap 428773 fork 511601 sigreturn 668402 chown 703765 getuid 821748 chmod1175632 kill1230340 write1281535 geteuid1918738 rmdir2376245 mkdir2516070 fsync3346330 setreuid5205649 gettimeofday9212264 lseek9336442 pathconf 18606662 statfs 29714064 access 30073540 fstatfs 31360178 lstat 33902417 extattr_get_fd 38793210 fchmod 147266506 rename 156300564 fstat 234898224 utimes 237551881 getdirentries 253926535 extattr_set_link 371269699 pread 671050763 unlink 768327954 pwrite 825201124 fstatat 866823356 clock_gettime 1257134991 writev 1984839112 read 2922189298 close 6180434183 fcntl 7849631277 stat 7872399963 extattr_get_file 7887564205 ioctl 9034605338 open23145865857 select 274329462364 poll 753606057912 _umtx_op 1097794513187 So, what is _umtx_op? I guess I have to move to kqueue as well. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
DTrace support in Postgresql not working
Hi guys, I have a system running 10-CURRENT (r250217) which I've built Postgresql 9.2.4 with DTrace support enabled on a VM running 9.1-STABLE (r250009) which I'm unable to build it on. On 10-CURRENT the problem is that dtrace -l does not list the postgresql provider. My make.conf on both system is STRIP= CFLAGS+=-fno-omit-frame-pointer on 9.1-STABLE the build fails with Assertion failed: (nrc == rc), function _libelf_resync_sections, file /usr/src/lib/libelf/elf_update.c, line 341. gmake: *** [utils/probes.o] Abort trap: 6 (core dumped) gmake: *** Deleting file 'utils/probes.o' *** [do-build] Error code 2 on 10-CURRENT there are warnings generated but the build completes installs pgstat.c:2538:36: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_STATEMENT_STATUS(cmd_str); ../../../src/include/utils/probes.h:424:42: note: expanded from macro 'TRACE_POSTGRESQL_STATEMENT_STATUS' __dtrace_postgresql___statement__status(arg0) ../../../src/include/utils/probes.h:803:59: note: passing argument to parameter here extern void __dtrace_postgresql___statement__status(char *); postgres.c:559:37: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_PARSE_START(query_string); ../../../src/include/utils/probes.h:316:44: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_PARSE_START' __dtrace_postgresql___query__parse__start(arg0) ../../../src/include/utils/probes.h:731:61: note: passing argument to parameter here extern void __dtrace_postgresql___query__parse__start(char *); postgres.c:582:36: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_PARSE_DONE(query_string); ../../../src/include/utils/probes.h:307:43: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_PARSE_DONE' __dtrace_postgresql___query__parse__done(arg0) ../../../src/include/utils/probes.h:725:60: note: passing argument to parameter here extern void __dtrace_postgresql___query__parse__done(char *); postgres.c:603:39: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_START(query_string); ../../../src/include/utils/probes.h:352:46: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_START' __dtrace_postgresql___query__rewrite__start(arg0) ../../../src/include/utils/probes.h:755:63: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__start(char *); postgres.c:621:38: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_DONE(query_string); ../../../src/include/utils/probes.h:343:45: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_DONE' __dtrace_postgresql___query__rewrite__done(arg0) ../../../src/include/utils/probes.h:749:62: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__done(char *); postgres.c:643:39: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_START(query_string); ../../../src/include/utils/probes.h:352:46: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_START' __dtrace_postgresql___query__rewrite__start(arg0) ../../../src/include/utils/probes.h:755:63: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__start(char *); postgres.c:670:38: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_REWRITE_DONE(query_string); ../../../src/include/utils/probes.h:343:45: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_REWRITE_DONE' __dtrace_postgresql___query__rewrite__done(arg0) ../../../src/include/utils/probes.h:749:62: note: passing argument to parameter here extern void __dtrace_postgresql___query__rewrite__done(char *); ^ postgres.c:845:31: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] TRACE_POSTGRESQL_QUERY_START(query_string); ../../../src/include/utils/probes.h:361:37: note: expanded from macro 'TRACE_POSTGRESQL_QUERY_START' __dtrace_postgresql___query__start(arg0) ../../../src/include/utils/probes.h:761:54: note: passing argument to parameter here extern void __dtrace_postgresql___query__start(char *); postgres.c:1130:30: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers
Anyone else seeing problems with dtrace and cyclic in 9.1-stable???
Greetings all, Has anyone else seen these errors during 9.1-stable boot... Jan 16 08:12:05 sleipnir kernel: link_elf_obj: symbol cyclic_clock_func undefined Jan 16 08:12:05 sleipnir kernel: KLD file cyclic.ko - could not finalize loading Jan 16 08:12:05 sleipnir kernel: KLD file dtrace.ko - cannot find dependency cyclic This began around 14th - 15th Jan 2013. I have no recollection of seeing these symptoms before. Cheers, // jau .--- ..- -.- -.- .-.- .-.-.-..- -.- -.- --- -. . -. /Jukka A. Ukkonen, Oxit Ltd, Finland /__ M.Sc. (sw-eng cs)(Phone) +358-500-606-671 / Internet: Jukka.Ukkonen(a)Oxit.Fi /Internet: jau(a)iki.fi v .--- .- ..- ...-.- .. -.- .. .-.-.- ..-. .. + + + + My opinions are mine and mine alone, not my employers. + + + + ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: DTrace userland
Here's another way to cause a kernel panic:
[marca@freebsd9-0 ~]$ sudo kldload dtraceall
[marca@freebsd9-0 ~]$ cat -n test.c
1 #include stdio.h
2
3 int main()
4 {
5sleep(15);
6
7FILE *fp = fopen(hello.txt, w);
8fprintf(fp, Here I am at %s:%d.\n, __FILE__, __LINE__);
9fclose(fp);
10 }
[marca@freebsd9-0 ~]$ gcc test.c -o test
[marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c ./test
dtrace: description 'pid$target:test:main:entry' matched 1 probe
dtrace: buffer size lowered to 1m
CPU IDFUNCTION:NAME
0 43030 main:entry
(Kernel panic! After reboot)
[marca@freebsd9-0 ~]$ cat hello.txt
Here I am at test.c:8.
Interestingly, the crash doesn't occur until after the sleep and the
fprintf call, so it looks the kernel panic happens as a result of the
traced process _exiting_...
Marc
On Mon, Feb 27, 2012 at 11:10 PM, Marc Abramowitz msabr...@gmail.comwrote:
Another strange behavior:
[Tab 1]
$ /bin/sleep 300
[1] 1806
[Tab 2]
$ sudo dtrace -n 'pid1806:sleep::entry'
$ echo $?
158
[Tab 1]
[1]+ Killed: 9 /bin/sleep 300
Something seems very wrong that DTrace is killing processes and causing
kernel panics.
Marc
On Mon, Feb 27, 2012 at 10:22 PM, Marc Abramowitz msabr...@gmail.comwrote:
I'm using FreeBSD 9.0 on amd64 in VMware Fusion and trying to DTrace
userland programs. I think I must be doing something wrong.
I recompiled my kernel and world, following the instructions at
http://wiki.freebsd.org/DTrace and I've read
http://wiki.freebsd.org/DTrace/userland:
The test.c pid provider example worked fine for me:
$ sudo dtrace -s pid.d -c ./test
dtrace: script 'pid.d' matched 2 probes
dtrace: buffer size lowered to 1m
CPU IDFUNCTION:NAME
0 43030 main:entry
0 43031 sleep:entry
0 43031 sleep:entry
0 43031 sleep:entry
As does a simple probe of test.c specified with the -n option:
[marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c
./test
dtrace: description 'pid$target:test:main:entry' matched 1 probe
dtrace: buffer size lowered to 1m
CPU IDFUNCTION:NAME
0 43030 main:entry
When I start trying to dtrace other programs, things don't go so well...
$ sudo dtrace -n :::entry -c /usr/local/bin/python
Python 2.4.5 (#2, Dec 5 2011, 15:19:09)
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9
Type help, copyright, credits or license for more information.
import os
os.getpid()
1603
dtrace: failed to control pid 1603: process exited with status 0
$ sudo dtrace -n 'pid$target:::entry' -c '/bin/cat hello_world.txt'
dtrace: description 'pid$target:::entry' matched 3315 probes
dtrace: buffer size lowered to 1m
CPU IDFUNCTION:NAME
0 43448 _rtld_bind:entry
0 43903 rlock_acquire:entry
0 43125def_thread_set_flag:entry
(Had to hit Ctrl-C to exit; it never displayed hello_world.txt to stdout)
[marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo make install
...
[marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n
'pid$target:::entry' -c '/usr/local/bin/gcat config.log'
dtrace: description 'pid$target:::entry' matched 3823 probes
dtrace: buffer size lowered to 1m
CPU IDFUNCTION:NAME
0 43524 _rtld_bind:entry
0 43979 rlock_acquire:entry
0 43201def_thread_set_flag:entry
^C
$ sudo dtrace -n 'pid$target:cat:main:entry' -c '/bin/cat hello_world.txt'
causes a kernel panic.
According to the core.txt file, it was a Fatal trap 10: trace trap while
in kernel mode and here's the KDB backtrace:
KDB: stack backtrace:
#0 0x8089025e at kdb_backtrace+0x5e
#1 0x80858ce7 at panic+0x187
#2 0x80b4bf20 at trap_fatal+0x290
#3 0x80b4c540 at trap+0x180
#4 0x80b36963 at calltrap+0x8
#5 0x8162583d at dtrace_assfail+0x2d
#6 0x8188aa2e at fasttrap_provider_free+0x1de
#7 0x8188ad13 at fasttrap_pid_cleanup_cb+0x1c3
#8 0x8086dfa1 at softclock+0x3a1
#9 0x8082d724 at intr_event_execute_handlers+0x104
#10 0x8082eee4 at ithread_loop+0xa4
#11 0x8082a34f at fork_exit+0x11f
#12 0x80b36e8e at fork_trampoline+0xe
[marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n
'pid$target:gcat::entry' -c '/usr/local/bin/gcat config.log'
(Another kernel panic)
I can provide full crash dumps if necessary.
Any idea what's going on here?
Cheers,
Marc
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: DTrace userland
On Tue, Feb 28, 2012 at 12:58 PM, Rui Paulo rpa...@freebsd.org wrote: Please file a PR. These are problems that we have to fix. I submitted a PR for the kernel panic at http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 Marc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: DTrace userland
On Tue, Feb 28, 2012 at 12:24 PM, Marc Abramowitz msabr...@gmail.comwrote: Here's another way to cause a kernel panic: [marca@freebsd9-0 ~]$ sudo kldload dtraceall ... [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c ./test dtrace: description 'pid$target:test:main:entry' matched 1 probe dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43030 main:entry (Kernel panic! After reboot) I submitted a PR for this kernel panic at http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 Marc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
DTrace userland
I'm using FreeBSD 9.0 on amd64 in VMware Fusion and trying to DTrace userland programs. I think I must be doing something wrong. I recompiled my kernel and world, following the instructions at http://wiki.freebsd.org/DTrace and I've read http://wiki.freebsd.org/DTrace/userland: The test.c pid provider example worked fine for me: $ sudo dtrace -s pid.d -c ./test dtrace: script 'pid.d' matched 2 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43030 main:entry 0 43031 sleep:entry 0 43031 sleep:entry 0 43031 sleep:entry As does a simple probe of test.c specified with the -n option: [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c ./test dtrace: description 'pid$target:test:main:entry' matched 1 probe dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43030 main:entry When I start trying to dtrace other programs, things don't go so well... $ sudo dtrace -n :::entry -c /usr/local/bin/python Python 2.4.5 (#2, Dec 5 2011, 15:19:09) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 Type help, copyright, credits or license for more information. import os os.getpid() 1603 dtrace: failed to control pid 1603: process exited with status 0 $ sudo dtrace -n 'pid$target:::entry' -c '/bin/cat hello_world.txt' dtrace: description 'pid$target:::entry' matched 3315 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43448 _rtld_bind:entry 0 43903 rlock_acquire:entry 0 43125def_thread_set_flag:entry (Had to hit Ctrl-C to exit; it never displayed hello_world.txt to stdout) [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo make install ... [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n 'pid$target:::entry' -c '/usr/local/bin/gcat config.log' dtrace: description 'pid$target:::entry' matched 3823 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43524 _rtld_bind:entry 0 43979 rlock_acquire:entry 0 43201def_thread_set_flag:entry ^C $ sudo dtrace -n 'pid$target:cat:main:entry' -c '/bin/cat hello_world.txt' causes a kernel panic. According to the core.txt file, it was a Fatal trap 10: trace trap while in kernel mode and here's the KDB backtrace: KDB: stack backtrace: #0 0x8089025e at kdb_backtrace+0x5e #1 0x80858ce7 at panic+0x187 #2 0x80b4bf20 at trap_fatal+0x290 #3 0x80b4c540 at trap+0x180 #4 0x80b36963 at calltrap+0x8 #5 0x8162583d at dtrace_assfail+0x2d #6 0x8188aa2e at fasttrap_provider_free+0x1de #7 0x8188ad13 at fasttrap_pid_cleanup_cb+0x1c3 #8 0x8086dfa1 at softclock+0x3a1 #9 0x8082d724 at intr_event_execute_handlers+0x104 #10 0x8082eee4 at ithread_loop+0xa4 #11 0x8082a34f at fork_exit+0x11f #12 0x80b36e8e at fork_trampoline+0xe [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n 'pid$target:gcat::entry' -c '/usr/local/bin/gcat config.log' (Another kernel panic) I can provide full crash dumps if necessary. Any idea what's going on here? Cheers, Marc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: DTrace userland
Another strange behavior: [Tab 1] $ /bin/sleep 300 [1] 1806 [Tab 2] $ sudo dtrace -n 'pid1806:sleep::entry' $ echo $? 158 [Tab 1] [1]+ Killed: 9 /bin/sleep 300 Something seems very wrong that DTrace is killing processes and causing kernel panics. Marc On Mon, Feb 27, 2012 at 10:22 PM, Marc Abramowitz msabr...@gmail.comwrote: I'm using FreeBSD 9.0 on amd64 in VMware Fusion and trying to DTrace userland programs. I think I must be doing something wrong. I recompiled my kernel and world, following the instructions at http://wiki.freebsd.org/DTrace and I've read http://wiki.freebsd.org/DTrace/userland: The test.c pid provider example worked fine for me: $ sudo dtrace -s pid.d -c ./test dtrace: script 'pid.d' matched 2 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43030 main:entry 0 43031 sleep:entry 0 43031 sleep:entry 0 43031 sleep:entry As does a simple probe of test.c specified with the -n option: [marca@freebsd9-0 ~]$ sudo dtrace -n 'pid$target:test:main:entry' -c ./test dtrace: description 'pid$target:test:main:entry' matched 1 probe dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43030 main:entry When I start trying to dtrace other programs, things don't go so well... $ sudo dtrace -n :::entry -c /usr/local/bin/python Python 2.4.5 (#2, Dec 5 2011, 15:19:09) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd9 Type help, copyright, credits or license for more information. import os os.getpid() 1603 dtrace: failed to control pid 1603: process exited with status 0 $ sudo dtrace -n 'pid$target:::entry' -c '/bin/cat hello_world.txt' dtrace: description 'pid$target:::entry' matched 3315 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43448 _rtld_bind:entry 0 43903 rlock_acquire:entry 0 43125def_thread_set_flag:entry (Had to hit Ctrl-C to exit; it never displayed hello_world.txt to stdout) [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo make install ... [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n 'pid$target:::entry' -c '/usr/local/bin/gcat config.log' dtrace: description 'pid$target:::entry' matched 3823 probes dtrace: buffer size lowered to 1m CPU IDFUNCTION:NAME 0 43524 _rtld_bind:entry 0 43979 rlock_acquire:entry 0 43201def_thread_set_flag:entry ^C $ sudo dtrace -n 'pid$target:cat:main:entry' -c '/bin/cat hello_world.txt' causes a kernel panic. According to the core.txt file, it was a Fatal trap 10: trace trap while in kernel mode and here's the KDB backtrace: KDB: stack backtrace: #0 0x8089025e at kdb_backtrace+0x5e #1 0x80858ce7 at panic+0x187 #2 0x80b4bf20 at trap_fatal+0x290 #3 0x80b4c540 at trap+0x180 #4 0x80b36963 at calltrap+0x8 #5 0x8162583d at dtrace_assfail+0x2d #6 0x8188aa2e at fasttrap_provider_free+0x1de #7 0x8188ad13 at fasttrap_pid_cleanup_cb+0x1c3 #8 0x8086dfa1 at softclock+0x3a1 #9 0x8082d724 at intr_event_execute_handlers+0x104 #10 0x8082eee4 at ithread_loop+0xa4 #11 0x8082a34f at fork_exit+0x11f #12 0x80b36e8e at fork_trampoline+0xe [marca@freebsd9-0 /usr/ports/sysutils/coreutils]$ sudo dtrace -n 'pid$target:gcat::entry' -c '/usr/local/bin/gcat config.log' (Another kernel panic) I can provide full crash dumps if necessary. Any idea what's going on here? Cheers, Marc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FreeBSD 9.0-RC1 and DTrace Userland Probes
I upgraded my box so that I can rock the userland DTrace probes. I have been
following the example at: http://wiki.freebsd.org/DTrace/userland
When I am ready to build my test probe, I run 'make' as the example shows. The
result of that is the following:
cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector -c test.c
cc -O2 -pipe -fno-omit-frame-pointer -std=gnu99 -fstack-protector -o test
test.o
test.o: In function `main':
test.c:(.text+0x29): undefined reference to `__dtrace_prober___probe__before'
test.c:(.text+0x45): undefined reference to `__dtrace_prober___probe__after'
*** Error code 1
Same idea as the example, but I just changed the names around. Well, so I
thought I would be smart and compile just the object file with:
dtrace -G -s prober.d
And that stalls. `truss` is showing that dtrace is stalling after a mmap, with
what looks to be a valid returned address.
/* provider.d */
provider prober {
probe probe__before(char *);
probe probe__after(char *);
};
/* test.c */
#include unistd.h
#include sys/time.h
#include provider.h
int main(void)
{
struct timeval tv;
for ( ;; )
{
sleep(1);
PROBER_PROBE_BEFORE(foo);
gettimeofday(tv, NULL);
PROBER_PROBE_AFTER(bar);
}
return 0;
}
Any insight would be wonderful.
Thanks!
-Matt
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dtrace function arguments
In the last episode (Aug 15), Ashley Williams said: I'm looking for a faster way to get more verbose information about dtrace function arguments. For example. Say, I want to know more about the funciton syscall:freebsd32:connect:return. I'd start off by doing a listing: # dtrace -lvf connect [...] Argument Types args[0]: int args[1]: caddr_t args[2]: int From the output of the listing, I can see quite clearly there are three arguments for this function - int, caddr_t, int; but I can't see from this output what these refer to. I could probably find the answer by digging through header files and source code, but this isn't exactly efficient. Is there an easier way to find more information about functions (not specifically this one)? All syscalls should have a manpage documenting their arguments, and some common kernel functions have manpages in section 9 (so man 9 malloc will get the kernel version, for example), but most kernel functions aren't officially documented apart from comments in the source. http://fxr.watson.org/ is a handy resource for finding where in the source tree a given function is defined. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
dtrace function arguments
I'm looking for a faster way to get more verbose information about dtrace function arguments. For example. Say, I want to know more about the funciton syscall:freebsd32:connect:return. I'd start off by doing a listing: # dtrace -lvf connect -snip--- 43723syscall freebsd32 connect return Probe Description Attributes Identifier Names: Private Data Semantics: Private Dependency Class: Unknown Argument Attributes Identifier Names: Private Data Semantics: Private Dependency Class: ISA Argument Types args[0]: int args[1]: caddr_t args[2]: int From the output of the listing, I can see quite clearly there are three arguments for this function - int, caddr_t, int; but I can't see from this output what these refer to. I could probably find the answer by digging through header files and source code, but this isn't exactly efficient. Is there an easier way to find more information about functions (not specifically this one)? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[dtrace] attaching to a PID
Does anyone else see the following crash?
$ sh -c 'sleep 60 dtrace -P syscall -p $!'
dtrace: description 'syscall' matched 2092 probes
Assertion failed: (dpr != NULL), file
.../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, line 751.
Exit 134
Also triggers without specifying PID, e.g. by ustack()
$ dtrace -P 'syscall { @[probefunc,ustack()] = count(); }'
Not sure if I hosed my environment.
--
FreeBSD 9.0-CURRENT #0 r223522M amd64
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: DTrace in RELEASE?
Does anyone know if it's likely DTrace will ever make it into the generic RELEASEs? Maybe, at least in part. One of the developers has asked that the hooks needed for dtrace be included by default in upcoming releases: http://lists.freebsd.org/pipermail/freebsd-arch/2011-March/011157.html b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
DTrace in RELEASE?
Does anyone know if it's likely DTrace will ever make it into the generic RELEASEs? Tom ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
dtrace/userland causing segmentation fault
hello freebsd gurus...
i'm currently using FreeBSD 9.0-CURRENT-201101...
dtrace is enable and working
[root@ ~]# dtrace -l | tail -5
41473profile tick-1000
41474profile tick-5000
41475profile tick-1sec
41476 database5533db main
query-done
41477 database5533db main
query-start
i´m trying to use dtrace with a very basic userland program and i´m
100% of the time getting segmentation faults...
-- probes definition file --
[root@ ~]# cat simple_probes.d
provider simple {
probe loop(int);
};
-- simple program --
[root@ ~]# cat simple.c
#include stdio.h
#include simple_probes.h
int main() {
int i;
i=0;
while(1) {
printf(%d\n,i);
i++;
SIMPLE_LOOP(i);
}
return(0);
}
-- the steps i use to get the program compiled are --
[root@ ~]# dtrace -C -h -s simple_probes.d
[root@ ~]# gcc -c simple.c
[root@ ~]# dtrace -G -s simple_probes.d simple.o
[root@ ~]# gcc -lelf -o simple simple_probes.o simple.o
-- but when i run the program i always get segmentation fault :( --
[root@ ~]# ./simple
0
Segmentation fault: 11 (core dumped)
i´ve been banging my head against a wall trying to troubleshoot this
issue with obviously no success...
have any of the freebsd gurus found a similar behavior in the past
regarding userland dtrace?
any pointers/links/words of encouragement will be greatly appreciated...
regards,
javier
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: PostgreSQL + 8.1 RELEASE + DTrace = pain?
On 12/6/10 11:29 PM, Dave Pooser dave-free...@pooserville.com wrote: I used pkg_delete to remove the postgresql packages (server and client), recompiled the kernel to include DTrace and eliminate some unused drivers, updated loader.conf to bring up dtraceall at boot, did a make clean and a make config to add DTrace, and built postgresql90-server again. It appeared to work fine, but now I'm getting segfaults when I try to launch it. Is there a better place I could/should be asking questions about PostgreSQL and DTrace on FreeBSD? Or is this combination still black magic at this point? -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com ...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!! -- Bill McKenna ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: PostgreSQL + 8.1 RELEASE + DTrace = pain?
On Dec 14, 2010, at 9:01 PM, Dave Pooser wrote: Is there a better place I could/should be asking questions about PostgreSQL and DTrace on FreeBSD? Or is this combination still black magic at this point? freebsd-ports@ is a reasonable alternative (since PostgreSQL is a port), but freebsd-questions@ is the best place to ask mixed questions, where the issue involves a combination of base system, ports, etc. However, you should be able to run the thing under gdb, or debug a corefile which was previously generated, and gain more information about what is going wrong. IMO, doing SQL query tracing and optimization is much more likely to produce tunable performance improvements than working at the DTrace level Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
PostgreSQL + 8.1 RELEASE + DTrace = pain?
First off, I'll freely admit I'm a *BSD noob; I've been administering Mac servers for a decade and OpenSolaris and Linux for 3-4 years but this is my first ever attempt to set up a FreeBSD system. The goal is to replace a Linux box that is currently a PostgreSQL database server; I need LDAP authentication and I want DTrace. (I also want GSSAPI, but that's another discussion entirely). (Why FreeBSD? DTrace and ZFS without the Oracle Solaris pricetag. Plus it's a *NIX I haven't used yet.) So I used csup to update to the latest ports, built postgresql90-server from ports with LDAP and no DTrace, and it worked fine. Then I used pkg_delete to remove the postgresql packages (server and client), recompiled the kernel to include DTrace and eliminate some unused drivers, updated loader.conf to bring up dtraceall at boot, did a make clean and a make config to add DTrace, and built postgresql90-server again. It appeared to work fine, but now I'm getting segfaults when I try to launch it. Am I doing something obviously stupid here? Is there a good source for troubleshooting steps? What other information should I be posting to help y'all help me figure this out? -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com ...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!! -- Bill McKenna ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Dtrace ustack status
Hi, Does anyone know what the status of dtrace being able to trace userland processes is? I see there are few patches out there but am unsure of the reliability etc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dtrace ustack status
On Tue, 20 Jul 2010 12:03:09 +0100 krad kra...@googlemail.com wrote: Does anyone know what the status of dtrace being able to trace userland processes is? I see there are few patches out there but am unsure of the reliability etc. http://freebsdfoundation.blogspot.com/2010/06/dtrace-userland-project.html -- Bruce Cran ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Dtrace ustack status
On 20 July 2010 13:02, Bruce Cran br...@cran.org.uk wrote: On Tue, 20 Jul 2010 12:03:09 +0100 krad kra...@googlemail.com wrote: Does anyone know what the status of dtrace being able to trace userland processes is? I see there are few patches out there but am unsure of the reliability etc. http://freebsdfoundation.blogspot.com/2010/06/dtrace-userland-project.html -- Bruce Cran Thanks thats good however its a letter of intent only. Does anyone know how its going, and is it likely to be delivered? September sounds like a tight time line to me as from what ive read its a fairly complex task. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
dtrace and web server
Hello List,
I try to locate (potential) bottlenecks at a web server:
-
% uname -a
FreeBSD bbserver.ipt.ru 8.0-STABLE FreeBSD 8.0-STABLE #3 r203959: Sun Feb 21
11:53:57 MSK 2010 r...@bbserver.ipt.ru:/z/obj/z/src/sys/BBSERVER amd64
% top -jd1 | head -20
last pid: 47907; load averages: 2.30, 1.88, 1.90 up 1+17:44:3611:31:05
177 processes: 4 running, 172 sleeping, 1 zombie
Mem: 916M Active, 558M Inact, 2899M Wired, 2656K Cache, 31M Buf, 3502M Free
Swap: 4096M Total, 4096M Free
PID JID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
22148 4 88 25 440 735M 530M ucond 3 23:05 7.81% mysqld
47705 4 www 1 540 223M 58476K select 2 0:07 7.76% httpd
47845 4 www 1 510 225M 48800K accept 1 0:02 7.47% httpd
47857 4 www 1 530 221M 44308K select 3 0:01 7.47% httpd
47797 4 www 1 510 225M 56276K accept 1 0:03 6.59% httpd
47843 4 www 1 500 221M 43580K select 3 0:01 6.30% httpd
47873 4 www 1 510 233M 52424K CPU22 0:01 5.96% httpd
47633 4 www 1 490 221M 56476K select 3 0:08 5.76% httpd
47878 4 www 1 470 221M 43480K accept 2 0:01 4.30% httpd
47708 4 www 1 520 221M 56756K accept 2 0:06 4.20% httpd
47880 4 www 1 520 223M 39516K accept 2 0:01 4.05% httpd
47875 4 www 1 490 235M 45080K CPU33 0:00 4.05% httpd
-
Let's use dtrace to understand what's going on within 10 seconds
interval and normalize to 1 second:
-
% cat top-10-count-periodic.d
#pragma D option quiet
BEGIN
{
last = timestamp;
}
syscall:::entry
{
@func[execname] = count();
}
tick-10sec
{
trunc(@func, 10);
normalize(@func, (timestamp - last) / 10);
printa(@func);
clear(@func);
last = timestamp;
}
-
The result is here:
ftp://ftp.bsam.ru/pub/tmp/top-10-count-periodic.1.log.txt
OK, seems that we are mostly interested at mysqld and httpd processes
(well, not a surprise).
The following script is intended to test and quantize mysqld process:
-
% cat quant.d
syscall:::entry
/ execname == mysqld /
{
self-ts = timestamp;
}
syscall:::return
/ self-ts execname == mysqld /
{
@time[probefunc] = quantize(timestamp - self-ts);
self-ts = 0;
}
-
The result: ftp://ftp.bsam.ru/pub/tmp/quant.mysqld.1.log.txt
The same D script but for httpd process:
ftp://ftp.bsam.ru/pub/tmp/quant.httpd.1.log.txt
And now can you advise me what to do next? What should I pay
attention to? Thanks!
--
WBR, Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Dtrace
is it likely that Dtrace will be coming to standard RELEASE kernels in future? i prefer not compile custom kernels for production servers but i do find the system monitoring Dtrace affords rather handy. -- View this message in context: http://old.nabble.com/Dtrace-tp26562798p26562798.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
