Base de datos de optimizaciones / ajuste

Afinar los parámetros de su base de datos para extraer el máximo de él!

Hola,

Estas son algunas de mis experiencias, mientras que i es la construcción de un motor de búsqueda y optmising la base de datos PostgreSQL a Sonic-velocidades!

Nuestra configuración para el servidor Postgresql fue la siguiente:
Redhat 7.2
PIV 2,00 Ghz sistema
1024MB RAM

Una de las primeras cosas que noté después de encender el programa de Servlet, fue que, aunque las preguntas fueron devueltos casi tan rápido como en el anterior sistema basado en MySQL, la carga en el servidor es mucho mayor. Entonces empecé a ir abajo en el profundo detalles de las cosas. Tuve antes de MySQL optimizado mucho por el aumento de caché y el tamaño de buffer y por tirar más hacia la RAM el problema. La única cosa más grande que uno tiene que hacer antes de ejecutar Postgresql, es proporcionar suficiente espacio de búfer compartida. Pero entonces,
¿Cuánto es suficiente?
Hay un acalorado debate sobre el mismo, entre las personas que dicen que, lógicamente, toda la RAM puede ser dedicado como contra aquellos que dicen que tirar más de memoria RAM después de un cierto límite no tiene ningún uso. El más caché compartida de amortiguación que tiene, mayor es el porcentaje de su base de datos que ni las causas read () 's de memoria ni la copia de la OS de amortiguación cache.But general, se cache un menor número de bloques, ya que se les doble buffering . Cuando se copia un bloque de la OS de amortiguación a la memoria compartida, la copia todavía existe en el sistema operativo de amortiguación. Así que ahora es bloquear el buffer de dos veces. Un solo disco I / O es mucho más caro que cientos de ejemplares entre el sistema operativo buffer cache y postgres "la memoria compartida. También se tendrá en cuenta todas las otras cosas que estás haciendo en la máquina - sólo pequeñas cosas, como cron y tal. Todo lo que tenga memoria. Por lo tanto, es peligroso no dejar que el OS gestionar una buena parte de la memoria.
Ocurre que estos dos factores podrían representar y hacer algo de una línea cada uno. El punto ideal sería que se cruzaron.

Además yo también optimizar consultas SQL adaptados específicamente para mi propósito. Uno de los principales inconveniente en PostgreSQL se encuentra en la aplicación de la evaluación de las consultas que contengan 'en' y 'existe'. Supongamos:
Consulta 1. SELECT * FROM db1 EN DONDE ID ((SELECT id de DB2 DONDE palabra = 'cualquier')) LIMIT 20;
Consulta 2. SELECT * FROM db1 EN DONDE ID (1234,2345,1242,1256,1245,1567,2222,22345234567456,35,56);

(ID que es la clave principal)

La consulta más tarde se escanea utilizando el índice de ID, mientras que el ex ejecuta en una secuencia de exploración. Creo que esto se llama "error de piloto" en que la base de datos se ejecuta la subconsulta para cada fila de la consulta exterior. En cambio, si utilizamos UNE explícito (como se indica a continuación), entonces podría forzar la base de datos para utilizar un índice en lugar de exploración.
Final de Consulta:
select * from db1, uno de DB2, DB2 b
donde id = a.id y a.word = 'word1 "
id = y b.id y b.word = 'word2 "
etc

NOTA: También puede ejecutar en una secuencia de exploración, en lugar de esperar un índice de exploración, si el número de tuplas a ser escaneados de más de 30-40% del total de tuplas en la tabla. Aunque esto puede variar cambiando las ponderaciones asignadas a random_page_cost, cpu_tuple_cost, cpu_index_cost y cpu_operator_cost utilizados por el optimizador para realizar estas decesions.

También me decidió a lanzar más RAM para el efecto. I asignados 64 MB de RAM compartida hacia el espacio de búfer. El archivo / var / lib / pgsql / data / postgresql.conf Contiene la configuración del servidor de base de datos. PostgreSQL utiliza el sistema de memoria compartida como un buffer. En un sistema Linux, puede ver la cantidad de memoria compartida fue asignado por su sistema ejecutando el comando:
cat / proc / sys / kernel / shmmax
Y para ver el uso de memoria compartida en el sistema:
ipcs
El resultado será en bytes. Por defecto, Red Hat Linux 7.2 asigna 32 MB de memoria compartida, lo que podría no ser suficiente para PostgreSQL. I el aumento de este límite de 64MB por hacer el comando:
67108864 echo> / proc / sys / kernel / shmmax

Es necesario incluir esta línea en su archivo de inicio postgresql, o editando el archivo / etc / rc.d / rc.local para un archivo de carácter más permanente en nuestra setting.Then postgresql.conf he shared_buffers a 8192.I también nuestra sort_mem a 16384 (16Megs una especie de zona de memoria). Desde la agrupación de conexiones era en efecto, me puse a max_connections 50.
Fsync y también se establece en falso.

shared_buffers = 8192
sort_mem = 16384
max_connections = 50
fsync = false

Un tirón he encontrado inicialmente fue que el sistema tuvo que construir y derribar un postgresql relación con cada solicitud. Esto es intolerable, por lo que empezó a utilizar la conexión de la puesta en común características que proporciona la resina (http://caucho.com).

-----
Varun

Agradecimientos: Curt, Bruce, Andrew y para la limpieza de todas mis dudas!