Message-ID: <524AAE12.8@iqbuzz.ru>
Date: Tue, 01 Oct 2013 15:12:18 +0400
From: Sergey Klochkov <klochkov@iqbuzz.ru>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: pgsql-admin@postgresql.org
CC: giuseppe.broccolo@2ndquadrant.it
Subject: Re: PostgreSQL 9.2 - pg_dump out of memory when backuping
 a database with 300000000 large objects
References: <524A90D1.5000109@iqbuzz.ru> <524AAB93.7070308@2ndquadrant.it>
In-Reply-To: <524AAB93.7070308@2ndquadrant.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

No, it did not make any difference. And after looking through pg_dump.c 
and pg_dump_sort.c, I cannot tell how it possibly could. See the 
stacktrace that I've sent to the list.

Thanks.

On 01.10.2013 15:01, Giuseppe Broccolo wrote:
> Maybe you can performe your database changing some parameters properly:
>>
>> PostgreSQL configuration:
>>
>> listen_addresses = '*'          # what IP address(es) to listen on;
>> port = 5432                             # (change requires restart)
>> max_connections = 500                   # (change requires restart)
> Set it to 100, the highest value supported by PostgreSQL
>> shared_buffers = 16GB                  # min 128kB
> This value should not be higher than 8GB
>> temp_buffers = 64MB                     # min 800kB
>> work_mem = 512MB                        # min 64kB
>> maintenance_work_mem = 30000MB          # min 1MB
> Given RAM 96GB, you could set it up to 4800MB
>> checkpoint_segments = 70                # in logfile segments, min 1,
>> 16MB each
>> effective_cache_size = 50000MB
> Given RAM 96GB, you could set it up to 80GB
>>
>
> Hope it can help.
>
> Giuseppe.
>

-- 
Sergey Klochkov
klochkov@iqbuzz.ru


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin