4
Nutzung mehrerer Kerne durch SQL Server
Hallo,
bei uns läuft eine SQL Server Express Edition auf einer Quad Core Windows Server 2003 Maschine.
Mittlerweile sind manche SQL Queries doch recht umfangreich geworden und wenn ein User eben diese umfangreichen Queries anstößt, dann rödelt eine CPU auf 100% Anschlag für 10 bis 15 Sekunden.
Die Express Edition kann ja auch nur einen Kern nutzen. Meine Frage ist jetzt, was wäre wenn ich z.B. die Standard Version, die ja mehrere Kerne unterstützt, installiere?
Wird dann die Anfrage eines Users auf mehrer Cores verteilt und dadurch eine höhere Perfomance erzielt? Das wäre natürlich super!
Oder ist es einfach nur so, dass die Anfrage trotzdem nur von einer CPU bearbeitet wird, aber wenn gleichzeitig ein anderer User eine Anfrage startet, sich diese zweite Anfrage dann eben auf eine 2. CPU verteilen kann?
Hoffe das ist so verständlich.....
Viele Grüße
Easyrider
bei uns läuft eine SQL Server Express Edition auf einer Quad Core Windows Server 2003 Maschine.
Mittlerweile sind manche SQL Queries doch recht umfangreich geworden und wenn ein User eben diese umfangreichen Queries anstößt, dann rödelt eine CPU auf 100% Anschlag für 10 bis 15 Sekunden.
Die Express Edition kann ja auch nur einen Kern nutzen. Meine Frage ist jetzt, was wäre wenn ich z.B. die Standard Version, die ja mehrere Kerne unterstützt, installiere?
Wird dann die Anfrage eines Users auf mehrer Cores verteilt und dadurch eine höhere Perfomance erzielt? Das wäre natürlich super!
Oder ist es einfach nur so, dass die Anfrage trotzdem nur von einer CPU bearbeitet wird, aber wenn gleichzeitig ein anderer User eine Anfrage startet, sich diese zweite Anfrage dann eben auf eine 2. CPU verteilen kann?
Hoffe das ist so verständlich.....
Viele Grüße
Easyrider
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93159
Url: https://administrator.de/contentid/93159
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
ja, ab Standard macht der SQL-Server solche Lastverteilung ( Stichwort "Parallel Query Processing) http://msdn.microsoft.com/en-us/library/ms188611.aspx ), allerdings merkt man es bei üblichen Anfragen / Anwendungen nicht sonderlich, so daß man unterm Strich pro User üblicherweise keine spürbare Beschleuning bekommt, bei mehreren gleichzeitigen Anfragen von verschiedenen Usern natürlich schon.
Ob es bei dir was bringt würde erst ein Test mit Sicherheit zeigen.
ja, ab Standard macht der SQL-Server solche Lastverteilung ( Stichwort "Parallel Query Processing) http://msdn.microsoft.com/en-us/library/ms188611.aspx ), allerdings merkt man es bei üblichen Anfragen / Anwendungen nicht sonderlich, so daß man unterm Strich pro User üblicherweise keine spürbare Beschleuning bekommt, bei mehreren gleichzeitigen Anfragen von verschiedenen Usern natürlich schon.
Ob es bei dir was bringt würde erst ein Test mit Sicherheit zeigen.
Moin moin
Soweit ich mich erinnere (kann das leider zur Zeit nicht Prüfen) kann man
1. einstellen wie viele CPUs der SQL Server nutzen darf (wenn man keine Proz. Liz. hat sondern CALs).
2. Ob alle bzw. wie viele CPUs pro Userabfrage verwendet werden können.
Gruß L.
Soweit ich mich erinnere (kann das leider zur Zeit nicht Prüfen) kann man
1. einstellen wie viele CPUs der SQL Server nutzen darf (wenn man keine Proz. Liz. hat sondern CALs).
2. Ob alle bzw. wie viele CPUs pro Userabfrage verwendet werden können.
Gruß L.
Moin easyrider,
Unabhängig davon, dass es natürlich auf 4 Kernen merklich schneller geht und wahrscheinlich auf 20 Kerne verteilt kaum noch Zeit zum Kaffee-Aufsetzen bleiben wird...
... wenn ihr Querys mit derartigen Antwortzeiten habt, dann habt ihr IMHO
---> Es spricht zwar nichts dagegen, ein flotteres Blech drunterzulegen.
Kann ja Performanceverbesserungen von bis zu 32,8% bringen, also "rechnet sich".
Aber mal einen zweitägigen Anlauf zu unternehmen, mal in Explains und Logs und erweiterten Protokolloptionen und Serverstatistiken nach Auffälligkeiten zu suchen bringt in der Regel ganz andere Dimensionen.
Grüße
Biber
Mittlerweile sind manche SQL Queries doch recht umfangreich geworden und wenn ein User eben diese umfangreichen Queries anstößt, dann rödelt eine CPU auf 100% Anschlag für 10 bis 15 Sekunden.
Unabhängig davon, dass es natürlich auf 4 Kernen merklich schneller geht und wahrscheinlich auf 20 Kerne verteilt kaum noch Zeit zum Kaffee-Aufsetzen bleiben wird...
... wenn ihr Querys mit derartigen Antwortzeiten habt, dann habt ihr IMHO
- massive DB-Design-Probleme
- keinerlei Verständnis für die Notwendigkeit von "normaler" DBA-Tätigkeit, die immer auch SQL-Optimierung und Performance-Tuning einschliesst
- wahrscheinlich einen Haufen dynamisches auf der Benutzer-Eingabemaske per Maus zusammengeklicktes Zeug, das als 3x8-Meter-ResultSet übers Netz zum Client geschickt wird und keine einzige Stored Procedure auf dem Server
- und möglicherweise ist die holde Gattin Eures DBAs die Geschäftsführerin des lokalen QuadCore-Lädchens
---> Es spricht zwar nichts dagegen, ein flotteres Blech drunterzulegen.
Kann ja Performanceverbesserungen von bis zu 32,8% bringen, also "rechnet sich".
Aber mal einen zweitägigen Anlauf zu unternehmen, mal in Explains und Logs und erweiterten Protokolloptionen und Serverstatistiken nach Auffälligkeiten zu suchen bringt in der Regel ganz andere Dimensionen.
Grüße
Biber
Moin,
ich kann Biber nur 100% zustimmen. CPU ist bei kleinen SQL-Anwendungen i.d.R. das letzte was gebraucht wird. M.E. nach liegt das Problem eher an nicht vorhandenen/falsch konfigurierten Indizies.
Oder dem Server fehlt RAM, Platten-I/O oder ein anständiger DBA
lg,
Slainte
ich kann Biber nur 100% zustimmen. CPU ist bei kleinen SQL-Anwendungen i.d.R. das letzte was gebraucht wird. M.E. nach liegt das Problem eher an nicht vorhandenen/falsch konfigurierten Indizies.
Oder dem Server fehlt RAM, Platten-I/O oder ein anständiger DBA
lg,
Slainte
