On 17/04/2020 3:10 pm, Carlos T. Groero Carmona wrote:
Hola Lista,
Creando una propuesta de configuration para un nuevo servidor me surge
una duda.
Las especificaciones de este servidor son:
OS: CentOS Linux release 7.7
Arquitectura: x86_64
CPU(s): 144
Thread(s) per core: 2
Core(s) per socket: 18
Socket(s): 4
Postgres: 9.6.15
Normalmente cuando estamos decidiendo los valores para estas
configuraciones usamos:
max_worker_processes = total numero de CPU
max_parallel_workers_per_gather: la mitad del numero de cpu casi
por defecto, asumo que es porque muchos servidores traen por defecto 2
sockets, pero en este caso este servidor tiene 4 sockets, asi que el
valor correcto creo que seria 36.
Leyendo la documentation de postgres, me hace pensar que estoy en lo
cierto, pero como este servidor se utilizara en production, seria un
desastre si estoy equivocado porque estos valores requieren reiniciar
el servidor para ser actualizados, y si a eso le agregamos que debemos
reiniciar tambien cualquier servidor que tengamos en standby pues ni
que decir cierto.
Saludos y de antemano gracias por su ayuda.
Usa esto.
https://pgtune.leopard.in.ua/#/
Ahora si vas a tener una bestia de maquina debes usar, SSD Enterprise
Level, read/write intensive, Lo ideal para datos calientes, io Accelerators.
Con una versión 12 por ejemplo puedes sacar partido a la creación de
indices en parallelo, el modelo revisa si puedes usar tablas particionadas.
el Filesystem algo como XFS.
el S.O separado en un disco logico distinto para la base de datos. ideal
RAID 1+0.
Usa Huge pages,
https://medium.com/@FranckPachot/did-you-forget-to-allocate-huge-pages-on-your-postgresql-server-7a97e7727b03
Asegurate que el cache de la controladora tenga batería ( estas tienen
energia solo por 7 dias en caso de fallas duras ).
Revisa que la controladora tenga el cache más grande que puedas usas.
Da lo mismo el tamaño de la maquina, la capacidada de la RAM y el
performance de las CPU, sí tienes SQL que no tienen indices, eso es
fatal para cualquier base de datos.
Evita tener funciones en los select, ( select algo(now()), bla, ble ,
bli from blo where blu = 'bla' ), al sacar la función algo, veras con
muchos datos que los select son super rápidos, el planificador no puede
hacer bien el trabajo si tienes funciones en los select. ( trata de
evitarlos en la medida que puedas ).
Sí los datos son muy importantes, configura dos discos en SPARE ( creeme
no te vas a arrepentir especialmente sí, por ABC motivos las alertas de
que fallo un disco no te llego, especialmente cuando fallaron 3... ( me
paso en un cliente en el norte de Chile donde el antispam paro las
alertas y cuando revise la maquina, tenia dos discos muertos ).
RAID no reemplaza respaldos. un buen diseño de respaldo y recuperación
es siempre importante.
Tener el RAID de datos de postgresql te puede salvar la vida a la hora
de corrupción del S.O. ( reinstalar y no volver a cargar los datos es
posible cuando tienes un disco lógico asigando al /var/lib/pgsql
No se me ocurre nada más que decirte, suerte y monitorea la maquina,
ideal llenar el comentario del /etc/aliases donde dice marc, pone tu correo.
# Person who should get root's mail
#root: marc
Postgresql 9.6 es Viejo, ya lo dije pero lo vuelvo a decir por si no se
noto, postgresql 12 o el ultimo que este en el mercado es siempre bueno.
Carlos
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
