6
SQL Server 2008R2 native Client Windows7 gegenüber Windows XP massiver Performance verlust
Moin zusammen,
Ich habe hier einen SQL Server 2008 R2 (Standard und Express... beide Versionen probiert) auf einem Server2008R2 laufen(virtuell VMware). Im SQL Server liegen 5 Datenbanken für ein Prozessleitsystem. Alle Datenbanken haben eine größe von unter 200MB...also sprechen wir hier eigentlich eher von einem Karteikasten ;)
Nun gut. Das Prozessleitsystem läuft auf dem Server selbst super Fix. Auswerungen können geöffnet werden, Prozessvariablen können super schnell aufgerufen werden und das System läuft einfach rund und schnell. ( Wir sind die herstellende Firma, daher kenne ich das System bestens )
Jetzt haben wir einen Netzwerk Client, auf diesem ist die Performance % dem lokalen System echt super Miserabel. Ich nenne nur ein Beispiel. Der Kunde öffnet auf dem PLS Server eine Auswertung von 60 Pumpwerken(Füllstand, Stromaufnahme der Pumpen, Laufzeiten der Pumpen) der letzten 24h. Es dauert ca. 40 Sekunden. Auf dem Client im Netzwerk dauert es ca. 3 Minuten.
Nehme ich mir nun einen alten Windows XP Client und installiere den SQL Server 2008R2 native Client, ist die Performance auf dem Client im Netzwerk nahezu identisch. Zwar nicht 100% gleich aber bis auf 5 oder 10 Sekunden passt es.
Jetzt habe ich über meinen Urlaub schon ordentlich Google gequält und nach SQL Server 2008R2 native Client bad Performace oder bad network performance gesucht. Da kommt auch so einiges hoch, wie z.B den Server nicht über Named Pipes anzusprechen sondern über die IP. Alle anderen Protokolle abschalten, Netbios over TCP/IP, IPV6 usw. usw. Das habe ich alles ausprobiert. Des Weiteren kam noch ein Hinweis LLMNR abzuschalten.(auch getan)
Dann bin ich noch auf folgenden Artikel gestoßen:
http://blogs.msdn.com/b/dipanb/archive/2010/06/09/sql-server-query-perf ...
Leider alles ohne Erfolg probiert ;(
Hat jemand schon vor einem ähnlichem Problem gestanden? Bin am Ende ;)
Ich habe hier einen SQL Server 2008 R2 (Standard und Express... beide Versionen probiert) auf einem Server2008R2 laufen(virtuell VMware). Im SQL Server liegen 5 Datenbanken für ein Prozessleitsystem. Alle Datenbanken haben eine größe von unter 200MB...also sprechen wir hier eigentlich eher von einem Karteikasten ;)
Nun gut. Das Prozessleitsystem läuft auf dem Server selbst super Fix. Auswerungen können geöffnet werden, Prozessvariablen können super schnell aufgerufen werden und das System läuft einfach rund und schnell. ( Wir sind die herstellende Firma, daher kenne ich das System bestens )
Jetzt haben wir einen Netzwerk Client, auf diesem ist die Performance % dem lokalen System echt super Miserabel. Ich nenne nur ein Beispiel. Der Kunde öffnet auf dem PLS Server eine Auswertung von 60 Pumpwerken(Füllstand, Stromaufnahme der Pumpen, Laufzeiten der Pumpen) der letzten 24h. Es dauert ca. 40 Sekunden. Auf dem Client im Netzwerk dauert es ca. 3 Minuten.
Nehme ich mir nun einen alten Windows XP Client und installiere den SQL Server 2008R2 native Client, ist die Performance auf dem Client im Netzwerk nahezu identisch. Zwar nicht 100% gleich aber bis auf 5 oder 10 Sekunden passt es.
Jetzt habe ich über meinen Urlaub schon ordentlich Google gequält und nach SQL Server 2008R2 native Client bad Performace oder bad network performance gesucht. Da kommt auch so einiges hoch, wie z.B den Server nicht über Named Pipes anzusprechen sondern über die IP. Alle anderen Protokolle abschalten, Netbios over TCP/IP, IPV6 usw. usw. Das habe ich alles ausprobiert. Des Weiteren kam noch ein Hinweis LLMNR abzuschalten.(auch getan)
Dann bin ich noch auf folgenden Artikel gestoßen:
http://blogs.msdn.com/b/dipanb/archive/2010/06/09/sql-server-query-perf ...
Leider alles ohne Erfolg probiert ;(
Hat jemand schon vor einem ähnlichem Problem gestanden? Bin am Ende ;)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 244660
Url: https://administrator.de/contentid/244660
Printed on: April 23, 2024 at 17:04 o'clock
6 Comments
Latest comment
Win 7 Pro?
Firewall?
AD?
DNS sauber?
Lonesome Walker
Firewall?
AD?
DNS sauber?
Lonesome Walker
Hi,
ja ist Win7 Pro im AD. AD ist sauber und der DNS ist auch sauber. Firewall ist aus. Das Problem tritt nachweislich auf einem 32 bit System mit SQL Server 2008R2 native Client nicht auf. 64 bit Systeme sind sofort extreeeeeme slow.
Arg. Dieses Problem ist in der Tat sehr nerven raubend. Div. suchen ergaben auch Ergebnisse... Mehrere Personen mit gleichen Problemen konnte ich ausfindig machen. Allerdings verlaufen diese Threads irgendwann ohne Ergebnis. Einer hat den Fall sogar bei Microsoft. ;(
ja ist Win7 Pro im AD. AD ist sauber und der DNS ist auch sauber. Firewall ist aus. Das Problem tritt nachweislich auf einem 32 bit System mit SQL Server 2008R2 native Client nicht auf. 64 bit Systeme sind sofort extreeeeeme slow.
Arg. Dieses Problem ist in der Tat sehr nerven raubend. Div. suchen ergaben auch Ergebnisse... Mehrere Personen mit gleichen Problemen konnte ich ausfindig machen. Allerdings verlaufen diese Threads irgendwann ohne Ergebnis. Einer hat den Fall sogar bei Microsoft. ;(
Zitat von @Marco-83:
Das Problem tritt nachweislich auf einem 32
bit System mit SQL Server 2008R2 native Client nicht auf.
64 bit Systeme sind sofort extreeeeeme slow.
Das Problem tritt nachweislich auf einem 32
bit System mit SQL Server 2008R2 native Client nicht auf.
64 bit Systeme sind sofort extreeeeeme slow.
Und was schliessen wir daraus?
Es gibt die ODBC-Settings für 32 und 64 Bit.
Es gibt den native Client für 32 und 64 Bit.
Hast Du DEN HIER installiert? Beide?
Alternativ auf der Gurke mal einen 32Bit DSN anlegen... KLICK
Lonesome Walker
Also die ODBC und auch cliconf habe ich sowohl für 64bit als auch für 32 bit gecheckt. Ebenfalls der native Client ist in beiden Versionen installiert. Bei 64bit Systemen installiert dieser sofort auch die 32bit Treiber mit. Die 32bit Version lässt sich auf 64bit Systemen gar nicht erst installieren.
Dieser Fall wird immer kurioser und ich bin langsam echt am verzeifeln. Kurze erklärung:
Ich starte meinen Server auf dem ESXi, danach verbinde ich mich per RDP auf diesen Server(2008R2). Datenbankabfragen lahmen nun extrem. Melde ich mich über RDP ab und verbinde mich über die echte Konsole, also über den ESXi auf die VM und melde mich am Windows an, rennt es normal ;)))
Weiterer Fall:
Ich habe einen Client im Netzwerk, 64bit Windows7, lokale Anmeldung mit Monitor und Tastatur. -> Es lahmt! Verbinde ich mich nun auf diesen Client von einem anderen Windows7 32bit Rechner im Netzwerk, läuft es fix. Verbinde ich mich von einem anderen 64bitClient im Netzwerk lahmt es.
Hätte ich es nicht selber vor mir, würde ich es als lesender nicht glauben ;)
Grrr
Dieser Fall wird immer kurioser und ich bin langsam echt am verzeifeln. Kurze erklärung:
Ich starte meinen Server auf dem ESXi, danach verbinde ich mich per RDP auf diesen Server(2008R2). Datenbankabfragen lahmen nun extrem. Melde ich mich über RDP ab und verbinde mich über die echte Konsole, also über den ESXi auf die VM und melde mich am Windows an, rennt es normal ;)))
Weiterer Fall:
Ich habe einen Client im Netzwerk, 64bit Windows7, lokale Anmeldung mit Monitor und Tastatur. -> Es lahmt! Verbinde ich mich nun auf diesen Client von einem anderen Windows7 32bit Rechner im Netzwerk, läuft es fix. Verbinde ich mich von einem anderen 64bitClient im Netzwerk lahmt es.
Hätte ich es nicht selber vor mir, würde ich es als lesender nicht glauben ;)
Grrr
Hallo zusammen,
wir haben das Rätsel gelöst.
Der Grafikkartentreiber war schuld! Das Verhalten betrifft tatsächlich sogar mehrere Hersteller, wir konnten das nach Feststellung mehrach mit diversen Herstellern rekonstruieren.
Unglaublich... aber gelöst :DDD
wir haben das Rätsel gelöst.
Der Grafikkartentreiber war schuld! Das Verhalten betrifft tatsächlich sogar mehrere Hersteller, wir konnten das nach Feststellung mehrach mit diversen Herstellern rekonstruieren.
Unglaublich... aber gelöst :DDD
xD tja... Sachen gibts.
Wenn Du den Beitrag noch auf gelöst setzt...
Lonesome Walker
Wenn Du den Beitrag noch auf gelöst setzt...
Lonesome Walker
