Re: Proposed changes to DTrace probe implementation

Поиск
Список
Период
Сортировка
От Paul van den Bogaard
Тема Re: Proposed changes to DTrace probe implementation
Дата
Msg-id EF0C21AC-E8E7-4938-A750-7AE42A81398C@sun.com
обсуждение исходный текст
Ответ на Re: Proposed changes to DTrace probe implementation  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
but putting these and other counters in context is what could be  
missing. Correlating a given (set of) stats with others (possible  
outside of the application domain) is one of the assets offered by  
DTrace.  Besides the generic transaction begin/start/end it could  
also be helpful to see the number of parses,binds,executes per  
transaction, user, connection etc.
And yes, I feel Tom is right in fearing that these things can be used  
in "creative" ways. However is this not true for most benchmarks/ 
results when ones objective is  to "show" how perfect/better/whatever  
product/platform A behaves/is compared to B, C, etc...

One benefit for generalizing a subset of the DTrace probes is the  
possibility of creating generic DTrace scripts that can be used for  
many database installations. DTrace is great, programming DTrace  
scripts is fun (my view, and sure I am biased as a Sun employee :-),  
but it is not likely to be something a dba would like to master. The  
availability of "generic" scripts does add value.


BTW I wonder if we could somehow combine DTrace as a contextual tool  
with the counters provided through the stats interface. Any insight/ 
ideas?

--Paul.






On 27-feb-2008, at 10:28, Magnus Hagander wrote:

> On Tue, Feb 26, 2008 at 03:48:28PM -0600, Robert Lor wrote:
>> Gregory Stark wrote:
>>> I think both types of probes are useful to different people.
>>>
>> I think certain higher level probes can be really useful to DBAs.
>>> Perhaps looking at the standard database SNMP MIB counters would  
>>> give us a
>>> place to start for upward facing events people want to trace for  
>>> databases
>>> in
>>> general.
>>>
>> Great idea. I found this link for public RDBMS MIB
>> http://www.mnlab.cs.depaul.edu/cgi-bin/sbrowser.cgi? 
>> HOST=&OID=RDBMS-MIB!rdbmsMIB
>>
>> The stats in rdbmsSrvInfoTable is quite useful, and it's one of the
>> tables that Oracle implements in their SNMP support.
>> http://download-east.oracle.com/docs/cd/B14099_19/manage.1012/ 
>> b16244/appdx_d_rdbms.htm
>
> Incidentally, most of that's already supported by the pg snmp  
> provider,
> through the stats system.
>
> //Magnus
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq

------------------------------------------------------------------------ 
---------------------
Paul van den Bogaard                                
Paul.vandenBogaard@sun.com
ISV-E  -- ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc                              phone:        +31  
334 515 918
Saturnus 1                                                  
extentsion: x (70)15918
3824 ME Amersfoort                                 mobile:       +31  
651 913 354
The Netherlands                                         
fax:            +31 334 515 001



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: An idea for parallelizing COPY within one backend
Следующее
От: "Tom Dunstan"
Дата:
Сообщение: Re: An idea for parallelizing COPY within one backend