La base de datos es un caché grande. Optimización del uso de la memoria. Escribir registros de transacciones en el disco
En nuestra oficina ha aparecido un megaprograma de contabilidad operativa. Los programadores lo están esculpiendo desde hace un año, casi todos los empleados de oficina trabajan allí, sin él ahora no hay vida en la compañía eléctrica regional. El programa no funciona, la oficina está, en cierto sentido, paralizada.
Ahora hay alrededor de 700 usuarios en el sistema, con hasta 100 usuarios activos.
Naturalmente, la cuestión del rendimiento ahora es primordial (si contamos desde cero, la tarea número 0, la tolerancia a fallos, se resolverá en un futuro próximo). Mi tarea como administrador es exprimir todo lo posible de la base de datos. Se trata de la versión 8.2 de PostgreSQL, desde la cual actualmente se está realizando una migración de prueba a la 9.0.
Aquí verá el archivo de parámetros postgresql.conf con comentarios extendidos para cada elemento.
La configuración de cada parámetro se eligió en función de la experiencia operativa existente, la investigación de al menos 3 fuentes abiertas, la documentación oficial y las pruebas de rendimiento de la aplicación en el servidor en la configuración más idéntica a DB 8.2. y 9.0.
# Archivo de parámetros de PostgreSQL postgresql.conf
# Intentando hacer volar la base EnergyNET como un halcón.
# Estas configuraciones asumen que en el servidor donde
# PostgreSQL está girando, no hay nadie más excepto él
# Sistema operativo.
#########################################################
#buffers_compartidos
#
# Significado del parámetro: PostgreSQL no lee datos directamente
# del disco y no los escribe directamente en el disco. Los datos se están cargando.
# al búfer compartido del servidor, ubicado en la memoria compartida,
# el servidor procesa bloques de lectura y escritura en este búfer,
# y luego los cambios se descargan en el disco.
# Si un proceso necesita acceso a una tabla, primero debe
# busca los bloques necesarios en el búfer compartido. si bloques
# están presentes, entonces puede continuar funcionando si
# no: se realiza una llamada al sistema para cargarlos.
# Los bloques se pueden cargar tanto desde el caché de archivos del sistema operativo como desde
# desde el disco, y esta operación puede resultar bastante costosa.
# Si el tamaño del buffer es insuficiente para almacenar con frecuencia
# de datos de trabajo utilizados, entonces serán permanentes
# escrito y leído desde la caché del sistema operativo o desde el disco, lo cual es extremadamente
# tendrá un impacto negativo en el rendimiento.
# El principio es que se establece el valor del parámetro.
# en la cantidad del 25-40% de RAM. De la versión
# PostgreSQL independiente.
#
buffers_compartidos = 500 MB # 2 GB de RAM
#búferes_compartidos = 3000 MB # 12 GB de RAM
#temp_buffers
#
# Significado del parámetro: Cantidad máxima de memoria asignada
# cada sesión para trabajar con tablas temporales.
# Hay que recordar que una vez que la sesión ha cogido tamaño,
# especificado en temp_buffers, esta memoria no se libera,
# hasta que finalice la sesión. En sistemas con grandes
# número de usuarios simultáneos
# valor incorrecto (sobreestimado) de este parámetro
# puede conducir fácilmente a un intercambio loco, y cómo
# consecuencia, la caída del sistema operativo. Y si en
# esto también significa fsync = desactivado, luego prepárate para restaurar
# base de datos de copias de seguridad.
# No utilizamos tablas temporales, por lo que
# puedes dejar el valor predeterminado. Eso es
# eliminar de postgresql.conf por completo
#
buffers temporales = 8 MB
#max_transacciones_preparadas
#
# Significado del parámetro: establece el número máximo
# TRANSACCIÓN PREPARADA que se puede configurar en
# estado preparado al mismo tiempo.
# Tenemos el 98% de todas las transacciones - PREPARADAS.
# Valor de parámetro mínimo requerido = max_connections
#
max_transacciones_preparadas = 600
#mem_trabajo
#
# Significado del parámetro: Establece la cantidad de memoria que se utiliza
# operaciones de clasificación internas y tablas hash antes
# cómo pasar al uso de archivos temporales en el disco.
# Si no hay suficiente memoria para ordenar algunos
# resultado, entonces el proceso del servidor utilizará
# archivos temporales. Si el tamaño de la memoria es demasiado grande,
# esto puede dar lugar a un intercambio.
# En una consulta compleja, varios
# operaciones de clasificación y hash, y cada una puede tomar
# tanta memoria como se especificó en este parámetro antes
# que comenzará a utilizar archivos temporales. Además, estos
# operaciones se pueden realizar simultáneamente en múltiples sesiones.
# Así, la memoria utilizada puede ser varias
# veces mayor que work_mem. Se utilizan operaciones de clasificación.
# para operaciones ORDER BY, DISTINCT y unión de métodos
# fusionar uniones. Las tablas hash se utilizan cuando
# operaciones de unión hash,
# operaciones de agregación basadas en hash y
# procesamiento de subconsultas IN basadas en hash.
# En sus propias palabras: si alguna de las operaciones enumeradas anteriormente requiere
# para realizar más memoria de la especificada en el parámetro work_mem,
# para esta operación se creará un archivo temporal en el directorio pgsql_tmp
# la base de datos correspondiente. Así que calcule cuánto volumen necesita configurar
# Se puede acceder a este parámetro simplemente en este directorio en el pico
# horas de carga. Si el volumen total de archivos creados allí cabe
# en RAM y quedará al menos el 30% de la reserva, teniendo en cuenta
# otras tareas que se ejecutan en el servidor, luego puede establecer un valor igual a
# archivos de aproximadamente el mismo tamaño. Aquí, por supuesto, también
# fanatismo, porque si el archivo temporal tiene más de 100 metros, entonces necesitas
#piensa tres veces...
#
memoria_trabajo = 32 MB
# autovacío
#
# El significado es simple: ejecución automática de procesos VACUUM.
# modo mientras el servidor está en ejecución.
# Ejecutaremos VACUUM y ANALYZE por la noche.
# vía CRON, por lo que no encenderemos el autovacío.
# Bueno, no es necesario que tengamos un sistema también durante el horario laboral.
# cargar con cosas no críticas.
#
vacío automático = apagado
#concurrencia_io_efectiva
#
# Significado del parámetro: Establece el número de operaciones de lectura/escritura en
# disco que PostgreSQL cree que se puede ejecutar
# simultáneamente. Aumentar este valor puede aumentar
# número de operaciones de E/S que cualquier sesión
# PostgreSQL puede intentar ejecutarse en paralelo.
# Los valores válidos oscilan entre 1 y 1000,
# o 0 si desea deshabilitar la ejecución asincrónica
# Operaciones de E/S.
# Para estimar el valor requerido de este parámetro, puede
# comenzar con la cantidad de dispositivos individuales, incluido RAID 0
# o RAID 1 utilizado por la base de datos. Para RAID 5
# La paridad de dispositivos no se tiene en cuenta. Sin embargo, si la base
# datos suelen estar ocupados por muchas solicitudes recibidas de
# diferentes sesiones simultáneas, incluso valores bajos
# puede mantener ocupada la matriz de discos. El valor es mayor
# necesario para mantener los discos ocupados resultará
# solo para carga adicional procesador.
# Simplemente ponga el valor del parámetro en un número,
# igual al número de ejes en los discos, por
# donde se encuentra la base de datos. Luego tratamos de reducir
# o aumentar, y evaluar el resultado con cada cambio
# parámetro. En general el parámetro es nuevo, poco probado,
# Hay pocas recomendaciones. Entonces lo probaremos.
#
Effective_io_concurrency = 4 # 4 discos en RAID10
# fsincronización
#
# Significado del parámetro: Este parámetro es responsable de restablecer los datos.
# del caché al disco cuando se completan las transacciones. Si
# establece su valor fsync = off entonces no habrá datos
# escribir en las unidades de disco inmediatamente después de finalizar
# operaciones. Esto puede mejorar significativamente la velocidad.
# operaciones de inserción y actualización, pero existe el riesgo de dañar la base de datos,
# si ocurre una falla (corte de energía inesperado,
# Fallo del sistema operativo, fallo del subsistema del disco).
# El parámetro de perra más tonta. Si es posible,
# SIEMPRE use fsync = activado. Si con rendimiento
# culo, luego cuando el valor está desactivado la mayoría de problemas posibles
# decidir. Esto es una mierda tan ambigua. En Windows
# Es recomendable no apagarlo por el propio buggy
#Ventanas.
# Si fsync = desactivado, asegúrese de instalar
# full_page_writes = desactivado
# Si fsync = on y hay problemas de rendimiento, entonces
# es mejor jugar con synchronous_commit, pero fsync no
# tocar.
#
fsync=activado
# escrituras de página completa
#
# Significado del parámetro: Si este parámetro está habilitado, el servidor
# PostgreSQL escribe todo el contenido de cada página del disco en WAL
# durante el primer cambio a esta página después de la prueba
# puntos. Esto es necesario porque si durante el proceso de grabación
# páginas experimentarán una falla del sistema, el disco puede terminar
# una página que combina datos antiguos y nuevos. Cambios
# en el nivel de fila de datos que normalmente se almacenan en WAL, puede
# puede no ser suficiente para restaurar la página después
# fallo del sistema. Almacenar una imagen de toda la página garantiza que
# que la página se restaurará correctamente, pero lo hará
# costará el aumento en la cantidad de datos que se necesitarán
# poner en WAL. (Dado que leer WAL siempre comienza con
# punto de interrupción, es conveniente hacer esto en el primer cambio
# cada página después del punto de control. De este modo,
# una forma de reducir el costo de escribir páginas
# es aumentar el intervalo entre puntos de control.)
# Deshabilitar esta opción acelera las cosas, pero puede causar
# a la corrupción de la base de datos en caso de falla del sistema o
# apagado. Los riesgos son similares a deshabilitar fsync, aunque
# en este caso son más pequeños.
#
full_page_writes=activado
# compromiso_sincrónico
#
# Significado del parámetro: Determina si la transacción debe esperar
# mientras que los registros WAL se descargarán en el disco antes del comando
# devolverá un mensaje de éxito al cliente. Por
# de forma predeterminada y desde el punto de vista de la seguridad, esta opción debería
# estar habilitado. Si la opción está deshabilitada, puede haber una brecha
# tiempo entre mensajes de éxito de transacción
# y el punto en el que la transacción está realmente a salvo de fallas
# en el servidor. A diferencia de fsync, deshabilitar esta opción
# no puede correr el riesgo de incoherencia en la base de datos: falla
# puede causar que se pierdan las transacciones más recientes, pero
# el estado de la base de datos será como si estos
# transacciones simplemente se cancelaron. Entonces el cierre
# synchronous_commit puede ser útil si
# el rendimiento es más importante que la precisión en la ejecución
# transacciones.
#
compromiso_sincrónico = desactivado
Effective_cache_size: le dice al programador el tamaño del objeto más grande en la base de datos que, en teoría, se puede almacenar en caché. En un servidor dedicado, tiene sentido establecer Effective_cache_size en 2/3 de la RAM total; en un servidor con otras aplicaciones, primero debe restar el tamaño de la cantidad total de RAM caché de disco SO y memoria ocupada por otros procesos.
La cuestión de qué DBMS (Postgresql o MS SQL para 1C es el más óptimo) ha sido objeto de muchos artículos. En este artículo, veremos los pasos de optimización para ambos. El DBMS de cada proveedor tiene sus propias recomendaciones de configuración y recomendaciones de 1C. Cabe señalar que dependiendo del equipo, la configuración del servidor y la cantidad de usuarios que configuran diferentes cargas, los detalles del proceso de optimización del DBMS para 1C y la implementación de recomendaciones pueden cambiar.
Configurando PostgreSQL para 1C
La experiencia en la operación de bases de datos 1C en PostgreSQL ha demostrado que el mayor rendimiento y rendimiento óptimo 1C y PostgreSQL se implementaron en Linux, por lo que es recomendable utilizarlo. Pero independientemente del sistema operativo, es importante recordar que la configuración predeterminada especificada al instalar PostgreSQL está destinada únicamente a iniciar el servidor DBMS. ¡No se puede hablar de explotación industrial! El siguiente paso después del lanzamiento será Optimización de PostgreSQL bajo 1C:
- Para empezar, desactivamos el ahorro de energía (de lo contrario, los retrasos en las respuestas de la base de datos pueden aumentar de forma impredecible) y prohibimos el intercambio de memoria compartida.
- Configuramos los parámetros básicos del servidor DBMS (las recomendaciones de configuración se describen con suficiente detalle, tanto en el sitio web oficial del proveedor como en 1C, por lo que nos centraremos solo en los más importantes).
- Las recomendaciones estándar de la empresa 1C sugieren deshabilitar los mecanismos HyperThreading. Pero probar Postgres-pro en servidores con SMT (multithreading simultáneo) habilitado mostró resultados diferentes.
Instalación de PostgreSQL
Instalar 1C en PostgreSQL en Windows es un proceso bastante simple. Al iniciar paquete de instalación Debe especificar la codificación UTF-8. De hecho, este es el único matiz interesante y no se requiere ninguna configuración adicional de PostgreSQL para 1C 8.3 desde Windows. Instalar y configurar PostgreSQL para 1C en el sistema operativo Linux puede causar una serie de dificultades. Para superarlos, como ejemplo, consideremos ejecutar (utilizando kits de distribución del proveedor líder ruso PostgreSQL-Pro y la empresa 1C) PostgreSQL en un servidor Ubuntu 16.04 x64.
Instalación de kits de distribución 1C para DBMS PostgreSQL
1.Descargue la posición de distribución especificada SGBD PostgreSQL:
2. Cargue PostgreSQL al servidor;
3.Puedes descomprimir el instalador de DBMS PostgreSQL con el comando:
tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz24.Antes de instalar el kit de distribución DBMS PostgreSQL, verifiquemos la presencia de la configuración regional requerida en el sistema (por defecto ru_RU.UTF-8):
5.Si el sistema con el que funcionará PostgreSQL se instaló en un idioma distinto al ruso, deberá crear nuevas configuraciones regionales:
locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-reconfigure locales6.Si la configuración regional requerida todavía está disponible, instálela de forma predeterminada:
locale –a nano /etc/default/locale Reemplace el contenido con LANG=ru_RU.UTF-87.Después de reiniciar, instale paquetes requeridos para nuestro Versiones de PostgreSQL:
apt-get instala libxslt1.1 certificado ssl8.La versión 9.4.2-1.1C del paquete PostgreSQL está vinculada a la versión libicu48 del paquete libicu. en el repositorio la versión requerida ya no está disponible, puedes descargarlo;
9.Descargue y colóquelo en el directorio donde se almacenan los archivos descargados para PostgreSQL;
10.Al dirigirnos al directorio con los archivos PostgreSQL, realizamos la instalación escribiendo secuencialmente los siguientes comandos:
CD<Путь к папке с файлами>dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dpkg -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.1C_amd64.deb11.Hecho. El paquete de distribución PostgreSQL DBMS está instalado.
Instalación de distribuciones PostgreSQL-Pro
Para instalar el servidor, debe ejecutar los siguientes comandos sucesivamente:
sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --quiet -O - http:// 1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get update sudo apt-get install postgresql-pro-1c-9.4Para acceder al servidor, edite los parámetros en el archivo. pg_hba.conf
cd<Путь до каталога pg_hba.conf>cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust" > pg_hba.conf" bash -c "echo "host all all all md5" >> pg_hba.conf"El archivo en sí tiene la siguiente estructura:
El expediente está bien documentado, pero en inglés. Veamos brevemente los parámetros principales:
- Local conexión local sólo a través de Unix
- Anfitrión conexión TCP/IP
- Anfitrión conexión SSL cifrada a través de TCP/IP (el servidor debe estar construido con soporte SSL, el parámetro ssl también debe estar configurado)
- Hostnossl conexión no cifrada a través de TCP/IP
- confianza admitir sin autenticación
- rechazar rechazar sin autenticación
- contraseña solicitud de contraseña en texto claro
- md5 solicitud de contraseña en formato MD5
- ldap verificar el nombre de usuario y la contraseña utilizando el servidor LDAP
- radio Verificación de nombre de usuario y contraseña mediante el servidor RADIUS
- pam verificar el nombre de usuario y la contraseña mediante el servicio de complemento
Puede encontrar información más detallada y detallada en la documentación del producto PostgreSQL.
root@NODE2:/home/asd# servicio --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# servicio postgresql start root@NODE2:/home/asd# servicio --status-all | grep postgres [+] postgresqlDespués de completar la instalación básica, debe configurar archivo de configuración servidor postgresql.conf, de acuerdo con las características específicas de PostgreSQL, el servidor 1C y la configuración del servidor Ubuntu.
Optimización de 1C para MS SQL Server
Instalación de las últimas actualizaciones para SQL Sever.
El sistema operativo reserva espacio y lo llena de ceros, lo que lleva bastante tiempo en los siguientes eventos:
- Creación de una base de datos;
- Agregar archivos de datos, registro de transacciones, a una base de datos existente;
- Aumento de tamaño archivo existente(incluidas las operaciones de crecimiento automático);
- Restauramos bases de datos o grupos de archivos.
se esta decidiendo este problema agregando la función (bajo la cual se ejecuta el servidor) al elemento de la política de seguridad local "Realizar tareas de mantenimiento de volumen".
Si es posible, es necesario distribuir la base de datos TempDB (se usa especialmente en el modo de bloqueo administrado RCSI) y el registro de transacciones en diferentes discos.
En el servidor donde funciona. servidor SQL, el modo de ahorro de energía debe configurarse en "Alto rendimiento".
La carpeta con los archivos de la base de datos no debe estar comprimida.
En la pestaña "Memoria" del servidor, establecemos el nivel mínimo en el 50% de la memoria total. Calculamos el máximo usando una de las fórmulas:
- Memoria máxima = Volumen total - tamaño según sistema operativo - tamaño para 1C (si existe, habiendo medido previamente la memoria utilizada con contadores) o
- Memoria máxima = Tamaño total – (1024* Tamaño total/16384).
Limitamos el parámetro DOP "Grado máximo de paralelismo" y lo configuramos en "1".
Actualizamos las estadísticas según cronograma. A partir de SQL Server 2008, la actualización de las estadísticas hace que las consultas se vuelvan a compilar y, por lo tanto, borra el caché de procedimientos, por lo que no es necesario realizar un procedimiento independiente para borrar el caché de procedimientos.
Periódicamente volvemos a indexar la tabla y desfragmentamos los índices.
Establecemos la correcta política de reservas. Si no necesita recuperarse hasta el último momento antes de una falla del sistema, y los últimos 5 minutos o más no son críticos para su negocio, configure el modelo de recuperación en "Simple". Esto acelerará significativamente la velocidad de grabación. Lo principal es que la copia de seguridad diferenciada se pueda completar dentro del tiempo especificado.
Logramos mejoras al trabajar con TempDB durante la E/S mediante la creación de archivos de datos adicionales. Si hay menos de 8 procesadores lógicos, se recomienda crear un archivo de datos para cada procesador lógico. Si hay más de 8 procesadores lógicos, se recomienda crear 8 archivos de datos y, aumentando en uno en múltiplo de 4, asegúrese de estimar la carga en TempDB.
Especifica la cantidad de memoria que utilizará el servidor de bases de datos para los buffers de memoria compartida. Por defecto, esto suele ser 128 megabytes (128 MB), pero puede ser menos si la configuración de su kernel lo impone. restricciones adicionales(Esto está determinado por el proceso initdb). Este valor no debe ser inferior a 128 kilobytes. (Este mínimo depende del valor de BLCKSZ). Sin embargo, generalmente se requieren valores mucho mayores para un buen rendimiento. Puede configurar este parámetro solo cuando el servidor se está iniciando.
Si está ejecutando un servidor dedicado con 1 GB o más de RAM, un valor inicial razonable para los búferes compartidos sería el 25 % de la memoria. Hay escenarios de carga de trabajo en los que valores de Shared_buffers aún mayores serán efectivos, pero dado que PostgreSQL también usa el caché del sistema operativo, es poco probable que sea útil dedicar más del 40% de la RAM a Shared_buffers. Al aumentar los búferes compartidos, normalmente es necesario aumentar max_wal_size en consecuencia para alargar el proceso de escritura. gran volumen datos nuevos o modificados durante un período de tiempo más largo.
Los servidores con menos de 1 GB de RAM deberían utilizar un porcentaje menor de RAM para dejar suficiente memoria para el sistema operativo. Además, los valores de Shared_buffers grandes no son tan eficientes en Windows. Quizás recibas mejores resultados, si mantiene este valor relativamente pequeño y confía más en la memoria caché del sistema operativo. Los valores óptimos de Shared_buffers para Windows suelen oscilar entre 64 y 512 megabytes.
páginas_enormes (enumeración)
Activa/desactiva el uso de páginas de memoria enormes. Los valores válidos son try (predeterminado), activado y desactivado.
Actualmente, esto solo es compatible con Linux. En otros sistemas, el valor de prueba simplemente se ignora.
Cuando Huge_pages está configurado en try, el servidor intentará utilizar páginas enormes, pero puede volver a páginas normales si eso falla. Con el valor activado, si falla el uso de páginas grandes, el servidor no se iniciará. Sin el valor, no se utilizarán páginas grandes.
temp_buffers (entero) Establece el número máximo de búferes temporales para cada sesión. El tamaño predeterminado de los búferes temporales es de ocho megabytes (1024 búferes). Esta configuración se puede cambiar en una sesión separada, pero solo antes del primer acceso a las tablas temporales; Después de esto, no podrá cambiar su valor para la sesión actual. La sesión asigna buffers temporales según sea necesario hasta que se alcanza el límite. especificado por parámetro temp_buffers. Si una sesión no utiliza buffers temporales, entonces solo se almacenan descriptores de buffer, que ocupan aproximadamente 64 bytes (como temp_buffers). Sin embargo, si el buffer realmente se utiliza, ocupará 8192 bytes adicionales (o caso general
, BLCKSZ bytes). max_prepared_transactions (entero) condición (ver PREPARAR TRANSACCIÓN). Cuando se establece en cero (el valor predeterminado), el motor de transacciones preparadas se desactiva. Puede configurar este parámetro solo cuando el servidor se está iniciando.
Si no planea utilizar transacciones, esta configuración debe borrarse para evitar que se creen transacciones preparadas sin darse cuenta. Si se utilizan transacciones preparadas, entonces max_prepared_transactions probablemente no debería ser menor que max_connections para que se pueda preparar una transacción en cada sesión.
Para un servidor esclavo, el valor de este parámetro debe ser mayor o igual que el valor en el maestro. De lo contrario, no se permitirán solicitudes en el servidor esclavo.
work_mem (entero) Especifica la cantidad de memoria que se utilizará para la clasificación interna y las operaciones de tabla hash antes de utilizar archivos temporales en el disco. El valor predeterminado es cuatro megabytes (4 MB). Tenga en cuenta que en consultas complejas, es posible que se ejecuten simultáneamente varias operaciones de clasificación o hash, por lo que esta cantidad de memoria estará disponible para cada operación. Además, dichas operaciones se pueden realizar simultáneamente en diferentes sesiones. Por tanto, la cantidad total de memoria puede ser muchas veces mayor que el valor de work_mem; esto debe tenerse en cuenta a la hora de elegir el valor adecuado. Las operaciones de clasificación se utilizan para ORDER BY, DISTINCT y fusionar uniones. Las tablas hash se utilizan para uniones y agregaciones hash, y para procesar subconsultas IN mediante hashes.
mantenimiento_work_mem (entero) Conjuntos volumen máximo
memoria para operaciones de mantenimiento de bases de datos, en particular VACUUM, CREATE INDEX y ALTER TABLE ADD FOREIGN KEY. Por defecto, su valor es 64 megabytes (64 MB). Dado que solo se puede ejecutar una operación de este tipo en una sesión a la vez y, por lo general, no se ejecutan en paralelo, este valor puede ser mucho mayor que work_mem. Aumentar este valor puede conducir a operaciones de limpieza y restauración más rápidas de la base de datos a partir de una copia. Tenga en cuenta que cuando se ejecuta autovacuum, esta cantidad puede asignarse por autovacuum_max_workers veces, así que no establezca el valor predeterminado demasiado alto. Puede ser mejor administrar la cantidad de memoria para autovacuum por separado cambiando .
replacement_sort_tuples (entero) Cuando el número de tuplas a ordenar es menor que un número específico, se utilizará la selección con reemplazo para obtener el primer flujo de datos a ordenar. Esto puede ser útil en sistemas con memoria, cuando las tuplas que ingresan a la entrada de una operación de clasificación grande se caracterizan por una buena correlación de orden físico y lógico. Tenga en cuenta que esto no se aplica a tuplas con contrarrestar correlación. Es posible que el algoritmo de selección con reemplazo produzca un flujo largo y no sea necesario fusionarlo, mientras que la estrategia predeterminada puede producir muchos flujos que luego deban fusionarse para producir el resultado final ordenado. Esto le permite acelerar las operaciones de clasificación.
El valor predeterminado es 150.000 tuplas. Tenga en cuenta que aumentar este valor no suele ser muy útil e incluso puede resultar contraproducente, ya que la eficiencia de la cola de prioridad depende de la memoria caché de la CPU disponible, mientras que con la estrategia estándar los subprocesos se ordenan. caché independiente algoritmo. Gracias a esto, la estrategia estándar le permite utilizar de forma automática y transparente la memoria caché del procesador disponible de una manera más eficiente.
Si Maintenance_work_mem se establece en su valor predeterminado, las clasificaciones externas en equipos de servicio(por ejemplo, las clasificaciones realizadas mediante los comandos CREATE INDEX para crear un índice de un árbol B) normalmente nunca usan selección con reemplazo (ya que todas las tuplas caben en la memoria) a menos que las tuplas de entrada sean lo suficientemente grandes. autovacuum_work_mem (entero)
Establece la cantidad máxima de memoria que utilizará cada proceso de trabajo de autovacuum. El valor predeterminado es -1, lo que significa que este volumen está determinado por el valor. Esta opción no afecta el comportamiento del comando VACUUM cuando se ejecuta en otros contextos.
Si max_stack_ Depth excede el límite real del kernel, entonces una función con recursividad ilimitada podría bloquear un proceso de servidor individual. En sistemas donde PostgreSQL puede detectar el límite establecido por el kernel, no permitirá que este parámetro se establezca en un valor no seguro. Sin embargo, no todos los sistemas proporcionan esta información, por lo que este valor debe seleccionarse con precaución. tipo_memoria_compartida_dinámica (enumeración)
Selecciona el mecanismo de memoria compartida dinámica que utilizará el servidor. Opciones válidas: posix (para asignar memoria compartida POSIX con la función shm_open), sysv (para asignar memoria compartida System V con la función shmget), windows (para asignar memoria compartida en Windows), mmap (para emular memoria compartida mediante archivos de mapeo de memoria almacenado en el directorio de datos) y ninguno (para desactivar esta funcionalidad). No todas las opciones son compatibles diferentes plataformas; la primera opción admitida por una plataforma determinada se convierte en su opción predeterminada. Generalmente no se recomienda el uso de mmap, que no está seleccionado en ningún lugar de forma predeterminada, ya que el sistema operativo puede escribir periódicamente páginas modificadas en el disco, lo que creará una carga adicional; sin embargo, puede resultar útil para depurar cuando el directorio pg_dynshmem está en el disco RAM o cuando otros mecanismos de memoria compartida no están disponibles.
18.4.2. Disco
Costo aproximado de borrar un búfer que se encuentra en el caché compartido. Esto implica bloquear el grupo de búfer, buscar la tabla hash y escanear el contenido de la página. Por defecto este parámetro es uno. vacío_cost_page_miss (entero)
Costo aproximado de borrar un búfer que debe leerse del disco. Esto implica bloquear el grupo de búfer, buscar la tabla hash, leer el bloque deseado del disco y escanear su contenido. Por defecto este parámetro es 10. vacío_cost_página_sucia (entero)
Costo aproximado de la limpieza que cambia un bloque que no ha sido modificado previamente. Esto incluye el costo de E/S adicional asociado con la escritura del bloque modificado en el disco. Por defecto, este parámetro es 20. Vacuum_cost_limit (entero)
El costo total, tras la acumulación del cual quedará dormido el proceso de limpieza. Por defecto este parámetro es 200.
Nota
Algunas operaciones adquieren bloqueos críticos y, por lo tanto, deben completarse lo más rápido posible. Durante tales operaciones, no hay costos de limpieza retrasados, por lo que el costo acumulado durante este tiempo bien puede exceder el límite establecido. Para evitar retrasos prolongados innecesarios en tales casos, el retraso real se calcula utilizando la fórmula vacío_cost_delay * acumulado_equilibrio / vacío_cost_limit y se limita a un máximo de vacío_cost_delay * 4.
18.4.5. Grabación en segundo plano
Entre los procesos especiales del servidor está el proceso. grabación de fondo, cuya tarea es registrar “ sucio"(nuevos o modificados) buffers compartidos en el disco. Intenta escribir datos desde buffers para que los procesos normales del servidor que procesan solicitudes no tengan que esperar para escribir, o esta espera sea mínima. Sin embargo, el proceso de escritura en segundo plano aumenta la carga general en el subsistema de E/S porque puede escribir una página modificada varias veces en cada cambio, mientras que solo se puede escribir una vez en un punto de control. Las opciones analizadas en esta subsección le permiten personalizar el comportamiento de la grabación en segundo plano para satisfacer sus necesidades específicas.
Establece el número máximo de buffers en los que un proceso de grabación en segundo plano puede escribir durante una ronda de actividad. Si se establece en cero, la grabación en segundo plano se desactiva. (Tenga en cuenta que los puntos de control administrados por un proceso auxiliar independiente no se ven afectados). El valor predeterminado para este parámetro es 100 buffers. Este parámetro solo se puede configurar en postgresql.conf o en la línea de comando al iniciar el servidor. bgwriter_lru_multiplier (punto flotante)
La cantidad de buffers sucios escritos en la siguiente ronda depende de cuántos buffers nuevos el servidor procesó en rondas anteriores. La demanda reciente promedio se multiplica por bgwriter_lru_multiplier y se supone que esta es la cantidad de buffers que se necesitarán en la próxima ronda. El proceso de escritura en segundo plano escribirá en el disco y en los buffers libres hasta que alcance el número de buffers libres. valor objetivo. (En este caso, el número de buffers escritos por ronda está limitado anteriormente por el parámetro bgwriter_lru_maxpages). Por lo tanto, con un multiplicador de 1,0, se escriben exactamente tantos buffers como requiere la suposición ( "exactamente según el plan"). Aumentar este multiplicador proporciona cierta protección contra aumentos repentinos de la demanda, mientras que disminuirlo refleja la intención de dejar algo de volumen de escritura para los procesos del servidor. Por defecto es 2.0. Esta opción solo se puede configurar en el archivo postgresql.conf o en la línea de comando al iniciar el servidor. bgwriter_flush_after (entero)
Cuando el proceso de escritura en segundo plano escribe más de bgwriter_flush_after bytes, el servidor le indica al sistema operativo que escriba estos datos en el almacenamiento subyacente. Esto limita la cantidad de datos sucios en el caché de la página del kernel y reduce la probabilidad de tartamudeo al sincronizar al final de un punto de control o cuando el sistema operativo descarga datos al disco en grandes cantidades en segundo plano. Esto a menudo reduce significativamente la latencia de las transacciones, pero hay situaciones, especialmente cuando la carga de trabajo es mayor pero menor que la caché de páginas del sistema operativo, en las que el rendimiento puede verse afectado. Es posible que esta configuración no funcione en todas las plataformas. Puede variar desde 0 (deshabilita el control de reescritura) hasta 2 MB. El valor predeterminado es 512 kB en Linux y 0 en otros sistemas operativos. (Si BLCKSZ no es de 8 KB, el valor predeterminado y el máximo se ajustan proporcionalmente). Este parámetro solo se puede configurar en postgresql.conf o en la línea de comando cuando se inicia el servidor.
Con valores pequeños de bgwriter_lru_maxpages y bgwriter_lru_multiplier, la actividad de E/S por parte del proceso de escritura en segundo plano se reduce, pero aumenta la probabilidad de que los procesos del servidor deban realizar la escritura directamente, lo que ralentizará la ejecución de las solicitudes. .
18.4.6. Comportamiento asincrónico
Effective_io_concurrency (entero)
Establece el número de operaciones de E/S simultáneas permitidas, lo que le indica a PostgreSQL cuántas operaciones de E/S se pueden realizar simultáneamente. Cuanto mayor sea este número, más operaciones de E/S intentará realizar PostgreSQL en paralelo en una sesión separada. Los valores válidos oscilan entre 1 y 1000, y valor nulo deshabilita las solicitudes de E/S asincrónicas. Actualmente, esta configuración sólo afecta al escaneo de mapas de bits.
Para medios magnéticos, un buen valor inicial para este parámetro es el número discos separados, conformando una matriz RAID 0 o RAID 1 en la que se ubica la base de datos. (Para RAID 5, se debe excluir un disco (como disco de paridad).) Sin embargo, si la base de datos procesa con frecuencia muchas solicitudes en diferentes sesiones y con valores pequeños, es posible que la matriz de discos esté completamente cargada. Si continúa aumentando este valor como completamente cargado discos, esto solo conducirá a un aumento en la carga en el procesador. Las unidades SSD y otras formas de almacenamiento en memoria a menudo pueden manejar muchas solicitudes paralelas, por lo que el número óptimo puede ser varios cientos.
La E/S asíncrona depende de la eficiencia de la función posix_fadvise, que falta en algunos sistemas operativos. Si falta, intentar establecer cualquier valor distinto de cero para este parámetro generará un error. En algunos sistemas (como Solaris), esta función está presente pero en realidad no hace nada.
El valor predeterminado es 1 en los sistemas donde esto es compatible y 0 en los demás casos. Este valor se puede anular para tablas en un espacio de tabla específico configurando el parámetro de espacio de tabla del mismo nombre (consulte ALTER TABLESPACE). max_worker_processes (entero)
Establece el número máximo procesos en segundo plano, que se puede ejecutar en el sistema actual. Este parámetro solo se puede configurar al iniciar el servidor. El valor predeterminado es 8.
Para un servidor esclavo, el valor de este parámetro debe ser mayor o igual que el valor en el maestro. De lo contrario, no se permitirán solicitudes en el servidor esclavo. max_parallel_workers_per_gather (entero)
Establece el número máximo de procesos de trabajo que puede iniciar un único nodo Gather. Los procesos de trabajo paralelos se toman del grupo de procesos controlado por el parámetro. Tenga en cuenta que es posible que la cantidad solicitada de procesos de trabajo no esté disponible en tiempo de ejecución. En este caso, el plan se ejecutará con menos procesos, lo que puede resultar ineficiente. Un valor de 0 (predeterminado) desactiva ejecución paralela solicitudes.
Tenga en cuenta que las consultas paralelas pueden consumir muchos más recursos que las no paralelas, ya que cada proceso de trabajo es un proceso independiente y tiene aproximadamente el mismo impacto en el sistema que una sesión de usuario adicional. Esto se debe tener en cuenta al elegir un valor para este parámetro, así como al configurar otras opciones que controlan el uso de recursos, como . Los límites de recursos, como work_mem, se aplican a cada proceso de trabajo individualmente, lo que significa que la carga total en todos los procesos puede ser mucho mayor de lo que normalmente sería el caso con un solo proceso. Por ejemplo, una consulta paralela que utiliza 4 procesos de trabajo puede utilizar 5 veces más tiempo de CPU, memoria, E/S, etc., en comparación con una consulta que no utiliza ningún proceso de trabajo.
Para información adicional Para consultas paralelas, consulte el Capítulo 15. backend_flush_after (entero)
Cuando un proceso de servicio escribe más bytes backend_flush_after, el servidor le indica al sistema operativo que escriba estos datos en el almacenamiento subyacente. Esto limita la cantidad de datos sucios en el caché de la página del kernel y reduce la probabilidad de tartamudeo al sincronizar al final de un punto de control o cuando el sistema operativo descarga datos al disco en grandes cantidades en segundo plano. Esto a menudo reduce significativamente la latencia de las transacciones, pero hay situaciones, especialmente cuando la carga de trabajo es mayor pero menor que la caché de páginas del sistema operativo, en las que el rendimiento puede verse afectado. Es posible que esta configuración no funcione en todas las plataformas. Puede variar desde 0 (deshabilita el control de reescritura) hasta 2 MB. Por defecto tiene un valor de 0, lo que significa que este comportamiento está deshabilitado. (Si BLCKSZ es distinto de 8 KB, el valor máximo se ajusta proporcionalmente). old_snapshot_threshold (entero)
Establece el tiempo mínimo que se puede utilizar una instantánea sin riesgo de recibir el error: la instantánea es demasiado antigua. Este parámetro solo se puede configurar al iniciar el servidor.
Después de este tiempo, se pueden borrar los datos antiguos. Esto evita que los datos contaminen las instantáneas que permanecen activas durante mucho tiempo. Para evitar obtener resultados incorrectos debido a la desinfección de datos que deberían haberse observado en la instantánea, el cliente recibirá un error si la antigüedad de la instantánea excede el límite especificado y se solicita una página de esa instantánea que ha cambiado desde que se creó.
Un valor de -1 (predeterminado) deshabilita este comportamiento. Los valores útiles para un entorno de producción pueden variar desde unas pocas horas hasta unos días. El valor ajustado se redondea al minuto más cercano y valores mínimos(como 0 o 1 min) se permiten solo porque pueden ser útiles para realizar pruebas. Aunque un valor de 60d (60 días) es aceptable, tenga en cuenta que para muchos tipos de carga, la contaminación crítica de la base de datos o el bucle de identificadores de transacciones pueden ocurrir en períodos de tiempo mucho más cortos.
Cuando esta restricción está vigente, el espacio liberado al final de la relación no se puede devolver al sistema operativo porque eliminaría la información necesaria para detectar que la instantánea es demasiado antigua. Todo el espacio asignado a la relación permanecerá asociado a ella hasta que se libere explícitamente (por ejemplo, usando el comando VACUUM FULL).
Establecer esta opción no garantiza que se generará el error indicado en todas las circunstancias posibles. De hecho, si se pueden obtener resultados correctos, por ejemplo, del cursor que materializó el conjunto de resultados, no se generará un error, incluso si las filas subyacentes en la tabla de destino se destruyeron durante la limpieza. Algunas tablas no se pueden borrar de forma segura en un corto período de tiempo, por lo que esta opción no se aplica a ellas. En particular, esto se aplica a directorios del sistema y tablas con índices hash. Para este tipo de tablas, esta opción no reduce la hinchazón, pero tampoco provoca el error de que la imagen es demasiado antigua al escanear.
16 de febrero de 2015
Optimización del rendimiento de PostgreSQL
por administrador
Configuración de configuración
Configurar recursos
buffers_compartidos
La cantidad de memoria compartida entre procesos PostgreSQL que se necesita para realizar operaciones activas. No debe especificar un tamaño demasiado grande, ya que PostgreSQL también utiliza un caché de disco.
Valores:
- Volumen medio de datos y 256-512 MB de memoria disponible: 16-32MB
-
Gran cantidad de datos y 1-4 GB de memoria disponible: 64-256MB
búfer_temperatura
Búfer para objetos temporales, principalmente para tablas temporales.
Puedes configurar el orden 16 megas
max_transacciones_preparadas
Número de transacciones preparadas simultáneamente.
Para el trabajo de 1C, este parámetro no tiene significado; PREPARE TRANSACTION no se utiliza allí.
Se puede dejar por defecto - 5
memoria_trabajo
Memoria especial utilizada para ordenar y almacenar en caché tablas para una sola consulta.
Al configurar este parámetro, debe considerar la cantidad de solicitudes simultáneas que se ejecutan al mismo tiempo.
Con memoria de 1-4Gb se recomienda instalar 32-128MB
mantenimiento_trabajo_mem
Memoria utilizada para operaciones VACUUM, CREATE INDEX, ALTER TABLE y FOREGIN KEY.
Debe establecerse en un valor mayor que work_mem. Los valores que son demasiado grandes darán como resultado el uso de swap.
Con memoria de 1-4Gb se recomienda instalar 128-512MB
profundidad_max_stack
Una pila especial para el servidor, idealmente debería coincidir con el tamaño de pila establecido en el kernel del sistema operativo. Establecerlo en un valor superior al del kernel puede provocar errores.
Se recomienda instalar de 2 a 4 MB.
relaciones_max_fsm
El número máximo de mesas para las que se realizará un seguimiento del espacio libre en el mapa compartido espacio libre. Estos datos son recopilados por VACUUM.
Establezca el parámetro de acuerdo con la cantidad de tablas en su base de datos con un margen. (Aplicable para versiones hasta 8.4)
max_fsm_pages
El número de bloques para los cuales la información sobre espacio libre. La información se almacena en la memoria compartida, cada registro requiere 6 bytes.
El uso de este parámetro le permite evitar el uso de VACUUM FULL para la base; (Aplicable para versiones hasta 8.4)
Este parámetro no debe ser inferior a 16*max_fsm_relations
Este parámetro se establece automáticamente al crear la base de datos usando la utilidad initdb
También puede configurarlo manualmente: como aproximación inicial, puede tomar la mitad del número promedio de registros modificados (ACTUALIZAR o ELIMINAR) entre ejecuciones del comando VACUUM.
Puede estimar este valor (la base de datos debería haber estado funcionando durante algún tiempo) ejecutando:
análisis de vacío completo;
AVISO: el número de espacios de página necesarios (196272) supera max_fsm_pages (153600)
SUGERENCIA: Considere aumentar el parámetro de configuración "max_fsm_pages" a un valor superior a 196272.
max_archivos_por_proceso
La cantidad máxima de archivos que un proceso y sus subprocesos pueden abrir al mismo tiempo.
Reduzca este parámetro si ve el mensaje " Demasiados archivos abiertos".
Escribir registros de transacciones en el disco
commit_delay y commit_siblings
El valor commit_delay se expresa en microsegundos (0 por defecto). El valor commit_siblings se expresa en unidades (5 por defecto).
commit_delay define el retraso entre un registro que ingresa al búfer del registro de transacciones y su descarga al disco. Si, al completar exitosamente una transacción, al menos las transacciones commit_siblings están activas, entonces la escritura se retrasará mientras dure commit_delay. Si se completa otra transacción durante este tiempo, sus cambios se descargarán juntos en el disco mediante una llamada al sistema. Estos parámetros acelerarán el trabajo si se realizan muchas transacciones "pequeñas" en paralelo.
sincronización f
Este parámetro es responsable de vaciar los datos del caché al disco cuando se completan las transacciones.
Si estableces su valor
fsync=apagado
entonces los datos no se escribirán en las unidades de disco inmediatamente después de completar las operaciones. Esto puede mejorar significativamente la velocidad de las operaciones de inserción y actualización, pero existe el riesgo de dañar la base de datos si ocurre una falla (un corte de energía inesperado, una falla del sistema operativo, una falla del subsistema del disco).
Utilice esta función sólo si tiene UPS y software confiables que apagan el sistema cuando las baterías están bajas.
No debe desactivar fsync cuando ejecute PostgreSQL en plataforma Windows, debido a la inestabilidad del sistema.
método_wal_sync
Un método utilizado para forzar la escritura de datos en el disco.
Si fsync=off, entonces esta opción no se utiliza.
Valores posibles:
sincronización_de_datosabierta- escribir datos usando el método open() con el parámetro O_DSYNC
sincronización de datos- llamar al método fdatasync() después de cada confirmación
fsync_writethrough- llamar a fsync() después de cada confirmación, ignorando los procesos paralelos
sincronización f- llamar a fsync() después de cada confirmación
sincronización_abierta- escribir datos usando el método open() con el parámetro O_SYNC
No todos los métodos están disponibles en determinadas plataformas. Por defecto se instala el primero disponible en el sistema.
escrituras de página completa
Establezca este parámetro en desactivado si fsync=off.
De lo contrario
Cuando esta opción está activada, PostgreSQL escribe el contenido de cada página en el registro de transacciones durante la primera modificación de la tabla después de un punto de control. Esto es necesario porque las páginas sólo se pueden escribir parcialmente si el sistema operativo falla durante el proceso. Esto dará como resultado que los datos nuevos se mezclen con los datos antiguos en el disco. Es posible que una entrada del registro de transacciones a nivel de fila no sea suficiente para restaurar completamente los datos después de una falla. full_page_writes garantiza una recuperación correcta, a costa de aumentar los datos escritos en el registro de transacciones (porque el registro de transacciones siempre comienza en un punto de control. La única forma de reducir el volumen de escritura es aumentar el intervalo del punto de control).
wal_buffers
La cantidad de memoria utilizada en MEMORIA COMPARTIDA para mantener registros de transacciones.
Con 1-4 GB de memoria disponible, se recomienda instalar 256-1024 kb
Optimización de consultas
habilitar_nestloop
Especifica el uso del planificador de consultas. En algunos casos, desactivar el programador puede reducir el tiempo de ejecución de solicitudes individuales, incluso de manera significativa. Sin embargo, en la gran mayoría de los casos, el programador puede reducir el tiempo de ejecución de la consulta. No deberías apagarlo, al menos no de forma permanente.
costo_página_aleatoria
Establece la estimación del programador del "costo" de la enumeración de datos no secuenciales. El valor predeterminado es 4.0. Disminuir este valor en relación con seq_page_cost hará que el programador prefiera escanear el índice; por el contrario, aumentará el costo del escaneo del índice; Puede cambiar ambos valores para cambiar la relación de "costo" operaciones de disco entrada/salida, en relación con el “coste” de uso del procesador, que se describe mediante los siguientes parámetros.
En servidores con velocidad matrices de discos tiene sentido reducir la configuración inicial a 3.0, 2.5 o incluso 2.0. Si la parte activa de su base de datos es mucho mayor que el tamaño de la RAM, intente aumentar el valor del parámetro. Puede abordar la selección del valor óptimo desde el lado del rendimiento de la consulta. Si el planificador de consultas prefiere exploraciones secuenciales en lugar de exploraciones de índice con más frecuencia de lo necesario, reduzca el valor. Por el contrario, si el programador elige escanear un índice lento cuando no debería hacerlo, tiene sentido aumentar la configuración. Después de un cambio, pruebe los resultados exhaustivamente en un conjunto de consultas lo más amplio posible. Nunca baje random_page_cost por debajo de 2.0; Si cree que random_page_cost necesita reducirse aún más, en este caso tiene más sentido cambiar la configuración de las estadísticas del programador.
cpu_tuple_cost
Establece la estimación del programador del "costo" de procesar cada fila durante la ejecución de la consulta. El valor predeterminado es 0,01.
cpu_index_tuple_cost
Establece la estimación del programador del "costo" de procesar cada índice durante una operación de exploración de índice. Predeterminado 0,005
costo_operador_cpu
Establece la estimación del programador del costo de ejecutar cada declaración o función durante la ejecución de la consulta. El valor predeterminado es 0,0025.
tamaño_caché_efectivo
Informa datos al planificador de consultas sobre la cantidad de memoria utilizada por el sistema operativo para el almacenamiento en caché de archivos para una sola solicitud.
Este parámetro en el sistema operativo se puede ver en la configuración:
Para Windows: en el Administrador de tareas, pestaña Rendimiento, Memoria física - Caché del sistema.
Para Linux: escriba el comando gratuito, el valor requerido en la columna almacenada en caché (en kB)
Este valor debe dividirse por el número de solicitudes competitivas en un momento dado (número promedio de conexiones a la base de datos + reserva).
objetivo_estadísticas_predeterminado
Establece la profundidad de las estadísticas de las tablas. Los valores más grandes pueden aumentar el tiempo de ejecución del comando ANALIZAR, pero mejorarán la construcción del plan de consulta.
Se recomienda configurarlo en aproximadamente 100.
restricción_exclusión
Habilita o deshabilita el uso por parte del planificador de restricciones CONSTRAINT en tablas al crear consultas.
Se recomienda establecer el valor en activado; sin embargo, si cambia la CONSTRAINT de las tablas, debe actualizar sus estadísticas ejecutando ANALYZE; de lo contrario, se crearán planes de consulta incorrectos.
Recopilación de estadísticas
stats_command_string
Si se debe transmitir información sobre el comando que se está ejecutando actualmente y la hora de inicio de su ejecución al recopilador de estadísticas.
Atacar
estadísticas_start_collector
Si se debe habilitar la recopilación de estadísticas.
Atacar
estadísticas_row_level, estadísticas_block_level
Ya sea para recopilar información de actividad en los niveles de registro y bloque, respectivamente.
Instalar
stats_row_level=activado
stats_block_level=apagado
stats_reset_on_server_start
¿Se deben restablecer las estadísticas cuando se reinicia el servidor?
Activar
autoaspiración
VACÍO - recolección de basura. VACUUM restaura el espacio ocupado por datos "muertos". Al realizar operaciones de datos normales, PostgreSQL no elimina físicamente datos de las tablas, esto sucede con la operación VACUUM.
autovacío
Ya sea para encender el autovacuum (inicio automático VACUUM),
atacar
autovacuum_naptime
Pausa entre inicios de Autovacuum.
Depende de la frecuencia con la que se actualicen los datos de sus tablas. Puede ser de unos 5 minutos, por defecto 1 minuto.
autovacuum_analyze_threshold
Define el número mínimo de inserciones, actualizaciones o eliminaciones necesarias para activar ANALYZE en cualquier tabla. Esta configuración se puede cambiar para mesas separadas cambiando la configuración de almacenamiento.
autovacuum_vacuum_threshold
Define el número mínimo de inserciones, actualizaciones o eliminaciones necesarias para activar VACUUM en cualquier tabla. Esta configuración se puede cambiar por tabla cambiando la configuración de almacenamiento.
Cabellos
max_locks_per_transaction
Número de bloqueos por transacción:
fijado en aproximadamente 250
punto muerto_tiempo de espera
Vida útil del punto muerto.
Configúrelo en aproximadamente 2 segundos.
Posible error
Después de arreglar el archivo de configuración, es posible que PostgreSQL no se inicie, dando el error:
FATAL: no pudo crear segmento de memoria compartida:...
La llamada al sistema fallida fue shmget (clave = 5432001, tamaño = 140075008, 03600).
Este error generalmente significa que la solicitud de PostgreSQL de un segmento de memoria compartida excedió el parámetro SHMMAX de su kernel. Puede reducir el tamaño de la solicitud o reconfigurar el kernel con SHMMAX más grande. Para reducir el tamaño de la solicitud (actualmente 140075008 bytes), reduzca el parámetro share_buffers de PostgreSQL (actualmente 16384) y/o su parámetro max_connections (actualmente 10).
Si el tamaño de la solicitud ya es pequeño, es posible que sea menor que el parámetro SHMMIN de su kernel, en cuyo caso es necesario aumentar el tamaño de la solicitud o reconfigurar SHMMIN.
La documentación de PostgreSQL contiene más información sobre la configuración de la memoria compartida.
Para solucionarlo, debe aumentar el parámetro SHMMAX en el sistema. Puede hacer esto de la siguiente manera (para el sistema operativo Linux):
Ejecute el comando:
eco 150829120 > /proc/sys/kernel/shmmax
especificando su nuevo valor para el parámetro (que se puede encontrar en el registro de errores de PostgreSQL). Esta operación establece el parámetro sobre la marcha, pero después de reiniciar el sistema los cambios se perderán. Para evitar que esto suceda, agregue la siguiente línea al archivo /etc/sysctl.conf:
núcleo.shmmax = 150829120
indicando su significado.
Ejemplo de configuración para un servidor con 2G RAM
Ajuste medio
Configuración estática media para un máximo rendimiento. Quizás otras configuraciones sean más adecuadas para un caso específico. Lea atentamente esta guía y configure PostgreSQL en función de esta información.
RAM - tamaño de la memoria
* Shared_buffers = 1/8 de RAM o más (pero no más de 1/4);
* work_mem en 1/20 de RAM;
* mantenimiento_work_mem en 1/4;
* max_fsm_relations al número planificado de tablas en las bases de datos * 1,5;
* max_fsm_pages en max_fsm_relations * 2000;
* fsync = verdadero;
* wal_sync_method = fdatasync;
*commit_delay = 10 a 100;
*commit_siblings = 5 a 10;
* Effective_cache_size = 0,9 del valor almacenado en caché, que muestra gratis;
* random_page_cost = 2 para CPU rápida, 4 para CPU lenta;
* cpu_tuple_cost = 0,001 para CPU rápida, 0,01 para CPU lenta;
* cpu_index_tuple_cost = 0,0005 para CPU rápida, 0,005 para CPU lenta;
*autovacío=encendido
* autovacuum_vacuum_threshold = 1800
* autovacuum_analyze_threshold = 900
mantenimiento de bases
Cuando inicia la base de datos por primera vez, después de completar los datos, debe realizar un ANÁLISIS para toda la base de datos.
VACUUM se realiza automáticamente, según la configuración del archivo de configuración.
No es necesario realizar VACUUM FULL si el autoaspirador está correctamente configurado.
Discos y sistemas de archivos.
Si su servidor tiene varios discos físicos, puede distribuir los archivos de la base de datos y el registro de transacciones en diferentes discos:
Detenga el servidor.
Mueva los directorios pg_clog y pg_xlog ubicados en el directorio de la base de datos a otro disco.
Crea un enlace simbólico en la ubicación anterior.
Inicie el servidor.
Por el momento, el rendimiento de PostgreSQL junto con el servidor 1C:Enterprise en comparación con el mismo MS SQL deja mucho que desear. Este artículo es una continuación de los intentos de lograr un rendimiento decente en PostgreSQL. Aunque por el momento no he podido lograr un rendimiento comparable al de MS SQL, creo que en un futuro próximo este problema se solucionará.
Parámetros básicos de PostgreSQL.
buffers_compartidos
La cantidad de memoria compartida asignada por PostgreSQL para el almacenamiento en caché de datos está determinada por la cantidad de páginas de búfer compartido de 8 kilobytes cada una. Hay que tener en cuenta que el propio sistema operativo almacena en caché los datos, por lo que no es necesario asignar toda la RAM disponible para el caché. El tamaño de Shared_buffers depende de muchos factores; para empezar, puedes tomar los siguientes valores:
- 8–16MB- Común computadora de escritorio con 512 MB y una pequeña base de datos,
- 80-160 MB– Un pequeño servidor diseñado para servir una base de datos con 1 GB de RAM y una base de datos de aproximadamente 10 GB,
- 400 megas– Un servidor con varios procesadores, con una capacidad de memoria de 8 GB y una base de datos que ocupa más de 100 GB, dando servicio a varios cientos de conexiones activas simultáneamente.
memoria_trabajo
Se asigna una cantidad limitada de memoria para cada solicitud. Este volumen se utiliza para ordenar, fusionar y otras operaciones similares. Si se excede este volumen, el servidor comienza a utilizar archivos temporales en el disco, lo que puede reducir significativamente el rendimiento. Puede estimar el valor requerido para work_mem dividiendo la cantidad de memoria disponible ( memoria fisica menos el volumen ocupado por otros programas y por páginas compartidas (shared_buffers) para el número máximo de conexiones activas utilizadas simultáneamente.
mantenimiento_trabajo_mem
Esta memoria se utiliza para realizar ANALYZE recopilación de estadísticas, VACUUM recolección de basura, CREATE INDEX y operaciones de adición. claves foráneas. El tamaño de la memoria asignada para estas operaciones debe ser comparable al tamaño físico del índice más grande del disco.
tamaño_caché_efectivo
PostgreSQL se basa en el almacenamiento en caché de archivos proporcionado por el sistema operativo para su diseño. Este parámetro corresponde tamaño máximo objeto que puede caber en la memoria caché del sistema. Este valor se utiliza únicamente con fines de estimación. Effective_cache_size se puede establecer en ½ - 2/3 de la cantidad de RAM disponible, si toda ella está asignada a PostgreSQL.
¡ATENCIÓN! Las siguientes opciones puede aumentar significativamente el rendimiento de PostgreSQL. Sin embargo, se recomienda su uso solo si existen UPS confiables y software que apague el sistema cuando las baterías están bajas.
sincronización f
Este parámetro es responsable de vaciar los datos del caché al disco cuando se completan las transacciones. Si desactiva este parámetro, los datos no se escribirán en las unidades de disco inmediatamente después de completar las operaciones. Esto puede mejorar significativamente la velocidad de las operaciones de inserción y actualización, pero existe el riesgo de dañar la base de datos si ocurre una falla (un corte de energía inesperado, una falla del sistema operativo, una falla del subsistema del disco).
El impacto negativo de tener fsync habilitado se puede reducir deshabilitándolo y confiando en la confiabilidad de su hardware. O eligiendo el parámetro correcto wal_sync_method, un método que se utiliza para forzar la escritura de datos en el disco.
Valores posibles:
- sincronización_de_datosabierta– escribir datos usando el método open() con el parámetro O_DSYNC,
- sincronización de datos– llamar al método fdatasync() después de cada confirmación,
- fsync_writethrough– llamar a fsync() después de cada confirmación, ignorando los procesos paralelos,
- sincronización f– llamar a fsync() después de cada confirmación,
- sincronización_abierta– escribir datos usando el método open() con el parámetro O_SYNC.
¡NOTA! No todos los métodos están disponibles en determinadas plataformas. El método que elija depende del sistema operativo en el que se ejecuta PostgreSQL.
PostgreSQL incluye una utilidad pg_test_fsync, con el que podrás determinar el valor óptimo del parámetro wal_sync_method.
Ejecuta una serie de pruebas de disco utilizando varios métodos de sincronización. Esta prueba proporciona estimaciones de rendimiento del sistema de disco que se pueden utilizar para determinar método óptimo sincronización para un sistema operativo determinado.
Decidí ejecutar la prueba anterior en la computadora de mi trabajo, que tiene las siguientes especificaciones:
- UPC: Núcleo Intel i3-3220 a 3,30 GHz x 2
- RAM: 4GB
- Disco duro: Seagate ST3320418AS 320GB
Prueba en Windows:
- SO: Windows 7 último x64
- FS: NTFS
- SGBD: PostgreSQL 9.4.2-1.1C x64
| C:\PROGRA~1\POSTGR~1\9.4.2-1.1C\bin>pg_test_fsync 5 segundos por prueba es el valor predeterminado de Linux) open_datasync 48817.440 operaciones/seg 20 usos/operación fdatasync n/a fsync 79.688 operaciones/seg 12549 usos/operaciónfsync_writethrough 80.072 operaciones/seg 12489 usos/operación open_sync n/a (en el orden de preferencia wal_sync_method, excepto fdatasync es el valor predeterminado de Linux) open_datasync 24713.634 operaciones/seg 40 usos/operación fdatasync n/a fsync 78.690 operaciones/seg 12708 usos/operaciónfsync_writethrough 79.073 operaciones/seg 12646 usos/operación open_sync n/a 1 * 16 kB escritura open_sync n/a 2 * 8 kB escrituras open_sync n/a 4 * 4 kB escrituras open_sync n/a 8 * 2 kB escrituras open_sync n/a 16 * 1kB escrituras open_sync n/a en un descriptor diferente.) escribir, fsync, cerrar 76.493 operaciones/seg 13073 usecs/opescribir, cerrar, fsync 77.676 operaciones/seg 12874 usecs/op 8kB no sincronizado escribe: escribir 1800.319 operaciones/segundo 555 usos/operación |
Según los resultados de la prueba, vemos que para Windows solución óptima utilizará open_datasync.
Prueba en Linux:
- SO: Debian 8.6 Jessie
- Centro: x86_64 Linux 3.16.0-4-amd64
- FS: ext4
- SGBD: PostgreSQL 9.4.2-1.1C amd64
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | /usr/lib/postgresql/9.4/bin# ./pg_test_fsync 5 segundos por prueba O_DIRECT es compatible con esta plataforma para open_datasync y open_sync.Compare los métodos de sincronización de archivos usando una escritura de 8kB:(en el orden de preferencia wal_sync_method, excepto fdatasync es el valor predeterminado de Linux) open_datasync 80.215 operaciones/seg 12467 usos/operaciónfdatasync 80.349 operaciones/seg 12446 usos/operaciónfsync 39.384 operaciones/seg 25391 usos/operación fsync_writethrough n/a open_sync 40.013 operaciones/seg 24992 usos/operaciónCompare métodos de sincronización de archivos usando dos escrituras de 8kB:(en el orden de preferencia wal_sync_method, excepto fdatasync es el valor predeterminado de Linux) open_datasync 40.033 operaciones/seg 24980 usos/operaciónfdatasync 77.264 operaciones/seg 12943 usos/operaciónfsync 36.325 operaciones/seg 27529 usos/operación fsync_writethrough n/a open_sync 19.659 operaciones/seg 50866 usos/operaciónCompare open_sync con diferentes tamaños de escritura:(Esto está diseñado para comparar el costo de escribir 16kBen diferentes tamaños de escritura open_sync.)1 * 16kB escritura open_sync 38.697 operaciones/seg 25842 usos/operación2 * 8kB open_sync escribe 17.356 operaciones/segundo 57616 usos/operación4 * 4kB open_sync escribe 8.996 operaciones/seg. 111156 usos/operación8 * 2kB open_sync escribe 4.552 operaciones/seg. 219686 usos/operación16 * 1kB open_sync escribe 2.218 operaciones/seg. 450930 usos/operaciónPruebe si se respeta fsync en el descriptor de archivo sin escritura:(Si los tiempos son similares, fsync() puede sincronizar datos escritos en un descriptor diferente.) escribir, fsync, cerrar 34.341 operaciones/seg. 29120 usos/operaciónescribir, cerrar, fsync 35.753 operaciones/seg 27970 usecs/op 8kB no sincronizado escribe: escribir 484193.516 ops/seg 2 usecs/op |
Según los resultados de la prueba, vemos que los métodos fdatasync y open_datasync proporcionan la mejor velocidad. También puedes notar que en el mismo hardware linux La velocidad de grabación fue casi la mitad que la de Windows.
Tenga en cuenta que estas pruebas utilizaron un sistema de disco que consta de un disco. Al usar matriz RAID con una gran cantidad de discos, la imagen puede ser diferente.
wal_buffers
La cantidad de memoria utilizada en MEMORIA COMPARTIDA para mantener registros de transacciones. Con 1-4 GB de memoria disponible, se recomienda instalar 256-1024 KB. Este parámetro debe aumentarse en sistemas con una gran cantidad de modificaciones en las tablas de la base de datos.
segmentos_punto_control
Define el número de segmentos (cada uno de 16 MB) del registro de transacciones entre puntos de control. Para bases de datos con muchas transacciones que modifican datos, se recomienda aumentar este parámetro. El criterio para un número suficiente de segmentos es la ausencia de advertencias en el registro de que los puntos de control ocurren con demasiada frecuencia.
escrituras de página completa
Habilitar esta opción garantiza una recuperación correcta, a costa de aumentar la cantidad de datos escritos en el registro de transacciones. Deshabilitar esta opción acelera el rendimiento, pero puede provocar daños en la base de datos en caso de una falla del sistema o un corte de energía.
compromiso_sincrónico
Habilita/deshabilita la escritura sincrónica en archivos de registro después de cada transacción. Habilitar la grabación sincrónica protege contra posible perdida datos. Pero impone una limitación en el ancho de banda del servidor. Puede desactivar la grabación sincrónica si necesita más rendimiento alto por el número de transacciones. Y la posibilidad potencialmente baja de perder una pequeña cantidad de cambios si el sistema falla no es crítica. Para desactivar la grabación sincrónica, desactive este parámetro.
Otra forma de mejorar el rendimiento de PostgreSQL es mover el registro de transacciones (pg_xlog) a otro disco. La asignación de un recurso de disco independiente para el registro de transacciones le permite obtener una ganancia de rendimiento significativa del 10% al 12% para los sistemas OLTP cargados.
En Linux, esto se hace creando un enlace simbólico a la nueva ubicación del directorio del registro de transacciones.
En Windows, puede utilizar la utilidad para estos fines. Unión. Para hacer esto necesitas:
- Detenga PostgreSQL.
- Haga una copia de seguridad de C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog.
- Copie C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog a D:\pg_xlog y elimine C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog .
- Desempaquetar el programa Unión en C:\Program Files\PostgreSQL\X.X.X\data .
- ventana abierta CMD, vaya a C:\Program Files\PostgreSQL\X.X.X\data y ejecute junction -s pg_xlog D:\pg_xlog .
- Establezca permisos para la carpeta D:\pg_xlog para el usuario de postgres.
- Inicie PostgreSQL.
Donde X.X.X es la versión de PostgreSQL utilizada.
Características y limitaciones en 1C:Enterprise al trabajar con PostgreSQL.
Usando el diseño de UNIÓN EXTERNA COMPLETA.
El DBMS PostgreSQL solo admite parcialmente la UNIÓN EXTERNA COMPLETA (ERROR: “La UNIÓN COMPLETA solo se admite con condiciones de unión fusionable”). Para implementar soporte completo para FULL OUTER JOIN cuando se ejecuta 1C:Enterprise 8 con PostgreSQL, una consulta similar se transforma en otra forma con un resultado equivalente; sin embargo, se reduce la eficiencia del uso de la construcción FULL OUTER JOIN.
Optimización del uso de la tabla virtual SliceLast cuando se trabaja con PostgreSQL.
Problema: Al trabajar con Uso de PostgreSQL Las conexiones a la tabla virtual SliceLast pueden causar una degradación significativa del rendimiento. Un error del optimizador puede provocar que se seleccione un plan de ejecución de consultas subóptimo.
Solución: Si la consulta utiliza una conexión a una tabla virtual en el lenguaje de consulta 1C:Enterprise Slice of the Last y la consulta funciona con un rendimiento insatisfactorio, se recomienda realizar la llamada a la tabla virtual en una consulta separada y guardar los resultados en una tabla temporal.
Resolviendo el problema con la congelación de PostgreSQL.
Al realizar algunas operaciones de rutina (cierre de mes, cálculo de costos, etc.), donde se utilizan consultas complejas con una gran cantidad de conexiones de tablas grandes, es posible un aumento significativo en el tiempo de ejecución de la operación. Básicamente, estos problemas están relacionados con el funcionamiento del optimizador de PostgreSQL y la falta de estadísticas actualizadas sobre las tablas que participan en la consulta.
Opciones para resolver el problema:
- Aumente la cantidad de registros vistos al recopilar estadísticas en tablas. Los valores más grandes pueden aumentar el tiempo de ejecución del comando ANALIZAR, pero mejorarán la construcción del plan de consulta:
- Archivo postgresql.conf- default_statistics_target = 1000-10000.
- Deshabilite la capacidad del optimizador para usar NESTED LOOP al seleccionar un plan de ejecución de consultas en la configuración de PostgreSQL:
- Archivo postgresql.conf- enable_nestloop = desactivado.
- efecto negativo Este método puede ralentizar algunas consultas porque utilizarán otros métodos de unión más costosos (HASH JOIN).
- Deshabilite la capacidad del optimizador para cambiar el orden de las combinaciones de tablas en una consulta:
- Archivo postgresql.conf- join_collapse_limit=1.
- Debe utilizar este método si está seguro de que el orden de unión de la tabla en la consulta del problema es correcto.
- Cambiar la configuración del optimizador:
- Archivo postgresql.conf:
- coste_página_seq = 0,1
- coste_página_aleatoria = 0,4
- cpu_operator_cost = 0.00025
- Archivo postgresql.conf:
- Utilizando PostgreSQL versión 9.1.2-1.1.C y superior, que implementa la recopilación de estadísticas independiente de AUTOVACUUM, basada en información sobre cambios en los datos de la tabla. De forma predeterminada, la recopilación de estadísticas está habilitada solo para tablas temporales y, en muchas situaciones, esto es suficiente. Si surgen problemas con la realización de operaciones de rutina, puede habilitar la recopilación de estadísticas para todas las tablas de problemas individuales o para todas ellas cambiando el valor del parámetro de configuración de PostgreSQL (archivo postgresql.conf) online_analyze.table_type = "temporal" en online_analyze.table_type = "todos". mi camarada Vasiliy P. Melnik. Aunque la interfaz está en inglés, es sencilla e intuitiva. Creo que cualquiera puede resolverlo.
