Review: DTrace probes (merged version)
in [PgSql]
|
From: Alvaro Herrera on 4 Jul 2008 13:30 Zdenek Kotala wrote: > Alvaro Herrera napsal(a): >>> proc-master-start >>> proc-master-stop >> >> What's "master" here? > > Main process - postmaster. Huh, surely we're not interested in tracking postmaster start? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 4 Jul 2008 13:33 Zdenek Kotala wrote: > Tom Lane napsal(a): >> I see no value in cluttering the system with useless probes. The worker >> start/stop are the only ones here with any conceivable application IMHO. > > As I answered to Alvaro. I needed to catch start of backend several times > to track call flow or attach debugger. It is possible to use some other > dtrace magic for that, but it is not easy and there is not way how to > determine what kind of process it is. For example how to measure how > many writes performs bgwriter? If you need to attach a debugger to a backend, you can use the -W switch (even on PGOPTIONS if you need it for a particular backend, AFAIR). If you want to "truss" it I guess you can use -W too. Does it have any usefulness beyond that? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Zdenek Kotala on 4 Jul 2008 13:42 Alvaro Herrera napsal(a): > Zdenek Kotala wrote: >> Alvaro Herrera napsal(a): > >>>> proc-master-start >>>> proc-master-stop >>> What's "master" here? >> Main process - postmaster. > > Huh, surely we're not interested in tracking postmaster start? > It depends. See following schema example postgres::proc-master-start { tracking = 1 } syscall:::open:entry / tracking == 1/ { ... print file name ... } postgres::proc-master-stop { tracking = 0 } It is very useful because it say when you can start and stop monitoring for example. But I'm not DTrace expert maybe there is different way how to do it. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Zdenek Kotala on 4 Jul 2008 13:50 Alvaro Herrera napsal(a): > Zdenek Kotala wrote: >> Tom Lane napsal(a): > >>> I see no value in cluttering the system with useless probes. The worker >>> start/stop are the only ones here with any conceivable application IMHO. >> As I answered to Alvaro. I needed to catch start of backend several times >> to track call flow or attach debugger. It is possible to use some other >> dtrace magic for that, but it is not easy and there is not way how to >> determine what kind of process it is. For example how to measure how >> many writes performs bgwriter? > > If you need to attach a debugger to a backend, you can use the -W switch > (even on PGOPTIONS if you need it for a particular backend, AFAIR). If > you want to "truss" it I guess you can use -W too. > > Does it have any usefulness beyond that? > Why use million of tools when you can use one? And truss monitors only syscalls but with dtrace you are able to use/trace over 80000 probes in the kernel, libc and so on. I agree that for debugger you can use -W option but in situation when you are not able to use this switch (e.g on customer production machine) dtrace is only possible solution. That is why I think that this probes are useful. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Lor on 21 Jul 2008 15:47 Apologies for the delayed response - vacation, travel, etc got in the way! Zdenek Kotala wrote: > I performed review of merged patch from Robert Treat. At first point > the patch does not work (SunOS 5.11 snv_86 sun4u sparc > SUNW,Sun-Fire-V240) The attached patch fixed the regression test errors. > > > However I went through a code and I have following comments: > > 1) Naming convention: > > - Some probes uses "*end", some "*done". It would be good to select > one name. Noted. Will use <name>-done per the convention. This change will be included in an updated patch later since I think there are a number of other changes that need to be made. > - I prefer to use clog instead of slru in probes name. clog is widely > known. I think slru- is okay per your subsequent emails. > - It seems to me better to have checkpoint-clog..., > checkpoint-subtrans instead of clog-checkpoint. Yes, I was thinking about this too, but the current names are more consistent with the others. For example: buffer-checkpoint, buffer-* xlog-checkpoint, xlog-* > - buffer-flush was originally dirty-buffer-write-start. I prefer > Robert Lor's naming. Actually, I made this change so the name is consistent with the other buffer-* probes. > > 2) storage read write probes > > smgr-read*, smgr-writes probes are in md.c. I personally think it make > more sense to put them into smgr.c. Only advantage to have it in md.c > is that actual amount of bytes is possible to monitor. The current probes return number of bytes, that's why they are in md.c > > 3) query rewrite probe > > There are several probes for query measurement but query rewrite phase > is missing. See analyze_and_rewrite or pg_parse_and_rewrite I believe the rewrite time is accounted for in the query-plan probe. Need to double check on this. > > 4) autovacuum_start > > Autovacuum_start probe is alone. I propose following probes for > completeness: > > proc-autovacuum-start > proc-autovacuum-stop > proc-bgwriter-start > proc-bgwriter-stop > proc-backend-start > proc-backend-stop > proc-master-start > proc-master-stop Saw a number of emails on this. Will get back on this. > > 5) Need explain of usage: > > I have some doubts about following probes. Could you please explain > usage of them? example dtrace script is welcome > > - all exec-* probes > - mark-dirty, local-mark-dirty > Theo/Robert, do you guys have any sample scripts on the probes you added. > > 6) several comments about placement: > > I published patch on http://reviewdemo.postgresql.org/r/25/. I added > several comments there. > > 7) SLRU/CLOG > > SLRU probes could be return more info. For example if page was in > buffer or if physical write is not necessary and so on. Yes, more info could be returned if we can identify specific use cases that the new data will enable. -- Robert Lor Sun Microsystems Austin, USA http://sun.com/postgresql
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Adding variables for segment_size, wal_segment_sizeand block sizes Next: Explain XML patch v2 |