oh thanks @Sameer Kumar
Thanks & Regards,
A.Mohamed Bilal
On Thu, Jan 9, 2014 at 12:50 PM, Sameer Kumar [via PostgreSQL] <[hidden email]> wrote:
On Wed, Jan 8, 2014 at 7:22 PM, ambilalmca <[hidden email]> wrote:
I want to collect,
*Connections. *
Current connections. The number of currently open connections.*Buffers. *
Connections executing requests. The number of currently open connections
that are executing requests.
Idle connections. The number of currently idle connections.
Max connections. The maximum number of concurrent connections to the
database server.
Used connections. Connections used as a percentage of maximum connections.
*IO Requests.*
Shared buffers size. Current size of shared buffers.
Disk cache size. Current size of disk cache buffer.
Sort buffer size. Current size of sort buffer.
Work buffer size. Current size of working requests buffer.
Temp buffer size. Current size of temporary buffer.
*Cache*
Blocks read. Number of blocks directly read on disk.
For optimal performance this value should be the smallest possible. If the
database has to execute too many disk accesses, performance will suffer.
Index blocks read. Number of index blocks directly read on disk.
% Index blocks read. Percentage of index blocks directly read on disk.
Sequence blocks read. Number of sequence blocks directly read on disk.
*Index*.
Blocks read. Number of cached blocks read.
Index blocks read. Number of cached index blocks read.
% Index blocks read. Percentage of cached index blocks read.
For optimal performance, this value must be as large as possible. If an
insufficient number of index blocks are declared in the table, it could
negatively impact the database server performance.
Sequence blocks read. Number of cached sequence blocks read.
*Command Rates.*
Index read. Number of reads initiated by an index.
Indexed rows read. Number of rows read by indexed requests.
Indexed rows fetched. Number of live rows fetched by indexed requests.
*Locks. *
Rows read. Number of rows read.
Rows fetched. Number of rows fetched.
Inserted rows. Number of rows inserted.
Updated rows. Number of rows updated.
Deleted rows. Number of rows deleted.
Committed transactions. Number of committed transactions.
This value should be relatively stable, indicating that there are no
performance-reducing load peaks. If applications do not commit often enough,
it will lead to an overload on the database server.
Rolled back transactions. Number of transactions rolled back.
% Rolledback transactions. Percentage of transactions rolled back.
Locks waiting. Number of locks waiting.
Locks held. Number of locks held.
Process holding locks. Number of processes holding locks.
how to collect these details by using query. now i find queries for
sonnections. but i dont know anout others. please help me.@Sameer Kumar
Are you building your own scripts for monitoring the database?Are are open source plug-ins available for that. Anyways, take a look at this documentation:You will find most of the things you have asked for (I guess all of it). If you are not able to find something then you can post here.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/How-to-know-server-status-variable-in-postgresql-tp5785677p5785833.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.Sent via pgsql-general mailing list ([hidden email])
--
http://postgresql.1045698.n5.nabble.com/How-to-know-server-status-variable-in-postgresql-tp5785677p5786022.htmlIf you reply to this email, your message will be added to the discussion below:
View this message in context: Re: How to know server status variable in postgresql?
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
