On Thu, Dec 7, 2017 at 2:31 PM, Laurenz Albe wrote:
> Gunther wrote:
>> Something is wrong with the dump thing. And no, it's not SSL or whatever,
>> I am doing it on a local system with local connections. Version 9.5
>> something.
>
> That's a lot of useful information.
>
> Try to profile where t
Gunther wrote:
> Something is wrong with the dump thing. And no, it's not SSL or whatever,
> I am doing it on a local system with local connections. Version 9.5 something.
That's a lot of useful information.
Try to profile where the time is spent, using "perf" or similar.
Do you connect via the
I confess I don't do dump or any backups much other than file system
snapshots.
But when I do, I don't like how long it takes.
I confess my database is big, I have about 200 GB. But still, dumping it
should not take 48 hours (and running) while the system is 75% idle and
reads are at 4.5 MB/s
On 22 Nov 2017, at 22:07, Patrick KUI-LI
mailto:pku...@hipay.com>> wrote:
Hello,
I had this behaviors when the upgraded pg 9.5 was on ssl mode by default.
So i deactivated ssl mode in postgresql.conf. That's all.
Regards,
Patrick
Hello
And you just uncommented the 'ssl = off' line in t
Hello,
I had this behaviors when the upgraded pg 9.5 was on ssl mode by default.
So i deactivated ssl mode in postgresql.conf. That's all.
Regards,
Patrick
On 11/21/2017 03:28 PM, Henrik Cednert (Filmlance) wrote:
> Hello
>
> We use a system in filmproduction called DaVinci Resolve. It uses
Hi Matthew
Actually running that test in a vm right now. =)
This is the same db dumped from 9.5 and 8.4 with compression 6 in the same
system (smaller db in a vm).
9.5:
real 82m33.744s
user 60m55.069s
sys 3m3.375s
8.4
real 42m46.381s
user 23m50.145s
sys 2m9.853s
When looking at a sample and/o
On Nov 22, 2017, at 5:06 AM, Henrik Cednert (Filmlance)
wrote:
>
> When investigating the zlib lead I looked at 8.4 installation and 9.5
> installation. 9.5 includes zlib.h (/Library/PostgreSQL//9.5/include/zlib.h),
> but 8.4 doesn't. But that's a header file and I have no idea how that really
Hi,
On 2017-11-22 02:32:45 -0800, Matthew Hall wrote:
> I would say most likely your zlib is screwed up somehow, like maybe it
> didn't get optimized right by the C compiler or something else sucks
> w/ the compression settings. The CPU should easily blast away at that
> faster than disks can read
When investigating the zlib lead I looked at 8.4 installation and 9.5
installation. 9.5 includes zlib.h (/Library/PostgreSQL//9.5/include/zlib.h),
but 8.4 doesn't. But that's a header file and I have no idea how that really
works and if that's the one used by pgres9.5 or not. The version in it s
Hello
I've ran it with all the different compression levels on one of the smaller
db's now. And not sending any flags to it see is, as I've seen hinted on some
page on internet, same as level 6.
I do, somewhat, share the opinion that something is up with zlib. But at the
same time I haven't to
> On Nov 21, 2017, at 10:18 PM, Henrik Cednert (Filmlance)
> wrote:
>
> WHat's the normal way to deal with compression? Dump uncompressed and use
> something that threads better to compress the dump?
I would say most likely your zlib is screwed up somehow, like maybe it didn't
get optimized
Ha! So forcing compression to 0 i went from 644 minutes to 87 minutes. And this
time I backed it to a afp share and from the looks of it I hit the roof on that
eth interface. Size of backup went from 50GB to 260 GB though, hehehe.
So something seems to have changed regarding default compression
Hi Tom
I'm honestly not sure about anything. =) I use the exact same flags as with 8.4
for the dump:
${BINARY_PATH}/pg_dump --host=localhost --user=postgres --no-password --blobs
--format=custom --verbose --file=${pg_dump_filename}_${database}.backup
${database}
So unless the default behaviou
"Henrik Cednert (Filmlance)" writes:
> I'm not sure if I can attach screenshots here. Trying, screenshot from
> instruments after running for a few mins.
It looks like practically all of pg_dump's time is going into deflate(),
ie zlib. I don't find that terribly surprising in itself, but it off
Hello
Running it with format "directory" produced something I cannot import form the
host application. So I aborted that.
Running it now and recording with Instruments. Guess I'll have to leave it
cooking for the full procedure but I've added an initial one to pastebin.
https://pastebin.com/QHR
Robert Haas writes:
> On Tue, Nov 21, 2017 at 12:01 PM, Tom Lane wrote:
>> Can you get a profile of where the machine is spending its time during the
>> dump run? On Linux I'd recommend "perf", but on macOS, hmm ...
>> You could use Activity Monitor, but as far as I can see that just captures
>>
On Tue, Nov 21, 2017 at 12:01 PM, Tom Lane wrote:
> "Henrik Cednert (Filmlance)" writes:
>> The last pg_dump with 8.4 took 212 minutes and 49 seconds.And now with 9.5
>> the very same pg_dump takes 644 minutes and 40 seconds. To it takes about
>> three times as long now and I have no idea to wh
"Henrik Cednert (Filmlance)" writes:
> The last pg_dump with 8.4 took 212 minutes and 49 seconds.And now with 9.5
> the very same pg_dump takes 644 minutes and 40 seconds. To it takes about
> three times as long now and I have no idea to why. Nothing in the system or
> hardware other than the p
From: Henrik Cednert (Filmlance) [mailto:henrik.cedn...@filmlance.se]
Sent: Tuesday, November 21, 2017 11:48 AM
To: pgsql-performance@lists.postgresql.org
Subject: Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
I VACUUM every sunday so that is done already. =/
Not sure I have the pro
tgresql.org<mailto:pgsql-performance@lists.postgresql.org>
Subject: Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
Attention: This email was sent from someone outside of Perceptron. Always
exercise caution when opening attachments or clicking links from unknown
senders or when receiving unexpected e
nrik.cedn...@filmlance.se]
> *Sent:* Tuesday, November 21, 2017 9:29 AM
> *To:* pgsql-performance@lists.postgresql.org
> *Subject:* pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
>
>
>
> Hello
>
>
>
> We use a system in filmproduction called DaVinci Resolve.
From: Henrik Cednert (Filmlance) [mailto:henrik.cedn...@filmlance.se]
Sent: Tuesday, November 21, 2017 11:37 AM
To: pgsql-performance@lists.postgresql.org
Subject: Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
Attention: This email was sent from someone outside of Perceptron. Alw
mlance) [mailto:henrik.cedn...@filmlance.se]
Sent: Tuesday, November 21, 2017 11:27 AM
To:
pgsql-performance@lists.postgresql.org<mailto:pgsql-performance@lists.postgresql.org>
Subject: Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
Ahh! Nice catch Igor. Thanks. =)
Will try and see if r
From: Henrik Cednert (Filmlance) [mailto:henrik.cedn...@filmlance.se]
Sent: Tuesday, November 21, 2017 11:27 AM
To: pgsql-performance@lists.postgresql.org
Subject: Re: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
Ahh! Nice catch Igor. Thanks. =)
Will try and see if resolve can read t
From: Henrik Cednert (Filmlance) [mailto:henrik.cedn...@filmlance.se]
Sent: Tuesday, November 21, 2017 9:29 AM
To:
pgsql-performance@lists.postgresql.org<mailto:pgsql-performance@lists.postgresql.org>
Subject: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
Hello
We use a system in
From: Henrik Cednert (Filmlance) [mailto:henrik.cedn...@filmlance.se]
Sent: Tuesday, November 21, 2017 9:29 AM
To: pgsql-performance@lists.postgresql.org
Subject: pg_dump 3 times as slow after 8.4 -> 9.5 upgrade
Hello
We use a system in filmproduction called DaVinci Resolve. It uses a pg
Hello
We use a system in filmproduction called DaVinci Resolve. It uses a pgsql
database when you work in a collaborative workflow and multiple people share
projects. Previously it was using pgsql 8.4 but for a new major upgrade they
recommend an upgrade to 9.5. Probably also to some macOS limi
27 matches
Mail list logo
