Re: Correcta configuracion para max_worker_processes y max_parallel_workers_per_gather

Horacio, gracias por tus consejos, sin duda alguna los prondre en practica,
ya algunos de ellos estab en practica.

El directorio root es Raid1 or 5 necesito chequear, ahora donde esta
postgres es raid 10 y el filesystem es xfs.

Por supuesto que deseo moverme a postgres 12, solo que todo es a su momento
desgraciadamente hay otras operaciones que debemos hacer antes de
ugradear a postgres 12, pero quiero empezar hacer algunas pruebas para
demostrar que esa migracion es necesaria, fundamentalmente enfocarme en las
mejoras de particionamiento, indexing y vacuum.

Gracias a todos por sus comentarios de nuevo,
Carlos

On Fri, Apr 17, 2020 at 6:31 AM Horacio Miranda <hmiranda(at)gmail(dot)com> wrote:

>
> 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
>
>