Estamos haciendo pruebas en un motor de postgres corriendo en un servidor distinto con sistema operativo Linux Debian, versión de PostgreSQL 8.1, y lo que notamos es que cualquiera sea el proceso de la aplicación cliente de pampa-postgres que llevemos a cabo (desde windows), tarda muchísimo tiempo. La configuración del archivo postgresql.conf esta en ambos servidores igual. ¿Será problema del driver ODBC de la máquina cliente? ¿por qué la diferencia de tiempos en los procesos de la aplicación en una conexión desde cliente(windows)–>servidor(windows) respecto a una cliente (windows)–>servidor(linux)? ¿qué puede ser?
La versión de la aplicación cliente Pampa-Postgres que estamos utilizando es la 5.5.0
Los dos servidores (tanto el de Windows como el de Linux) tienen la misma velocidad de conexión de la red entre clientes y servidores, ambos estan en la misma red.
El archivo de configuración postgresql.conf tiene leves diferencias entre las dos, pero son cosas que modifique para ir personalizando la configuración de acuerdo a nuestras necesidades, para probar (en el servidor de linux) descomenté y seteé algunas líneas como por ejemplo:
max_connections = 40 (por el máximo de conexiones concurrentes que podemos llegar a tener nosotros)
shared_buffers = 1000
max_prepared_transactions = 35
work_mem = 208896
lo demás esta todo igual.
El servidor de Windows tiene un procesador Intel Core 2 Quad CPU de 2.4 GHz, disco de 232 GB y 1,98 GB de PAM con sistema operativo Windows Server 2003.
El servidor de Linux tiene un procesador Intel Xeon CPU 2.8GHz, 1GB de memoria, un raid de disco scsi de 65 Gb.
Por lo que he leído se recomienda poner un 10% del total de la memoria RAM para shared_buffers, y entre un 2% y un 4% de la memoria RAM para work_men.
No entiendo porque los tiempos demoran tanto en Linux, por lo que vos me decís debería ser incluso más rápido.
¿Entonces no tiene nada que ver el driver ODBC de la máquina cliente? Eso lo descarto?
Bueno, nos mantenemos en contacto
Los valores del 10% y 4% son solo unos valores iniciales para empezar a probar.
Todo depende de las aplicaciones y servicios que corra el servidor.
Supongamos que el servidor lo único que corre es Postgres:
Si en el servidor tenes 1GB de memoria, y el S.O te consume 300MB, tranquilamente a postgres le podes poner 500MB.
Asegurate que la memoria que usa postgres nunca vaya a disco (que haga swap) porque sino va a ser lentísimo todo.
Cuando me pones: shared_buffers = 1000, esos 1000 en que unidad estan? Te recomiendo ver un poquito esto. Y si estas usando Postgres 8.2, las unidades las podes poner con MB,KB,etc…
Ejemplo:
shared_buffers = 500MB
work_mem = 80MB
Con respecto a los clientes, los mismo procesan gran parte de la información por lo que un cliente con hardware mas potente sin duda que va a funcionar mucho mas rápido!
El ODBC se encarga de enviar sentencias sql a postgres, por lo que es independiente si postgres escucha estas sentencias desde un servidor linux o uno windows.
Espero que se entienda y que le encuentres la vuelta.
Saludos,
Nico.
Hola Nicolás, finalmente modificando los parámetros de shared_buffers y de work_mem logré que funcionara más rápido en linux. El problema había sido que el espacio que requería el número de buffers que yo le había asignado al parámetro shared_buffers, era superior al tamaño del segmento de memoria compartida del kernel de linux. Así que asigné al kernel de linux un nuevo tamaño de segmento por default SHMMAX (modificando el archivo /etc/sysctl.conf). A shared_buffers le di un 10% del total de la memoria RAM para comenzar a probar
Cuando yo te había puesto shared_buffers = 1000, la unidad es el número de bloques de memoria de 8KB, porque no es postgres 8.2, sino postgres 8.1 así que las unidades no las toma con KB o MB.
Bueno, muchas gracias! Saludos,