From: | "Nicholson, Brad (Toronto, ON, CA)" <bnicholson(at)hp(dot)com> |
---|---|
To: | "pgsql-advocacy(at)postgresql(dot)org" <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Top 5 Challenges - Administration and Monitoring |
Date: | 2011-03-10 18:11:39 |
Message-ID: | 2626AEE4839D064CB0472A3814DC403F46D139CD9E@GVW1092EXB.americas.hpqcorp.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
Hi,
Apologies for starting a new thread on this but I just re-subbed to this list and don't have the original message to reply to, but wanted to address this comment from Greg in this message:
http://archives.postgresql.org/pgsql-advocacy/2011-03/msg00006.php
>> 4. Administration & monitoring
>
> This is a pretty vague and wide-ranging topic, so it's hard to address.
> We do have a slew of administration GUIs, and a bunch of monitoring
> tools, but especially the latter need some work. Would be nice if these
> bullet points were broken down a little further with some actual
> specific complaints or ideas. Any chance of that, Josh?
>
Part of the problem is having a slew of tools. In order to use them, you need to know:
-that these tools exist in the first place and where to find them
-which tool is the correct one for what you are wanting to do
-does the tool even work (or work properly) with modern versions of Postgres, or was support dropped off 3 versions back
-that the tool will actually run on your platform. It's great the Postgres runs on a lot of different OS's, but many of the support tools do not.
For those that aren't well versed in Postgres, this isn't very intuitive. It's can also be very time consuming to figure out.
Think about a task as basic as finding the top queries running against your database. In other platforms it is a point and click (or simple query) away. For us, it involves having the correct log settings, thresholds low enough to log the queries, disk space/available I/O for lower logging levels, knowledge that something like pgfouine exists to parse the results, a server with php and the appropriate libraries available to run it and so on.
When you get down to the more expert DBA level, there is a lot of information that you either can't get or is very time consuming to get compared to what you gather in other databases. Many things that DBA's need isn't there or isn't intuitive to get (sources of wait times, per query resource utilization, ect). Diagnosing problems after they have happened is a particular challenge that we have.
Due to the inherent disconnect between DB and OS level stuff, correlating what is happening at the DB with what is happening on the server is another challenge at times. This gets more difficult as the throughput and concurrency of your systems increases.
None of these are simple problems to solve due the way we work (and to an extent, the way open source works).
Brad.
From | Date | Subject | |
---|---|---|---|
Next Message | damien clochard | 2011-03-10 22:53:19 | Proposal for a PostgreSQL Print Magazine |
Previous Message | Greg Sabino Mullane | 2011-03-10 18:07:46 | Re: Top five challenges |