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 <hmira...@gmail.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 > >
