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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
