Joseph S Wrote
> If I have 14 drives in a RAID 10 to split between data tables
> and indexes what would be the best way to allocate the drives
> for performance?
RAID-5 can be much faster than RAID-10 for random reads and writes. It is much
slower than RAID-10 for sequential writes, but about th
>
> -- Forwarded message --
> From: Joseph S
> To: Greg Smith , pgsql-performance@postgresql.org
> Date: Fri, 28 Aug 2009 10:25:10 -0400
> Subject: Re: What exactly is postgres doing during INSERT/UPDATE ?
> Greg Smith wrote:
>
> The main two things you can do to improve this on t
> What more complex tools would you recommend to monitor memory usage?
vmstat, and sar on Linux. Dtrace on BSD or Solaris, if you're ready to
write some d-script. pg_top for PG memory usage interactively.
See performance-whack-a-mole: www.pgcon.org/2009/schedule/events/188.en.html
--
Josh Be
Dear all,
I am migrating a large PhpBB forum to Drupal.
What memory monitoring tool would you recommend?
I never used one before in PostgreSQL.
The only figures I read are those from VACUUM VERBOSE ANALYSE to make
sure I have enough shared memory for indexes.
What more complex tools would you
Scott Marlowe wrote:
After that you have to start looking at hardware. Soimething as
simple as a different drive for indexes and another for WAL, and
another for the base tables can make a big difference.
If I have 14 drives in a RAID 10 to split between data tables and
indexes what would be
Greg Smith wrote:
The main two things you can do to improve this on the database side:
-Increase checkpoint_segments, which reduces how often updated data has
to be flushed to disk
It fsync is turned off, does this matter so much?
--
Sent via pgsql-performance mailing list (pgsql-perform
On Fri, Aug 28, 2009 at 2:08 AM, Greg Smith wrote:
>
> This sort of workload involves random I/O rather than sequential. On
> regular hard drives this normally happens at a tiny fraction of the speed
> because of how the disk has to seek around. Typically a single drive
> capable of 50-100MB/s on
On Fri, 28 Aug 2009, Joseph S wrote:
If I run " dd if=/dev/zero bs=1024k of=file count=1000 " iostat shows me:
Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 671.5088.00113496.00176 226992
That's the sequential transfer rate of y
top shows the cpu usage of the pg process ranges from zero to never more
than ten percent of a cpu, and that one cpu is always ninety some odd
percent in iowait. So what is postgres doing (with fsync off) that
causes the cpu to spend so much time in iowait?
Updating indexes ?
--
