Store and Postgres 8.1 on Linux

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Store and Postgres 8.1 on Linux

kobetic
I've got two installations of Postgres 8.1 on Linux here (FC5 and FC6) and I notice a significant performance degradation with just about any Store operation compared to my previous installs that didn't involve Postgres 8.1. Previously I used Postgres 7.4 (I think) on FC4 and even Postgres 8 RC on WinXP, which felt noticeably faster AFAICT. This is running VW on the same machine as the DB. I'm used to this setup to just zip by loading pretty much anything. Now it feels like the database is remote, not local.

I didn't try to dig in to figure out what's going on yet, so I have no idea why (it may well be something wrong with my particular setup), but I notice that top shows the postgres daemon very busy at about 90% during Store ops. I believe I managed to turn on the auto-vacuuming feature and even vacuumed manually but didn't see much improvement. Actually now that I think of it, I suspect that all my previous setups used 32-bit OSes (certainly the Windows ones did), whereas my current FC5 and FC6 installs run in 64-bits, and also the postgres server is running in 64-bits. But I still use the 32-bit VW on those.

Anyway, I'm curious if anyone else is using similar setup and what's the experience.

Thanks,

Martin

Reply | Threaded
Open this post in threaded view
|

Re: Store and Postgres 8.1 on Linux

kobetic
OK, I've got an update that might be interesting for some. Desperate enough I decided to replicate the repository using the Glorp replicator. Less than a day later I've got another DB with the same contents and indeed this one is orders of magnitude faster. So I'm inclined to conclude that something is wrong with my backup or my backup procedures (since that's what I used to restore the repository).
My backup procedure is pretty simple. I run this as a cronjob:

        pg_dump -U mkobetic -Fc -b store > store.pgdump

and to restore it I use

        pg_restore -cd store store.pgdump

I did use the backup several times (usually due to OS upgrades) and it always manages to create a "working" repository but it seems to get progressively slower as the DB gets bigger. I can continue fine relying on the replicator instead, but I'd be curious if somebody knows what I'm doing wrong with the backups.

Thanks,

Martin

Martin Kobetic wrote:

> I've got two installations of Postgres 8.1 on Linux here (FC5 and FC6)
> and I notice a significant performance degradation with just about any
> Store operation compared to my previous installs that didn't involve
> Postgres 8.1. Previously I used Postgres 7.4 (I think) on FC4 and even
> Postgres 8 RC on WinXP, which felt noticeably faster AFAICT. This is
> running VW on the same machine as the DB. I'm used to this setup to just
> zip by loading pretty much anything. Now it feels like the database is
> remote, not local.
>
> I didn't try to dig in to figure out what's going on yet, so I have no
> idea why (it may well be something wrong with my particular setup), but
> I notice that top shows the postgres daemon very busy at about 90%
> during Store ops. I believe I managed to turn on the auto-vacuuming
> feature and even vacuumed manually but didn't see much improvement.
> Actually now that I think of it, I suspect that all my previous setups
> used 32-bit OSes (certainly the Windows ones did), whereas my current
> FC5 and FC6 installs run in 64-bits, and also the postgres server is
> running in 64-bits. But I still use the 32-bit VW on those.
>
> Anyway, I'm curious if anyone else is using similar setup and what's the
> experience.
>
> Thanks,
>
> Martin
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Store and Postgres 8.1 on Linux

Janko Mivšek
Martin, what about "vacuum"-ing a database after restore? As I
understand vacuuming a PostgreSQL database recalculate statistics about
db tables which effects performance significantly.

Best regards
Janko

Martin Kobetic wrote:

