Urgente: Como trata SQL Server los nucleos de los procesadores.
Fran
En la empresa vamos a cambiar los servidores que estan destinados a llevar
la base de datos sobre la que trabaja el programa principal de la empresa.
Este programa no controla nada el tema del procesamiento y delega en como lo
haga la base de datos. Nosotros tenemos puesto un SQL Server 2000 Enterprise
sobre Windows 2000 Advanced Server y vamos a comprar nuevas máquinas donde
instalaremos el W2003 y SQL Server 2000 (ya que con el 2005 no funciona el
programa). El tema es que tenemos propuesta de las mismas máquinas Dual Core
a 3,0 Ghz o Quad-Core a 1,86 Ghz. Mi pregunta es saber si Sql Server 2000
aprovecha los cores y en que medida, no vaya a ser que compresmos los
quad-cores pensando que es mejor elección y sin embargo no los aproveche y
hubiera sido mejor una maquina con menos cores pero más rápidos.
Agradezco de antemano las respuestas.
Maxi
tal, no hace diferencia si es core o socket separados, el ve procesadores y
si le decis que los use los usara y como :)
Un detalle importante, el licenciamiento por procesador de SQL es por
socket, con lo cual podes tener un dual-core o el Quad y pagaras por cada
socket y no por cada nucleo :)
--
Saludos
------------------------------------------------------
[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
http://maxiaccotto.blogspot.com/
--------------------------------------------------
"Fran" <Fr...@discussions.microsoft.com> wrote in message
news:0DABA84F-8972-4AA4...@microsoft.com...
Fran
de 2 socket y puedo elegir entre que cada socket albergue 2 cores a 3 Ghz o 4
cores a 1,86Ghz, y pensando que solamente va a haber un único programa en
ejecución que es SQL-Server con una única BBDD, crees que es mejor 2 cores
más rápidos por socket o 4 más lentos?. Siempre pensando que estamos hablando
de SQL Server 2000 Enterprise y W2003 Server.
El objetivo es que ese SQL Server vaya lo más rápido posible, ya que tenemos
problemas de rendimiento en la BBDD y se trata de optimizar en lo máximo
posible el SQL independiente del resto de aplicaciones.
Un saludo y gracias de antemano.
Carlos Sacristán
va a agradecer más que le añadas más memoria a mejores procesadores. Ojo,
que no estoy diciendo que no intentes optimizar esto, sino que probablemente
no obtengas la ganancia que esperas.
Dices que actualmente tienes problemas de rendimiento, pero no dices a
qué es debido. ¿Estás seguro que es porque se os ha(n) quedado pequeño(s)
el(los) procesadore(s) que tenéis actualmente?
--
--
--
--
Un saludo
--
--
----------------------------------------------
"Sólo sé que no sé nada. " (Sócrates)
"Fran" <Fr...@discussions.microsoft.com> escribió en el mensaje
news:A88799F7-57BF-44E3...@microsoft.com...
Alejandro Mesa
Comparto tu criterio. Es como tratar de cambiarle el motor a mi carro, sin
ni siquiera saber que la baja velocidad a la que estoy manejando se debe a
una goma ponchada. Claro que es mas facil agarrar unos miles de $ y empezar a
cambiar cuanto se pueda, pero el costo beneficio no sera el mejor.
La mayoria de las veces, los problemas con SQL Server se deben a un sistema
de I/O pobre, mal uso (o ninguno) de indices y no seguir los estandares
cuando se escribe el codigo que servira como interface de la db.
Fran, te recomiendo que espongas un poco mas sobre el sistema actual que
tienes.
- Detalle del equipo actual
- Versiones de OS y SQL Server
- Sistema de I/O (discos) que usas
- Como tienes repartida las bases de sistema, tempdb, db de usuario y su log
de transacciones
- Cual es la orientacion de tu db (OLTP o DATA WAREHOUSE)
- Cual es la estructura de tus tablas incluyendo restricciones e indices
- Que tipo de problemas estas teniendo y si has podido localizar los objetos
involucrados
Saludos,
Alejandro Mesa
Fran
es nuestro. Esta comprado a una empresa y el tema de como este programado y
si tiene o no indices creados, debemos remitirnos a ellos y no podemos hacer
nosotros ningún tipo de pruebas. Por otro lado para dar más datos comentar
que la BBDD esta alojada en un servidor con 2 procesadores Xeon con 2 GB
conectados a una SAN mediante Fibra Optica a 2Ghz (por lo que descarto la
I/O) que estan en RAID 0+1 (4 discos). Actualmente todo funciona con W2k
Enterprise Server y SQL Server 2000. La BBDD tiene algo más de 11Ghz con un
log de 100MB y crecimiento automático en ambos del 10%. El equipo esta
destinado a llevar el software en producción del programa de gestión global
de la empresa (una sola base de datos) al cual se conectan unos 400 usuarios
de manera concurrente a traves de 6 servidores de terminal server que hacen
de front-end, pero no se hacen muchas operaciones sobre la bbdd ya que pueden
hacerse unas 1000 ventas diarias (evidentemente generando sus pedidos,
albaranes..., pero que no es un call-center). Los problemas los encontramos
principalmente cuando se sacan listados de la bbdd que hace que el
rendimiento general caiga en picado y los tiempos de respuesta sean
inaceptables. La máquina tiene 3 años y ya es hora de un cambio generacional,
pero puestos al cambio y dado que en el tema software dependemos de terceros
queremos poner la máquina más optima del mercado, de ahi la duda de los cores
en SQL Server 2000 (ya que el programa no funciona en 2005 ni tampoco esta
preparado para 64 bits, es de 32). La máquina que nos hemos planteado es la
HP DL380 G5 con 4Gb, con la misma conexión a la SAN, 4 Mb de Cache por
procesador, y aquí es lo importante, o ponemos 2 procesadores Dual-Core a
3Ghz o 2 procesadores Quad-Core a 1,86Ghz. Sabiendo que solo se ejecuta en
esa máquina el SQL-Server ¿Cual eligiriais?. Si necesitais más datos,
comentármelos. Y si teneis alguna posible mejora para el sistema (sabiendo
que el software es de terceros) agradeceria mucho vuestra ayuda.
Gracias de Antemano.
Francisco García.
Carlos Sacristán
máquina que tienes ni la que vas a comprar puedan tener problemas en este
aspecto.
De todos modos comentas que la bajada de rendimiento del sistema es
cuando se solicitan informes pero... ¿de cualquier tipo? Es decir, ¿con
informes sencillos también ocurre o sólo con algunos más potentes?
En cualquier caso, aunque el software dependa de terceros no significa
que éstos terceros se tengan que desentender del tema. Vosotros habréis
pagado un coste de licencias para que la aplicación funcione de un modo
aceptable bajo unos requisitos de hardware que (seguro de sobra) cumplís,
así que yo lo que haría sería comentarles a los que os han vendido la
aplicación la problemática que tenéis y que sugieran mejoras
--
--
--
--
Un saludo
--
--
----------------------------------------------
"Sólo sé que no sé nada. " (Sócrates)
"Fran" <Fr...@discussions.microsoft.com> escribió en el mensaje
news:BC55E2B4-2178-4057...@microsoft.com...
Alejandro Mesa
Vamos a hilar fino aqui, como sabe decir Carlos.
- 2 Xeon ? GHz
- 2 GBytes de RAM? - La ram es barata y a SQL Server siempre le vendra bien
asi que trata de poner mas RAM a ese servidor. Tienes W2k Enterprise y eso
es lo que pudiera limitar el uso de memoria por parte de SQL Server, puesto
que W2k Enterprise no permite la opcion /3G en el boot.ini y PAE no esta
disponible en esta version. Pudieras optar por instalar 2000 Advanced Server,
2000 Datacenter o Windows Server 2003.
How to configure SQL Server to use more than 2 GB of physical memory
http://support.microsoft.com/kb/274750/
- Una ultima recomendacion seria que setearas un servidor menos potente pero
que te sirva para reportes. Puedes usar replicacion, log shipping, restore,
DTS, etc.
En cuanto a la pregunta que me hicistes. Yo usaria 2 procesadores de 3 GHz,
aunque insisto en que eso no resolvera tus problemas.
AMB
Fran
dudas. Los Xeon son PIII Xeon a 1,4Ghz. El sistema operativo es W2000
Advanced Server y dado que tenemos otra máquina en cluster, hemos deshecho el
cluster para cogerle la memoria y ampliarsela a 4GB. Con todo esto cuando
varios usuarios sacan listados "pesados" (estos se van a 10-15 minutos como
mínimo) el resto de usuarios practicamente no pueden trabajar. Entrar en las
ventas (de donde tambien tiran los listados) se hace eterno dando a veces
errores de time out, y el hacer simples busquedas se hacen eternas.
Evidentemente se ha comentado con la empresa desarrolladora del software, y
van mejorando poco a poco los procesos (me imagino que añadiendo indices y
creando nuevos DTS), pero claro no es un gran ERP donde esten optimizados
todos los procesos, por lo que nuestro esfuerzo de inversión (aparte de
mejora de software, y dado que no podemos actualizar a Sql 2005 por que no va
el programa ni a tecnologias de 64 bits) se va a centrar en mejora de
Hardware, que si bien no es el factor crítico, seguro que mejorara el tema en
cierta medida. De ahi nuestra preocupación por elegir bien el tema de los
procesadores, Dual o Quad Core, ya que la velocidad de los mismos si parece
un factor algo importante.
Un saludo.
Antonio Soto
Entendemos tu situación. Lo que te quieren decir Alejandro y Carlos, y que
comparto 100%, es que no te lleves las manos a la cabeza si después de hacer
esa ampliación de hardware, no notáis prácticamente la diferencia. Si tenéis
problemas de mala programación, bloqueos, etc,... El hardware poco puede
hacer en muchos casos. Como consejo, primero buscaría donde pueden estar los
problemas, para ver si el Hardware podría solucionar algo o no.
Otra cosa, cuidado con SQL Server el "multiprocesamiento". A veces,
normalmente por mala indexación y gestión de bloqueos, SQL decide partir la
ejecución de una consulta y al final pasa más tiempo esperando por esas
ejecuciones paralelas que si se ejecutase en un único procesador. Échale un
vistazo a este enlace
http://blogs.msdn.com/sqltips/archive/2005/09/14/466387.aspx
Saludos
--
Antonio Soto
Solid Quality Learning
http://www.sqlu.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference
"Fran" <Fr...@discussions.microsoft.com> wrote in message
news:107E5E86-37F8-4443...@microsoft.com...
Fran
solución seria mejorar ciertos aspectos del programa (algunas soluciones,
como hacer tablas con datos calculados por la noche o pensar en poner una
máquina para reportes se estan haciendo), pero todo eso depende siempre de
los desarrolladores del software, que por otra parte tienen el programa en
VB6 (que no lo habia comentado, por si puede influir) y al tenerlo instalado
en clientes "pequeños" (20-30 usuarios) claro está, les va relativamente
bien, pero con nosotros que somos 400 hay muchas más posibilidades de
coincidencias en listados y procesos "pesados". Pero nosotros, como
departamento de Informática no podemos más que tratar de solucionar lo que
nos toca. Ya hemos concienciado que la maquina no es el factor clave, pero
evidentemente desde nuestra gerencia se quieren mejoras, y si la máquina
mejora el sistema un 20-40% pues siempre es bien recibida. Ahora bien, de
verdad el Sql Server 2000 aprovecha algo los cores (por que el software no
controla nada y delega en como lo haga la base de datos y el sistema
operativo). Lo digo porque he leido la página que me ha indicado Antonio y
puede ser que incluso vaya a peor (aunque sinceramente no lo creo, solo por
la mejora de velocidad de procesadores, cache y bus frontal el tema debe
necesariamente que mejorar). Viendo estudios, he visto que Intel en sus
benchmark de bases de datos dice que si mejora, pero claro no dice que base
de datos usa para sacar el número de transacciones por segundo.
¿Creeis que Sql Server 2000 aprovechara los dos socket de 4 cores cada uno?.
Un saludo a todos.
Salvador Ramos
el tema de los índices si que podríais hacer una revisión y optimización si
fuese necesario.
--
Un saludo
Salvador Ramos
Murcia - España
------------------------------------------------
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL Server y .NET)
------------------------------------------------
"Fran" <Fr...@discussions.microsoft.com> escribió en el mensaje
news:BC55E2B4-2178-4057...@microsoft.com...
Eladio Rincón
quizás he llegado un poco tarde al hilo, pero por si sirve, ahí voy...
pasar de 2GB a 4GB de RAM se va a agradecer más que decidir entre dual o
quadpro. Antes de realizar la medición haría una auditoría del sistema para
detectar "qué es lo que más le duele al servidor": típicamente: disco,
memoria, procesador, o red.
Desde la distancia es complicado "estimar" el beneficio de dual vs quad,
pero dado el problema que indicas (reportes frente a facturación) y contando
que tenéis SQL Server 2000 Enterprise Edition, apostaría a que tienes más
problemas de IO y memoria que de procesador.
--
Saludos,
Eladio Rincón,
Mentor Solid Quality Learning
SQL Server MVP
------------------------------------------------------------------
Visita mi página web
Artículos, recursos y trucos de SQL Server 2000 y 2005
http://www.siquelnet.com
------------------------------------------------------------------
"Fran" <Fr...@discussions.microsoft.com> wrote in message
news:BC55E2B4-2178-4057...@microsoft.com...
Jose Mariano Alvarez
Es evidente que el cambio de hardware es muy importante y estas mas que
duplicando las tasas de transferencia entre los procesadores y la memoria
(mas alla del aumento de la CPU) Es muy sospechoso que la lentitud se
produzca cuando aparecen los reportes. Esto suele ser un sintoma en el cual
apostaria a que el hardware te va a ayudar a reducir los tiempos pero como ya
tienes buenos discos no tanto como te imaginas, porque es muy probable que
los problemas se deban a locks. Si el problema primario o secundario es el
I/O (por falta de buenos indices, diseño, o consultas mal escritas) tampoco
va a ayudar mucho porque no mejoras los discos.
Como tu base de datos es de 11GB segun indicas lo cual significa que no es
muy grande, sugiero que determines el problema antes de hacer una inversion.
He visto equipos de 8 procesadores y 16Gb de Ram con la CPU al 100% de todos
los procesadores por una simple instruccion select sobre una sola tabla (muy
mal escrita por supuesto).
Respecto a mas o menos nucleos es relativamente irrelevante si ambos tienen
una suma de ciclos de CPU equivalentes y ajustas MAXDOP porque debido al
multitasking cooperativo que tiene y el manejo de threads que hace el SQL no
creo que varie demasiado. Igualmente apostaria por los procesadores con mas
nucleos que son mas modernos y los pipelines son mas eficientes al igual que
suelen tener mayor cache L1 y L2.
Saludos
--
--
Ing. Jose Mariano Alvarez
Mi.Correo.es.j0s...@gmail.c0m.Corregirl0
(Cambia los ceros por O y saca lo que sobra)