On 13/07/2010 4:05 PM, Andras Fabian wrote:
Craig, thanks for that PS tip (you think, you have used PS for such a long
time, but it still has some new tricks available).
So, obviously, for some reason we are waiting too much for a backind_device ...
which ever it is at the moment. Because, as I just wrote to Scott Marlowe, the
disk system is almost idling (have seen disk utilization on the drive to which
I write below 1%).
A quick search suggests that most calls into congestion_wait are in the
memory management subsystem, and are involved in situations where the
system is struggling for memory. However, that includes memory consumed
by I/O buffers, writeback for I/O, etc, so it'd also be consistent with
very slow I/O causing write throttling as the system tried to write
already buffered data to disk.
Most other calls are in file system drivers.
At this point I'd be taking a closer look at "vmstat 1" and "iostat 1"
output, plus "top", to see if any interesting clues about system-wide
issues turned up.
I'd also be trying to perform each step of the problem operation in
isolation as much as possible, so as to see if I could find out what
particular part was causing the slowdown. Comparing "\copy" to "COPY ...
TO STDOUT", invoking "COPY ... TO STDOUT" with a standalone backend
writing output to an on disk file and to /dev/null, etc.
So, the question seems to be, why and where this "idling happens".
You can potentially find out more by getting a trace of the kernel
function call stack for the backend process. The kernel call stack of a
process at any given time can be obtained by reading /proc/$pid/stack .
This will tell you not only what call it's waiting in in the kernel, but
what function(s) called it, and even the code offset within each function.
Just as a test, I have tried a very simple piping example (which should go
trough STDOUT too ... or am I wrong).
- "dd if=/dev/zero of=file_10GB bs=1024 count=10M" created a 10 GB test file
on source drive (sdb)
- "time cat file_10GB> /var/tmp/test2.dump" ... pipe the file to target drive
(/var/tmp is on sda)
Isn't your issue suspected to be with network transfers over unix
sockets and/or tcp/ip, rather than with pipes?
Try "socat" if you want to test unix socket performance and/or tcp/ip
socket performance. It's an amazing sysadmin/network swiss army knife.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
