RE: [PERFORM] exponentia​l performanc​e decrease, problem with version postgres + RHEL?

John Nash wrote:
> We have being doing some testing with an ISD transaction and we had
> some problems that we posted here.
>
> The answers we got were very kind and useful but we couldn't solve the problem.

Could you refer to the threads so that you don't get the same advice again?

> We have doing some investigations after this and we are thinking if is
> it possible that OS has something to do with this issue. I mean, we
> have two hosts, both of them with OS = Red Hat Enterprise Linux Server
> release 6.2 (Santiago)
>
> But when doing "select * from version()" on the postgres shell we obtain:
>
> sessions=# select * from version();
> version
> ------------------------------------------------------------------------------------------------------
> --------
> PostgreSQL 9.1.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
> 4.4.6 20110731 (Red Hat 4.4.6-3), 64-bit
> (1 row)
>
> We don't understand why in here it's written "(Red Hat 4.4.6-3)".
>
> Is it possible that we have installed a postgres' version that it's
> not perfect for the OS?

It means that the PostgreSQL you are using was compiled with a
compiler that was compiled on RHEL4. Shouldn't be a problem.

> But if this is a problem, why are we obtaining a normal perform on a
> host and an exponential performance decrease on another?
>
> And how can we obtain a normal performance when launching the program
> which does the queries from another host (remote url) but when
> launching it in the same host we obtain this decrease on the
> performance?

Try to identify the bottleneck.
Is it disk I/O, CPU, memory or something else?

> name |
> current_setting
>
> --------------------------+---------------------------------------------------------------------------
> -----------------
> ------------------
> version | PostgreSQL 9.1.3 on
> x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20110731 (Red
> Hat
> 4.4.6-3), 64-bit
> archive_mode | off
> client_encoding | UTF8
> fsync | on
> lc_collate | en_US.UTF-8
> lc_ctype | en_US.UTF-8
> listen_addresses | *
> log_directory | pg_log
> log_filename | postgresql-%a.log
> log_rotation_age | 1d
> log_rotation_size | 0
> log_truncate_on_rotation | on
> logging_collector | on
> max_connections | 100
> max_stack_depth | 2MB
> port | 50008
> server_encoding | UTF8
> shared_buffers | 32MB

Now that sticks out as being pretty small.
Try 1/4 of the memory available for the database, but not
more than 2 GB.

> synchronous_commit | on
> TimeZone | Europe/Madrid
> wal_buffers | 64kB

That's also pretty small.

> wal_sync_method | fsync
> (22 rows)

Yours,
Laurenz Albe