Обсуждение: how test postgresql.conf settings?

Hi all,

   I'm testing different configurations of postgresql 8.1 running on
debian. The method I was following was:
   - change the postgresql.conf
   - restart postgres (/etc/init.d/postgresql restart )
   - execute my test queries

  I have noticed that this is not enough to flush the cache, I don't
know where it is, if at the raid controller, at OS or at postgresql
itself. Reboot the machine I don't think it's a good solution because it
takes quite long. Do you have any suggestion? BTW is there any tool to
stress the DB, I mean, create a set of queries to execute and throw a
configurable set of concurrent connections to check the performance?


Thanks to all
--
Arnau

Chandra Sekhar Surapaneni wrote:
> If you HUP the database or reload the database the changes will take
> effect. Only in a very few cases you will have to restart the
> database. Can you give us more information regarding what changes you
> made to the postgresql.conf?
The annotated postgresql conf give you that info... www.powerpostgresql.com

>
> -Chandra Sekhar Surapaneni
>
> ------------------------------------------------------------------------
> *From:* pgsql-admin-owner@postgresql.org on behalf of Arnau Rebassa
> Villalonga
> *Sent:* Wed 2/15/2006 4:39 AM
> *To:* pgsql-admin@postgresql.org
> *Subject:* [ADMIN] how test postgresql.conf settings?
>
> Hi all,
>
>    I'm testing different configurations of postgresql 8.1 running on
> debian. The method I was following was:
>    - change the postgresql.conf
>    - restart postgres (/etc/init.d/postgresql restart )
>    - execute my test queries
>
>   I have noticed that this is not enough to flush the cache, I don't
> know where it is, if at the raid controller, at OS or at postgresql
> itself. Reboot the machine I don't think it's a good solution because it
> takes quite long. Do you have any suggestion? BTW is there any tool to
> stress the DB, I mean, create a set of queries to execute and throw a
> configurable set of concurrent connections to check the performance?
>
>
> Thanks to all
> --
> Arnau
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>


--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl - http://www.commandprompt.com/

Sorry for answering so late, but I didn't notice your answer...

Chandra Sekhar Surapaneni wrote:
> If you HUP the database or reload the database the changes will take
> effect. Only in a very few cases you will have to restart the database.
> Can you give us more information regarding what changes you made to the
> postgresql.conf?

   I was tweaking the Resource usage part shared_buffers, work_mem, ...
The problem is I was restarting the database with:
  /etc/init.d/postgresql restart

The problem is that the result I was getting after the restart were much
better than if I reboot the machine. So I don't know why of that big
difference, if due to postgresql or due the kernel cache or where...

>
> -Chandra Sekhar Surapaneni
>
> ------------------------------------------------------------------------
> *From:* pgsql-admin-owner@postgresql.org on behalf of Arnau Rebassa
> Villalonga
> *Sent:* Wed 2/15/2006 4:39 AM
> *To:* pgsql-admin@postgresql.org
> *Subject:* [ADMIN] how test postgresql.conf settings?
>
> Hi all,
>
>    I'm testing different configurations of postgresql 8.1 running on
> debian. The method I was following was:
>    - change the postgresql.conf
>    - restart postgres (/etc/init.d/postgresql restart )
>    - execute my test queries
>
>   I have noticed that this is not enough to flush the cache, I don't
> know where it is, if at the raid controller, at OS or at postgresql
> itself. Reboot the machine I don't think it's a good solution because it
> takes quite long. Do you have any suggestion? BTW is there any tool to
> stress the DB, I mean, create a set of queries to execute and throw a
> configurable set of concurrent connections to check the performance?


--
Arnau