Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-28 Thread Greg Smith
On Sun, 24 Aug 2008, Tom Lane wrote: Mind you, I don't think Apple sells any hardware that would be really suitable for a big-ass database server. If you have money to burn, you can get an XServe with up to 8 cores and 32GB of RAM, and get a card to connect it to a Fiber Channel disk array.

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-25 Thread Jonah H. Harris
On Fri, Aug 22, 2008 at 7:52 AM, Peter Schuller <[EMAIL PROTECTED]> wrote: > Is there currently a way of dumping such information? I.e., asking PG > "what are backends waiting on right now?". Unfortunately, not within Postgres itself. The question, "what is the database waiting on?" is a good one

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-25 Thread RW
This matches not exactly the topic but it is sometimes helpfull. If you've enabled I/O accounting and a kernel >= 2.6.20 (needs to be compiled with **CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y ) and sysstat package (>= 7.1.5) installed you can use

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-25 Thread Alexander Staubo
On Mon, Aug 25, 2008 at 3:34 AM, Scott Carey <[EMAIL PROTECTED]> wrote: > DTrace is available now on MacOSX, Solaris 10, OpenSolaris, and FreeBSD. > Linux however is still in the dark ages when it comes to system monitoring, > especially with I/O. While that's true, newer 2.6 kernel versions at le

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-24 Thread Alvaro Herrera
Tom Lane wrote: > "Scott Carey" <[EMAIL PROTECTED]> writes: > > DTrace is available now on MacOSX, Solaris 10, OpenSolaris, and FreeBSD. > > Linux however is still in the dark ages when it comes to system monitoring, > > especially with I/O. > > Oh, after poking around a bit, I should note that so

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-24 Thread Tom Lane
"Scott Carey" <[EMAIL PROTECTED]> writes: > DTrace is available now on MacOSX, Solaris 10, OpenSolaris, and FreeBSD. > Linux however is still in the dark ages when it comes to system monitoring, > especially with I/O. Oh, after poking around a bit, I should note that some of my Red Hat compatriots

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-24 Thread Tom Lane
Craig Ringer <[EMAIL PROTECTED]> writes: > Peter Schuller wrote: >> But in general, it would be very interesting to see, at any given >> moment, what PostgreSQL backends are actually blocking on from the >> perspective of PostgreSQL. > The recent work on DTrace support for PostgreSQL will probably

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-24 Thread Scott Carey
More info/notes on DTrace -- DTrace is available now on MacOSX, Solaris 10, OpenSolaris, and FreeBSD. Linux however is still in the dark ages when it comes to system monitoring, especially with I/O. You can write some custom DTrace scripts to map any of the basic Postgres operations or processes

Re: [PERFORM] Identifying the nature of blocking I/O

2008-08-24 Thread Craig Ringer
Peter Schuller wrote: > But in general, it would be very interesting to see, at any given > moment, what PostgreSQL backends are actually blocking on from the > perspective of PostgreSQL. The recent work on DTrace support for PostgreSQL will probably give you the easiest path to useful results. Y

[PERFORM] Identifying the nature of blocking I/O

2008-08-22 Thread Peter Schuller
[for the purpose of this post, 'blocking' refers to an I/O operation taking a long time for reasons other than the amount of work the I/O operation itself actually implies; not to use of blocking I/O calls or anything like that] Hello, I have a situation in which deterministic latency is a lot mo