Thread: Performance Solaris vs Linux
Hi,
we are using Postgres on both Solaris servers and Linux servers, and Postgres are much slower on Solaris servers. We have tested with different versions of Solaris and Postgres, but the fact remains: Postgres seems to be much faster on Linux server. Does anybody else has the same experience?
Best regards,
Fredrik B
we are using Postgres on both Solaris servers and Linux servers, and Postgres are much slower on Solaris servers. We have tested with different versions of Solaris and Postgres, but the fact remains: Postgres seems to be much faster on Linux server. Does anybody else has the same experience?
Best regards,
Fredrik B
Fredrik Bertilsson escribió: > Hi, > we are using Postgres on both Solaris servers and Linux servers, and > Postgres are much slower on Solaris servers. We have tested with different > versions of Solaris and Postgres, but the fact remains: Postgres seems to be > much faster on Linux server. Does anybody else has the same experience? You haven't specified where the slowness is. Is it that connection establishing is slower? Are queries slower? Is the hardware comparable? Are the filesystems configured similarly? -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever" (Oliver Silfridge)
Fredrik Bertilsson wrote: > Hi, > we are using Postgres on both Solaris servers and Linux servers, and > Postgres are much slower on Solaris servers. We have tested with > different versions of Solaris and Postgres, but the fact remains: > Postgres seems to be much faster on Linux server. Does anybody else has > the same experience? > > Best regards, > Fredrik B I had some performance problems on Solaris a while ago which let to this interesting thread: http://archives.postgresql.org/pgsql-performance/2006-04/thrd4.php#00035 executive summary: - write cache might be (unexpectedly) off by default on sun gear - set explicitly "wal_sync_method = fsync" - some other settings (see thread) Bye, Chris.
Hi Frederick,
There is an article about tunning the performance of PostgreSQL on Solaris at
http://tweakers.net/reviews/649/9
which is not quite exactly of what you wanted but it might help you.
I think that Solaris has disk cache turned off by default which linux does not have
due to possible data loss in case of a power failure.
Regards,
Julo
Fredrik Bertilsson wrote:
There is an article about tunning the performance of PostgreSQL on Solaris at
http://tweakers.net/reviews/649/9
which is not quite exactly of what you wanted but it might help you.
I think that Solaris has disk cache turned off by default which linux does not have
due to possible data loss in case of a power failure.
Regards,
Julo
Fredrik Bertilsson wrote:
Hi,
we are using Postgres on both Solaris servers and Linux servers, and Postgres are much slower on Solaris servers. We have tested with different versions of Solaris and Postgres, but the fact remains: Postgres seems to be much faster on Linux server. Does anybody else has the same experience?
Best regards,
Fredrik B
Is there any way to stop the autovacuum if it is running longer than 10 min or so?
Is it good idea to kill autovacuum if it is running longer than expected?
In my OLTP system, we are inserting, updating and deleting the data every second.
Autovacuum started and never finished slowing down the whole system.
Any help?
Thanks
Regards
sachi
On 8/21/07, Sachchida Ojha <sojha@secure-elements.com> wrote: > > > Is there any way to stop the autovacuum if it is running longer than 10 min > or so? > > Is it good idea to kill autovacuum if it is running longer than expected? > > In my OLTP system, we are inserting, updating and deleting the data every > second. > > Autovacuum started and never finished slowing down the whole system. It's probably better to adjust the sleep parameters in postgresql.conf and then pg_ctl reload You can kill the autovacuum backend, but it will just start up again when the sleep time has passed.