W dniu 14 kwietnia 2010 15:30 użytkownik Grzegorz Jaśkiewicz
napisał:
> That really sounds like hardware issue. The I/O causes the system to freeze
> basically.
> Happens sometimes on cheaper hardware.
>
Probably You have right because this is HS21 Blade Server. And as You
know blades are cheap a
Krzysztof Kardas wrote:
> synchronous_commit = off
> This caused a monumental performance jump. From a machine that is
> utilized on 100%, machine is now sleeping and doing nothing. I
> have executed some sqls on huge tables like history and all has
> executed like lightning. Comparing to MySQ
That really sounds like hardware issue. The I/O causes the system to freeze
basically.
Happens sometimes on cheaper hardware.
Hi all.
Well I have used all Your recomendations but I still have no luck with
performance tunning. The machine has a moments thas was utilized in
100%. The problem was I/O on disks. CPU's were busy on system
interrupts.
I have started again to look of I/O performance tunning and I have changed
2010/4/9 Scott Marlowe :
> On Fri, Apr 9, 2010 at 10:30 AM, Merlin Moncure wrote:
>> On Fri, Apr 9, 2010 at 12:03 PM, Greg Smith wrote:
>>> The main problem with this configuration is that work_mem is set to an
>>> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
>>> fr
On Fri, Apr 9, 2010 at 10:30 AM, Merlin Moncure wrote:
> On Fri, Apr 9, 2010 at 12:03 PM, Greg Smith wrote:
>> The main problem with this configuration is that work_mem is set to an
>> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
>> free after starting the server, w
On Fri, Apr 9, 2010 at 12:03 PM, Greg Smith wrote:
> The main problem with this configuration is that work_mem is set to an
> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
> free after starting the server, work_mem='4MB' is as large as you can safely
> set this.
if y
On Fri, Apr 9, 2010 at 10:03 AM, Greg Smith wrote:
> The main problem with this configuration is that work_mem is set to an
> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
> free after starting the server, work_mem='4MB' is as large as you can safely
> set this.
> m
Off-list message that should have made it onto here, from Krzysztof:
I have changed PostgreSQL to 8.3. I think that the database is really working
faster. New settings:
name | unit | current_setting
-+--+---
autova
The OP is using:
autovacuum_vacuum_threshold | 10
That means that vacuum won't consider a table to be 'vacuum-able' until
after 100k changes that's nowhere near aggressive enough. Probably
what's happening is that when autovacuum finally DOES start on a table, it
just takes forever.
2010/4/9 Greg Smith :
> Merlin Moncure wrote:
>>
>> postgresql 8.2: autovacuum enabled by default
>> postgresql 8.3: HOT (reduces update penalty -- zabbix does a lot of
>> updates)
>>
>
> autovacuum wasn't enabled by default until 8.3. It didn't really work all
> that well out of the box until the
Merlin Moncure wrote:
postgresql 8.2: autovacuum enabled by default
postgresql 8.3: HOT (reduces update penalty -- zabbix does a lot of updates)
autovacuum wasn't enabled by default until 8.3. It didn't really work
all that well out of the box until the support for multiple workers was
ad
Krzysztof Kardas wrote:
My current database variables:
That is way too much stuff to sort through. Try this instead, to only
get the values you've set to something rather than every single one:
select name,unit,current_setting(name) from pg_settings where
source='configuration file' ;
Kind of off-topic, but I've found that putting the history table on a separate
spindle (using a separate tablespace) also helps improve performance.
--Richard
On Apr 8, 2010, at 12:44 PM, Robert Haas wrote:
> 2010/4/8 Merlin Moncure :
>> previous to 8.2, to get good performance on zabbix you
2010/4/8 Merlin Moncure :
> previous to 8.2, to get good performance on zabbix you need to
> aggressively vacuum the heavily updated tables yourself.
Generally if you DON'T vacuum aggressively enough, then vacuums will
take a really long and painful amount of time, perhaps accounting for
the "hang
2010/4/8 Grzegorz Jaśkiewicz :
> starting with 8.3, there's this new feature called HOT, which helps a lot
> when you do loads of updates.
> Plus writer is much quicker (30-40% sometimes), and autovacuum behaves much
> nicer.
> Bottom line, upgrade to 8.3, 8.1 had autovacuum disabled by default for
starting with 8.3, there's this new feature called HOT, which helps a lot
when you do loads of updates.
Plus writer is much quicker (30-40% sometimes), and autovacuum behaves much
nicer.
Bottom line, upgrade to 8.3, 8.1 had autovacuum disabled by default for a
reason.
Hi,
I am using zabbix monitoring software. The backbone database for
zabbix is postgresql 8.1 installed od linux.
Database server has 3GB of RAM, 1 CPU Dual Core and 2 SAS disks in RAID 1.
Zabbix makes a lot of inserts and updates on database. The problem is
that when autovaccum starts the datab
18 matches
Mail list logo
