* Waldo Nell (pwn...@telkomsa.net) wrote:
> The fsync = off was because the production system runs on a uber expensive
> SAN system with multipathing over Fibre Channel, it is on UPS and backup
> generators in a secure datacenter, and we have daily backups we can fall back
> to.
So, two points:
Waldo Nell writes:
> I have PostgreSQL 8.4.8 on Ubuntu Linux x64. Server is a Core i7 950
> with 6GB of RAM. 2GB of RAM us used by Java, some small amount by the
> kernel / services and the rest is available to PostgreSQL.
[ and the DB is 74GB, and things get slower when raising shared_buffers
On 2011-08-12, at 10:10 , Kevin Grittner wrote:
> Turning fsync off in production may be OK as long as those daily
> backups aren't in the same building as the uber expensive SAN, and
> it's really OK to fall back on a daily backup if the database server
> crashes or locks up. By the way, I neve
On 08/12/2011 12:28 PM, Waldo Nell wrote:
I guess that means the OS cache is better for this particular use case
than the postgresql cache?
There you go. It's not magic; the database cache has some properties
that work very well for some workloads. And for others, you might as
well let the
Waldo Nell wrote:
> The fsync = off was because the production system runs on a uber
> expensive SAN system with multipathing over Fibre Channel, it is
> on UPS and backup generators in a secure datacenter, and we have
> daily backups we can fall back to.
Turning fsync off in production may be
On 2011-08-12, at 09:32 , Merlin Moncure wrote:
> In my opinion before looking at postgresql.conf you need to make sure
> your queries and their plans are good. fire up pgfouine and see where
> those 60 minutes are gettings spent. maybe you have a problem query
> that demands optimization.
Tha
On Thu, Aug 11, 2011 at 7:27 PM, Waldo Nell wrote:
>
> On 2011-08-11, at 17:18 , k...@rice.edu wrote:
>
>> One guess is that you are using the defaults for other costing parameters
>> and they
>> do not accurately reflect your system. This means that it will be a crap
>> shoot as
>> to whether a
On 2011-08-11, at 18:17 , Greg Smith wrote:
> shared_buffers=512MB
> wal_buffers=16MB
> checkpoint_segments=64
Thanks for the advice. I tried these values... And it is even worse - went up
to 63 minutes (from 60 minutes). Like I said this load is read mostly. My 80
/ 20% might be a bit inac
On 12/08/2011 8:03 AM, Waldo Nell wrote:
I have PostgreSQL 8.4.8 on Ubuntu Linux x64. Server is a Core i7 950 with 6GB
of RAM. 2GB of RAM us used by Java, some small amount by the kernel / services
and the rest is available to PostgreSQL. Hard drive is a single 7200 RPM SATA
1TB Caviar Blac
On 08/11/2011 07:35 PM, Waldo Nell wrote:
Please explain why the system is slower with the recommended values for these
two settings?
If the other parameters are at their defaults, the server is probably
executing a checkpoint every few seconds running your test. I'd wager
your log is fille
On 2011-08-11, at 17:18 , k...@rice.edu wrote:
> One guess is that you are using the defaults for other costing parameters and
> they
> do not accurately reflect your system. This means that it will be a crap
> shoot as
> to whether a plan is faster or slower and what will affect the timing.
O
On Thu, Aug 11, 2011 at 04:35:34PM -0700, Waldo Nell wrote:
> I have PostgreSQL 8.4.8 on Ubuntu Linux x64. Server is a Core i7 950 with
> 6GB of RAM. 2GB of RAM us used by Java, some small amount by the kernel /
> services and the rest is available to PostgreSQL. Hard drive is a single
> 7200
12 matches
Mail list logo