> OK, I've got an update that might be interesting for some. Desperate
> enough I decided to replicate the repository using the Glorp replicator.
> Less than a day later I've got another DB with the same contents and
> indeed this one is orders of magnitude faster. So I'm inclined to
> conclude that something is wrong with my backup or my backup procedures
> (since that's what I used to restore the repository).
> My backup procedure is pretty simple. I run this as a cronjob:
>
>     pg_dump -U mkobetic -Fc -b store > store.pgdump
>
> and to restore it I use
>
>     pg_restore -cd store store.pgdump
>
> I did use the backup several times (usually due to OS upgrades) and it
> always manages to create a "working" repository but it seems to get
> progressively slower as the DB gets bigger. I can continue fine relying
> on the replicator instead, but I'd be curious if somebody knows what I'm
> doing wrong with the backups.
>
> Thanks,
>
> Martin
>
> Martin Kobetic wrote:
>> I've got two installations of Postgres 8.1 on Linux here (FC5 and FC6)
>> and I notice a significant performance degradation with just about any
>> Store operation compared to my previous installs that didn't involve
>> Postgres 8.1. Previously I used Postgres 7.4 (I think) on FC4 and even
>> Postgres 8 RC on WinXP, which felt noticeably faster AFAICT. This is
>> running VW on the same machine as the DB. I'm used to this setup to
>> just zip by loading pretty much anything. Now it feels like the
>> database is remote, not local.
>>
>> I didn't try to dig in to figure out what's going on yet, so I have no
>> idea why (it may well be something wrong with my particular setup),
>> but I notice that top shows the postgres daemon very busy at about 90%
>> during Store ops. I believe I managed to turn on the auto-vacuuming
>> feature and even vacuumed manually but didn't see much improvement.
>> Actually now that I think of it, I suspect that all my previous setups
>> used 32-bit OSes (certainly the Windows ones did), whereas my current
>> FC5 and FC6 installs run in 64-bits, and also the postgres server is
>> running in 64-bits. But I still use the 32-bit VW on those.
>>
>> Anyway, I'm curious if anyone else is using similar setup and what's
>> the experience.
>>
>> Thanks,
>>
>> Martin
>>
>>
>
>

--
Janko Mivšek
Svetovalec za informatiko
EraNova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565

Reply | Threaded
Open this post in threaded view
|

Re: Store and Postgres 8.1 on Linux

kobetic
Yup, I'm aware of that. I did all kinds of vacuuming combinations that pgAdmin offered serveral times. Didn't seem to help much.

Janko Mivšek wrote:

> Martin, what about "vacuum"-ing a database after restore? As I
> understand vacuuming a PostgreSQL database recalculate statistics about
> db tables which effects performance significantly.
>
> Best regards
> Janko
>
> Martin Kobetic wrote:
>> OK, I've got an update that might be interesting for some. Desperate
>> enough I decided to replicate the repository using the Glorp
>> replicator. Less than a day later I've got another DB with the same
>> contents and indeed this one is orders of magnitude faster. So I'm
>> inclined to conclude that something is wrong with my backup or my
>> backup procedures (since that's what I used to restore the repository).
>> My backup procedure is pretty simple. I run this as a cronjob:
>>
>>     pg_dump -U mkobetic -Fc -b store > store.pgdump
>>
>> and to restore it I use
>>
>>     pg_restore -cd store store.pgdump
>>
>> I did use the backup several times (usually due to OS upgrades) and it
>> always manages to create a "working" repository but it seems to get
>> progressively slower as the DB gets bigger. I can continue fine
>> relying on the replicator instead, but I'd be curious if somebody
>> knows what I'm doing wrong with the backups.
>>
>> Thanks,
>>
>> Martin
>>
>> Martin Kobetic wrote:
>>> I've got two installations of Postgres 8.1 on Linux here (FC5 and
>>> FC6) and I notice a significant performance degradation with just
>>> about any Store operation compared to my previous installs that
>>> didn't involve Postgres 8.1. Previously I used Postgres 7.4 (I think)
>>> on FC4 and even Postgres 8 RC on WinXP, which felt noticeably faster
>>> AFAICT. This is running VW on the same machine as the DB. I'm used to
>>> this setup to just zip by loading pretty much anything. Now it feels
>>> like the database is remote, not local.
>>>
>>> I didn't try to dig in to figure out what's going on yet, so I have
>>> no idea why (it may well be something wrong with my particular
>>> setup), but I notice that top shows the postgres daemon very busy at
>>> about 90% during Store ops. I believe I managed to turn on the
>>> auto-vacuuming feature and even vacuumed manually but didn't see much
>>> improvement. Actually now that I think of it, I suspect that all my
>>> previous setups used 32-bit OSes (certainly the Windows ones did),
>>> whereas my current FC5 and FC6 installs run in 64-bits, and also the
>>> postgres server is running in 64-bits. But I still use the 32-bit VW
>>> on those.
>>>
>>> Anyway, I'm curious if anyone else is using similar setup and what's
>>> the experience.
>>>
>>> Thanks,
>>>
>>> Martin
>>>
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: Store and Postgres 8.1 on Linux

Boris Popov, DeepCove Labs (SNN)
In reply to this post by Janko Mivšek
You must be thinking of VACUUM ANALYZE, plain VACUUM won't recalculate table stats. But I suspect all that is covered by the new autovacuum agent unless its disabled in the configuration. You could try VACUUM FULL though.

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Janko Mivšek [mailto:[hidden email]]
Sent: Tuesday, November 07, 2006 2:48 PM
To: Martin Kobetic
Cc: VWNC
Subject: Re: Store and Postgres 8.1 on Linux

Martin, what about "vacuum"-ing a database after restore? As I
understand vacuuming a PostgreSQL database recalculate statistics about
db tables which effects performance significantly.

Best regards
Janko

Martin Kobetic wrote:

> OK, I've got an update that might be interesting for some. Desperate
> enough I decided to replicate the repository using the Glorp replicator.
> Less than a day later I've got another DB with the same contents and
> indeed this one is orders of magnitude faster. So I'm inclined to
> conclude that something is wrong with my backup or my backup procedures
> (since that's what I used to restore the repository).
> My backup procedure is pretty simple. I run this as a cronjob:
>
>     pg_dump -U mkobetic -Fc -b store > store.pgdump
>
> and to restore it I use
>
>     pg_restore -cd store store.pgdump
>
> I did use the backup several times (usually due to OS upgrades) and it
> always manages to create a "working" repository but it seems to get
> progressively slower as the DB gets bigger. I can continue fine relying
> on the replicator instead, but I'd be curious if somebody knows what I'm
> doing wrong with the backups.
>
> Thanks,
>
> Martin
>
> Martin Kobetic wrote:
>> I've got two installations of Postgres 8.1 on Linux here (FC5 and FC6)
>> and I notice a significant performance degradation with just about any
>> Store operation compared to my previous installs that didn't involve
>> Postgres 8.1. Previously I used Postgres 7.4 (I think) on FC4 and even
>> Postgres 8 RC on WinXP, which felt noticeably faster AFAICT. This is
>> running VW on the same machine as the DB. I'm used to this setup to
>> just zip by loading pretty much anything. Now it feels like the
>> database is remote, not local.
>>
>> I didn't try to dig in to figure out what's going on yet, so I have no
>> idea why (it may well be something wrong with my particular setup),
>> but I notice that top shows the postgres daemon very busy at about 90%
>> during Store ops. I believe I managed to turn on the auto-vacuuming
>> feature and even vacuumed manually but didn't see much improvement.
>> Actually now that I think of it, I suspect that all my previous setups
>> used 32-bit OSes (certainly the Windows ones did), whereas my current
>> FC5 and FC6 installs run in 64-bits, and also the postgres server is
>> running in 64-bits. But I still use the 32-bit VW on those.
>>
>> Anyway, I'm curious if anyone else is using similar setup and what's
>> the experience.
>>
>> Thanks,
>>
>> Martin
>>
>>
>
>

--
Janko Mivšek
Svetovalec za informatiko
EraNova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565