La situación tengo una base de datos postgresql 9.2 que se actualiza bastante constantemente todo el tiempo. Por lo tanto, el sistema está vinculado a E / S, y actualmente estoy considerando realizar otra actualización, solo necesito algunas instrucciones sobre dónde comenzar a mejorar.
Aquí hay una imagen de cómo se veía la situación en los últimos 3 meses:
Como puede ver, las operaciones de actualización representan la mayor parte de la utilización del disco. Aquí hay otra imagen de cómo se ve la situación en una ventana de 3 horas más detallada:
Como puede ver, la velocidad máxima de escritura es de alrededor de 20 MB / s
Software
El servidor ejecuta ubuntu 12.04 y postgresql 9.2. El tipo de actualizaciones son pequeñas actualizaciones típicamente en filas individuales identificadas por ID. Por ej UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. He eliminado y optimizado los índices tanto como creo que es posible, y la configuración de los servidores (tanto Linux linux como postgres conf) también está bastante optimizada.
Hardware El hardware es un servidor dedicado con 32 GB de RAM ECC, 4x 600 GB de discos SAS de 15,000 rpm en una matriz RAID 10, controlado por un controlador RAID LSI con BBU y un procesador Intel Xeon E3-1245 Quadcore.
Preguntas
- ¿El rendimiento visto por los gráficos es razonable para un sistema de este calibre (lectura / escritura)?
- ¿Debo centrarme en hacer una actualización de hardware o investigar más a fondo el software (ajustes del kernel, confs, consultas, etc.)?
- Si realiza una actualización de hardware, ¿la cantidad de discos es clave para el rendimiento?
------------------------------ACTUALIZAR------------------- ----------------
Ahora he actualizado mi servidor de base de datos con cuatro SSD Intel 520 en lugar de los viejos discos SAS de 15k. Estoy usando el mismo controlador de banda. Las cosas han mejorado bastante, como puede ver en el siguiente, el rendimiento máximo de E / S ha mejorado entre 6 y 10 veces, ¡y eso es genial!
Sin embargo, esperaba algo más como una mejora de 20 a 50 veces según las respuestas y las capacidades de E / S de los nuevos SSD. Así que aquí va otra pregunta.
Nueva pregunta ¿Hay algo en mi configuración actual que limite el rendimiento de E / S de mi sistema (dónde está el cuello de botella)?
Mis configuraciones:
/etc/postgresql/9.2/main/postgresql.conf
data_directory = '/var/lib/postgresql/9.2/main'
hba_file = '/etc/postgresql/9.2/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.2/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.2-main.pid'
listen_addresses = '192.168.0.4, localhost'
port = 5432
unix_socket_directory = '/var/run/postgresql'
wal_level = hot_standby
synchronous_commit = on
checkpoint_timeout = 10min
archive_mode = on
archive_command = 'rsync -a %p postgres@192.168.0.2:/var/lib/postgresql/9.2/wals/%f </dev/null'
max_wal_senders = 1
wal_keep_segments = 32
hot_standby = on
log_line_prefix = '%t '
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
default_statistics_target = 100
maintenance_work_mem = 1920MB
checkpoint_completion_target = 0.7
effective_cache_size = 22GB
work_mem = 160MB
wal_buffers = 16MB
checkpoint_segments = 32
shared_buffers = 7680MB
max_connections = 400 /etc/sysctl.conf
# sysctl config
#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
# ipv6 settings (no autoconfiguration)
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.accept_ra_defrtr=0
net.ipv6.conf.default.accept_ra_rtr_pref=0
net.ipv6.conf.default.accept_ra_pinfo=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_dad=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_rtr_pref=0
net.ipv6.conf.all.accept_ra_pinfo=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.forwarding=0
# Updated according to postgresql tuning
vm.dirty_ratio = 10
vm.dirty_background_ratio = 1
vm.swappiness = 0
vm.overcommit_memory = 2
kernel.sched_autogroup_enabled = 0
kernel.sched_migration_cost = 50000000/etc/sysctl.d/30-postgresql-shm.conf
# Shared memory settings for PostgreSQL
# Note that if another program uses shared memory as well, you will have to
# coordinate the size settings between the two.
# Maximum size of shared memory segment in bytes
#kernel.shmmax = 33554432
# Maximum total size of shared memory in pages (normally 4096 bytes)
#kernel.shmall = 2097152
kernel.shmmax = 8589934592
kernel.shmall = 17179869184
# Updated according to postgresql tuningSalida de MegaCli64 -LDInfo -LAll -aAll
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 446.125 GB
Sector Size : 512
Is VD emulated : No
Mirror Data : 446.125 GB
State : Optimal
Strip Size : 64 KB
Number Of Drives per span:2
Span Depth : 2
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disk's Default
Encryption Type : None
Is VD Cached: Nosynchronous_commit: 'La confirmación asincrónica es una opción que permite que las transacciones se completen más rápidamente, a costa de que las transacciones más recientes se pierdan si la base de datos se bloquea'.
synchronous_commit = off, después de leer los documentos en postgresql.org/docs/9.2/static/wal-async-commit.html . (3) ¿Cómo se ve su configuración? P.ej. resultados de esta consulta:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');