Ir al contenido


Foto

Consejos y/o sugerencias de configuración en multiprocesadores/núcleos


  • Por favor identifícate para responder
3 respuestas en este tema

#1 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 17 septiembre 2014 - 09:23

Pues eso, como dice el título. ¿Qué consejos podrían darme para una óptima instalación y configuración de Firebird en un equipo de varios procesadores/núcleos?
En teoría la arquitectura de Firebird más apropiada sería la Classic, sabiendo que supuestamente fue diseñada para trabajar de mejor manera en esos entornos.
Para que se hagan una idea, estas son las especificaciones de mi equipo:

Intel® Core TM i7-2670QM CPU @ 2.20Ghz 2.20Ghz
Memoria: 14,0 GB
Procesador x64
Cantidad de procesadores: 8
Discos:
APPLE HDD HTSS47550A9E384 de 465 GB
INTEL SSDSA2CW160G3 de 148 GB
Placa de video: NVIDIA GeForge GTX 560M

Recuerdo haber leído, no se si en la documentación oficial o en otro sitio, que lo mejor es configurar CPUAffinity para que trabaje sobre los procesadores/núcleos pares o bien sobre los impares. Es decir por ejemplo: en {2,4,6}. Pero no estoy seguro si eso fue a modo ejemplo o si efectivamente es más sano u óptimo eso.
Es la primera vez que me enfrento al dilema en equipos de más de 1 procesador por ello acudo a sus sabios consejos antes de embarcarme.

Saludos,
  • 0

#2 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 17 septiembre 2014 - 03:37

Bueno... estuve haciendo algo de ayuda-memoria y empiezo a recordar que la idea de CPUAffinity es la de "ayudar" un poco a la edición SuperServer y sólo aplica en Windows.
Pero me gustaría escuchar experiencias de algunos de ustedes en estos tipos de entornos.

Saludos,
  • 0

#3 Sergio

Sergio

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.092 mensajes
  • LocationMurcia, España

Escrito 18 septiembre 2014 - 01:45

FB classic es bueno para muchos procesadores porque cada conexion usa su propia zona de memoria y su hilo, la pega es que has de calcular la RAM por conexion en la configuracion bien, si tienes 100 conexiones y cada una usa 200MB de cache puedes terminar mal de memoria. Resumiendo, classic bueno si tienes muchas conexiones que necesitan poca cache.

Superserver usa una cache por cada base de datos, no por conexion, asi que hay menos caches y pueden ser mas grandes, eso es bueno para pocas conexiones (40 o 50 es razonable) y si hacen consultas grandes que precisen memoria.

Superserver NO es multiprocesador, usara 1 y medio, y con CPUAffinity puedes decirle que use el 3 porque el 1 y el 2 lo usa windows y esas cosas.

Por cierto, FB 3.0 ya está en alpha 2, con la V3.0 se convierte en multiprocesador sin sacrificar nada, es lo ideal para 4 procesadores o mas, pero eso si, esta en alpha2, yo la he probado y funciona, pero por ejemplo no es 100% compatible atras de momento (no se han preocupado aun mucho de poder abrir una base de datos V2.5 con el servidor 3.0, por lo que la conversion de un fichero ha de hacerse con 2 servidores, uno 2.5 y otro 3.0) vamos, yo me esperaria un poco, pero es una opcion disponible.


  • 0

#4 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 18 septiembre 2014 - 07:49

Gracias Sergio por el repaso.
Yo recordaba mal y pensé que CPUAffinity era tanto en Classic como Superver y eso me confundió las cosas. Se bien que Classic está pensando para un mejor rendimiento en entornos multiprocesadores/núcleos. Y ya que dispongo de un equipo de tales características, pues... creería que es mejor aprovecharlo como debiera. ¡Sino para que tanto Ferrari de equipo!  :|  ;)

Como nunca he usado la alternativa Classic (siempre use SuperServer) ni he tenido la oportunidad de ver en acción lo de multiprocesadores/núcleos es que a lo que más apunto en el hilo es a que otros consejos o cosideraciones debiera de tener en cuenta.
Lo de RAM no creo que sea un problema realmente, tengo 14 GB. Creo que ando bien  *-)  ;) . Y dudo que en donde se instale finalmente la base de datos y el servidor se requiera de tanta concurrencia. Después de todo, deberé dejar esto libre... y que los usuarios finales puedan trabajar con cualquier acquitectura que consideren más oportuna a su caso y configuren el motor a sus necesidades como a la mi aplicación.

Lamentablemente no puedo esperar a la salida de FB 3 ni de animarme a una versión alpha.

Aún así me gustaría contar con sus experiencias.
  • 0




IP.Board spam blocked by CleanTalk.