Dr.Verpeilung 10 Geschrieben 6. Juli 2010 Melden Teilen Geschrieben 6. Juli 2010 Hallo Zusammen, wir haben ein IBM x3650M2 Server mit zwei Intel Xeon Quad Core CPUs. Darauf wird Windows Server 2003 R2 Enterprise x86 und SQL 2005 Standard ausgeführt. Im Laufe eines Tages werden verschiedene SSIS Pakete ausgeführt die zwischen 3 und 10 Minuten laufen. Während dieser Zeit ist zu beobachten, dass der SQL Server Prozess zu max. 13% ausgelastet ist, was ja implizit bedeutet, dass nur einer von acht Kernen benutzt wird. Im SSMS habe ich schon mit der Ressourcenzuteilung gespielt und von automatisch auf fest zugewiesen geändert. Dabei habe ich 4 Kerne der Prozessoraffinität zugewiesen und die restlichen 4 Kerne der E/A Affinität. Dennoch läuft der sqlservr.exe auf maximal 13% Last. Habt ihr noch eine Idee? Gruß verpeilo Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 6. Juli 2010 Melden Teilen Geschrieben 6. Juli 2010 Hallo 13 % Last sagt ja nur bedingt etwas aus. Das ganze müsste man mal via Perfmon beobachten. Wahrscheinlich braucht er einfach nicht mehr, könnte die einfachste Erklärung sein. Gruß Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 6. Juli 2010 Melden Teilen Geschrieben 6. Juli 2010 Das kann auch stark von den Queries abhängen. Manche Queries lassen sich nicht sinnvoll in Threads aufteilen und laufen dann eben auf einem Core. Ich kenne hier nur DB2 im Detail. Dort ist das ähnlich und Verhalten kann sort über bestimmt Parameter verändert werden. Wobei das nicht in jedem Fall die Performance steigert. Oft auch im Gegenteil... -Zahni Zitieren Link zu diesem Kommentar
Dr.Verpeilung 10 Geschrieben 6. Juli 2010 Autor Melden Teilen Geschrieben 6. Juli 2010 Hallo 13 % Last sagt ja nur bedingt etwas aus. Das ganze müsste man mal via Perfmon beobachten. Wahrscheinlich braucht er einfach nicht mehr, könnte die einfachste Erklärung sein. Gruß Das hatte ich anfangs auch gedacht. Allerdings funktioniert eine Anwendung die die selbe DB nutzt dann nicht mehr und stürzt wg. Time Out ab... Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 6. Juli 2010 Melden Teilen Geschrieben 6. Juli 2010 Das hatte ich anfangs auch gedacht. Allerdings funktioniert eine Anwendung die die selbe DB nutzt dann nicht mehr und stürzt wg. Time Out ab... Dann ist aber die Anwendung schrottig. Perfmon remote von ner Admin-Workstation auch probiert? Zitieren Link zu diesem Kommentar
Dr.Verpeilung 10 Geschrieben 6. Juli 2010 Autor Melden Teilen Geschrieben 6. Juli 2010 Dann ist aber die Anwendung schrottig. Perfmon remote von ner Admin-Workstation auch probiert? Da kann die Anwendung nix für wenn der SQL Server keine Anfragen entgegen nimmt. Wenn ich mich zu dieser Zeit mit dem SSMS verbindet und eine 0815-Abfrage ausführe, kommt auch nix... Die Anwendung nennt sich übrigens SAP... *gg* Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 6. Juli 2010 Melden Teilen Geschrieben 6. Juli 2010 Da kann die Anwendung nix für wenn der SQL Server keine Anfragen entgegen nimmt. Wenn ich mich zu dieser Zeit mit dem SSMS verbindet und eine 0815-Abfrage ausführe, kommt auch nix... Während ein SSIS-Package läuft kannst du keine Abfragen ausführen? Perfmon während nem SSIS-Package sollte doch aber definitiv kein Problem sein. Irgendwas an deiner Maschine ist da im argen... Die Anwendung nennt sich übrigens SAP... *gg* Tja... ich enthalte mich mit meiner persönlichen Meinung zu diesem ERP und behalte mir rein technische Unterstützung vor. Lass doch mal den MS SQL BPA drüber laufen und schau was der zu der Maschine und der Instanzkonfiguration sagt: MCSEBoard.de SQL Blog Blog Archive Der SQL Server 2005 Best Practices Analyzer Zitieren Link zu diesem Kommentar
Dr.Verpeilung 10 Geschrieben 6. Juli 2010 Autor Melden Teilen Geschrieben 6. Juli 2010 Während ein SSIS-Package läuft kannst du keine Abfragen ausführen?Perfmon während nem SSIS-Package sollte doch aber definitiv kein Problem sein. Irgendwas an deiner Maschine ist da im argen... Tja... ich enthalte mich mit meiner persönlichen Meinung zu diesem ERP und behalte mir rein technische Unterstützung vor. Lass doch mal den MS SQL BPA drüber laufen und schau was der zu der Maschine und der Instanzkonfiguration sagt: MCSEBoard.de SQL Blog Blog Archive Der SQL Server 2005 Best Practices Analyzer Perfmon geht natürlich. Welche Leistungsindikatoren brauchst du denn? Zitieren Link zu diesem Kommentar
phoenixcp 10 Geschrieben 6. Juli 2010 Melden Teilen Geschrieben 6. Juli 2010 Hm, seit Beitrag #2 schlage ich dir eine Beobachtung via Perfmon vor und die soll nicht gehen und auf einmal geht sie doch... Nunja, sei es drum. Ich würde mir grade bei einem SQL Server hauptsächlich die Themen Arbeitsspeicher, Arbeitsspeicherauslastung, I/O, I/O Auslastung und die CPU-Kerne in ihrer Auslastung anschauen. Konkrete Bezeichnungen von Leistungsindikatoren hab ich grade nicht zur Hand, da musst du selber mal schauen. Je nachdem wie gut die Abfragen etc. definiert oder optimiert sind, solltest du damit die essentiellen Bottlenecks (mein Tipp: Festplatten-I/O und / oder Arbeitsspeicher) herausfiltern können. Zitieren Link zu diesem Kommentar
Dr.Verpeilung 10 Geschrieben 6. Juli 2010 Autor Melden Teilen Geschrieben 6. Juli 2010 Uuuups, ich fürchte da habe ich mich unglücklich ausgedrückt. Das Statement ist recht simpel. Ein kleines Update von 17 Spalten mit den Werten von 17 Spalten einer anderen Tabelle. UPDATE SAP.toa01 SET feld3 = SAP.toa02.feld5, feld4 = SAP.toa02.feld6, feld5 = SAP.toa02.feld7, feld6 = SAP.toa02.feld8, feld7 = SAP.toa02.feld9, feld8 = SAP.toa02.feld10, feld9 = SAP.toa02.feld11, feld10 = SAP.toa02.feld12, feld11 = SAP.toa02.feld13, feld12 = SAP.toa02.feld14, feld13 = SAP.toa02.feld15, feld14 = SAP.toa02.feld16, feld15 = SAP.toa02.feld17, datum1 = SAP.toa02.datum1, feld16 = SAP.toa02.feld18, feld17 = SAP.toa02.feld19, feld18 = SAP.toa02.feld20, feld2 = SAP.toa02.zahl2 FROM SAP.toa01 INNER JOIN SAP.toa02 ON SAP.toa01.feld20 = SAP.toa02.feld21 AND SAP.toa01.feld21 = SAP.toa02.feld22 Perfmon lasse ich morgen ausführen. Ich kann mir aber nicht vorstellen, dass es am Arbeitsspeicher oder an den Festplatten liegt. Der Server ist lediglich für 3 SAP Modulberater (ich und noch zwei) verfügbar, weil es sich nur um eine Testumgebung handelt. Der Server ist mit 32GB RAM ausgestattet und die Festplatten hängen in zwei IBM Storage Systemen mit Fibre Channel Festplatten auf denen die SAP Datenbank verteilt ist. Für ein Produktivsystem deutlich zu wenig, aber die Maschine dümpelt eigentlich sonst nur vor sich hin. In der Tabelle TOA01 sind 1,5 Mio Zeilen. In der TOA02 um die 900.000. Zitieren Link zu diesem Kommentar
Dr.Verpeilung 10 Geschrieben 9. Juli 2010 Autor Melden Teilen Geschrieben 9. Juli 2010 Sry wegen der späten Rückmeldung. Hier die Perfmon Daten Seiten/s ==> 2,124 (Durchschnitt) Wartschlangenlänge ==> 2,367 (Durchschnitt) Prozessorzeit (über alle Kerne) ==> 30% (Durchschnitt) Prozessorzeit nur SQL-Server ==> 13% (Durchschnitt) Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 9. Juli 2010 Melden Teilen Geschrieben 9. Juli 2010 Moin, wie lange braucht den das Update-Statement wenn Du es allein laufen lässt ? Kannst Du das o.g. Problem auf dieses Update-Statement eingrenzen, bzw. bleibt dieses Update beim ausführen schon "hängen" ? (Stichwort: Ausführungsplan, Indizes) Gruß Kai Zitieren Link zu diesem Kommentar
Dr.Verpeilung 10 Geschrieben 12. Juli 2010 Autor Melden Teilen Geschrieben 12. Juli 2010 Das Problem lässt sich auf dieses Statement eingrenzen. Normalerweise dauert es 2-3 Minuten. Es gibt aber auch Tage, an denen es über 8 Stunden dauert... Nach dieser Zeit ist es dann aber auch korrekt ausgeführt. Zitieren Link zu diesem Kommentar
Dr.Verpeilung 10 Geschrieben 15. Juli 2010 Autor Melden Teilen Geschrieben 15. Juli 2010 Sonst keiner eine Idee? Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 15. Juli 2010 Melden Teilen Geschrieben 15. Juli 2010 Läufen während des Statements noch andere Anwendungen/Verbindeungen auf dieser Tabelle ? Möglicherweise treten dead locks auf. Du Könntest einen lock timeout definieren: SET LOCK_TIMEOUT (Transact-SQL) Das löst das Lock-Problem zwar nicht, produziert dann aber nachvollziehbare Fehler. -Zahni Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.