From: | Felipe Barousse Boué <fbarousse(at)piensa(dot)com> |
---|---|
To: | Julian Cardona <juliancardonam(at)yahoo(dot)com> |
Cc: | pgsql-ayuda(at)tlali(dot)iztacala(dot)unam(dot)mx |
Subject: | Re: [Pgsql-ayuda] Rendimiento Postgres |
Date: | 2003-02-28 16:04:25 |
Message-ID: | 1046448262.27849.304.camel@monster.piensa.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Julio:
De por sí, el hacer query's a una BD (de hecho sea cual sea, PostgreSQL,
Oracle, etc), a través de ODBC, causa un impacto adicional en los
tiempos del query. Por que ? Pues por que no estas trabajando con una
interface directa al motor de la BD sino por medio de una interface
"genérica" que hace la conversión de tu query al motor de la BD en
cuestión. Eso es el ODBC, por ello, tu query tiene que ejecutar ese
código extra (correspondiente al ODBC) cosa que requiere mas tiempo.
Ahora, creo importante que revises los parámetros de configuración de tu
adaptador ODBC, especialmente los relativos a logging y tracing. Si
estan activos, quítalos. Estos crean otro impacto fuerte en tiempos al
escribir a disco todo lo que hace el ODBC.
El fsync de PostgreSQL, aqui no creo que tengas mayor impacto o
relevancia. Por que? Por que de todas maneras tendrás que leer del disco
(o discos) los datos de la BD. La primera vez que lo hagas será la mas
lenta, las subsecuentes tal vez un poco mas rápidas si tienes cache's
habilitados en tu servidor. El fsync mas bien lo relaciono a entradas de
datos a la BD, para no escribir automáticamente al disco cada cierto
tiempo (lo cual impacta en performance claro) pero con el consecuente
riesgo de pérdida de información si sucede algo como fallar la
alimentación eléctrica.
Otro punto MUY importante y que tiene que ver con el que menciono en el
parráfo de arriba y por supuesto con el performance es la cantidad de
memoria de tu servidor. mientras mas, mejor. Tengo BD en postgresql en
las mismas máquinas que tu (Dell Optiplex GX-240) sólo que con 512 MB, 1
GB y 2 GB de RAM ; se hacen querys complejas y funcionan sin problema,
la memoria de seguro ayuda de manera significativa. 128 MB es poca
memoria, sugiero aumentarla por lo menos a 256 o 512 MB
Por último, tus índices. Asegurate de manejar correctamente los indices
de tu base de datos, es decir, definir correctamente que campos son
llaves primarias, cuales estan indexados, etc. Esto, si esta mal,
definitivamente hará tu BD mas lenta.
Espero esta información te sea útil. Un saludo.
Felipe Barousse Boué
Piensa Technologies - Bufete Consultor de México
www.piensa.com
On Fri, 2003-02-28 at 08:37, Julian Cardona wrote:
> Hola lista, mi pregunta es la siguiente:
> Tengo RH 7.3, corriendo postgres 7.2 ademas de los
> servicios normales, telnet, ftp etc. Tengo una BD con
> una tabla con 82.000 registros y hago un Select un
> poco pesado sobre esta y otras tablas utilizando el
> editor de consultas de Pgaccess, la consulta toma de
> 35 a 45 segundos en realizarce. Tengo un Dell Optiplex
> gx240 con Pentium IV, 128 en RAM y DD 20 Gb. Al hacer
> esta misma consulta desde una estación windows por
> ODBC se demora unos 25 a 30 minutos. Alguien me puede
> decir cual es el problema?, porque se demora tanto? es
> ODBC el problema?, que me pueden recomendar para
> solucionarlo y para aumentar el performance de
> postgres.Mi archivo postgresql.conf es:
> (Alguien sabe una dirección en donde encuentre info
> detallada sobre las opciones de este archivo?, los
> signifocados de cada parametro y sus posibles valores,
> espero me puedan ayudar, de antemano gracias por la
> atanción).
> P.D: es recomendable cambiar el parametro fsync a
> falso para aumentar la velocidad? asi ante un eventual
> problema se pierdan datos? "fsync=false".
>
> tcpip_socket = true
> #ssl = false
>
> max_connections = 500
>
> port = 5432
> #hostname_lookup = false
> #show_source_port = false
>
> #unix_socket_directory = ''
> #unix_socket_group = ''
> #unix_socket_permissions = 0777
>
> #virtual_host = ''
>
> #krb_server_keyfile = ''
>
>
> #
> # Shared Memory Size
> #
> #shared_buffers = 64 # 2*max_connections, min
> 16
> shared_buffers = 1000 # 2*max_connections, min
> 16
> #max_fsm_relations = 100 # min 10, fsm is free
> space map
> #max_fsm_pages = 10000 # min 1000, fsm is free
> space map
> #max_locks_per_transaction = 64 # min 10
> #wal_buffers = 8 # min 4
>
> #
> # Non-shared Memory Sizes
> #
> #sort_mem = 512 # min 32
> #vacuum_mem = 8192 # min 1024
>
>
> #
> # Write-ahead log (WAL)
> #
> #wal_files = 0 # range 0-64
> #wal_sync_method = fsync # the default varies across
> platforms:
> # # fsync, fdatasync, open_sync, or open_datasync
> #wal_debug = 0 # range 0-16
> #commit_delay = 0 # range 0-100000
> #commit_siblings = 5 # range 1-1000
> #checkpoint_segments = 3 # in logfile segments (16MB
> each), min 1
> #checkpoint_timeout = 300 # in seconds, range 30-3600
> #fsync = true
>
>
> #
> # Optimizer Parameters
> #
> #enable_seqscan = true
> #enable_indexscan = true
> #enable_tidscan = true
> #enable_sort = true
> #enable_nestloop = true
> #enable_mergejoin = true
> #enable_hashjoin = true
>
> #ksqo = false
>
> #effective_cache_size = 1000 # default in 8k pages
> #random_page_cost = 4
> #cpu_tuple_cost = 0.01
> #cpu_index_tuple_cost = 0.001
> #cpu_operator_cost = 0.0025
>
>
> #
> # GEQO Optimizer Parameters
> #
> #geqo = true
> #geqo_selection_bias = 2.0 # range 1.5-2.0
> #geqo_threshold = 11
> #geqo_pool_size = 0 # default based on #tables
> in query, range 128-1024
> #geqo_effort = 1
> #geqo_generations = 0
> #geqo_random_seed = -1 # auto-compute seed
>
>
> #
> # Debug display
> #
> #silent_mode = false
>
> #log_connections = false
> #log_timestamp = false
> #log_pid = false
>
> #debug_level = 0 # range 0-16
>
> #debug_print_query = false
> #debug_print_parse = false
> #debug_print_rewritten = false
> #debug_print_plan = false
> #debug_pretty_print = false
>
> # requires USE_ASSERT_CHECKING
> #debug_assertions = true
>
>
> #
> # Syslog
> #
> # requires ENABLE_SYSLOG
> #syslog = 0 # range 0-2
> #syslog_facility = 'LOCAL0'
> #syslog_ident = 'postgres'
>
>
> #
> # Statistics
> #
> #show_parser_stats = false
> #show_planner_stats = false
> #show_executor_stats = false
> #show_query_stats = false
>
> # requires BTREE_BUILD_STATS
> #show_btree_build_stats = false
>
>
> #
> # Access statistics collection
> #
> #stats_start_collector = true
> #stats_reset_on_server_start = true
> #stats_command_string = false
> #stats_row_level = false
> #stats_block_level = false
>
>
> #
> # Lock Tracing
> #
> #trace_notify = false
>
> # requires LOCK_DEBUG
> #trace_locks = false
> #trace_userlocks = false
> #trace_lwlocks = false
> #debug_deadlocks = false
> #trace_lock_oidmin = 16384
> #trace_lock_table = 0
>
>
> #
> # Misc
> #
> #dynamic_library_path = '$libdir'
> #australian_timezones = false
> #authentication_timeout = 60 # min 1, max 600
> #deadlock_timeout = 1000
> #default_transaction_isolation = 'read committed'
> #max_expr_depth = 10000 # min 10
> #max_files_per_process = 1000 # min 25
> #password_encryption = false
> #sql_inheritance = true
> #transform_null_equals = false
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Información de Estados Unidos y América Latina, en Yahoo! Noticias.
> Visítanos en http://noticias.espanol.yahoo.com
> _______________________________________________
> Pgsql-ayuda mailing list
> Pgsql-ayuda(at)tlali(dot)iztacala(dot)unam(dot)mx
> http://tlali.iztacala.unam.mx/mailman/listinfo/pgsql-ayuda
--
Felipe Barousse Boue.
CEO - Director General
Piensa Technologies - Bufete Consultor de Mexico
www.piensa.com
From | Date | Subject | |
---|---|---|---|
Next Message | Manuel Sugawara | 2003-02-28 17:28:07 | Re: [Pgsql-ayuda] RE: [Pgsql-ayuda] Acentos, ñ y signos castellanos |
Previous Message | Alvaro Herrera | 2003-02-28 14:55:15 | Re: [Pgsql-ayuda] Rendimiento Postgres |