{"id":1417,"date":"2014-03-19T19:46:14","date_gmt":"2014-03-19T18:46:14","guid":{"rendered":"http:\/\/soci.hu\/blog\/?p=1417"},"modified":"2014-03-19T23:51:18","modified_gmt":"2014-03-19T22:51:18","slug":"sql-server-magas-cpu-hasznalat-nyomozas-es-megoldas","status":"publish","type":"post","link":"https:\/\/soci.hu\/blog\/index.php\/2014\/03\/19\/sql-server-magas-cpu-hasznalat-nyomozas-es-megoldas\/","title":{"rendered":"SQL Server magas CPU haszn\u00e1lat nyomoz\u00e1s \u00e9s megold\u00e1s"},"content":{"rendered":"

Az ut\u00f3bbi hetekben szinte minden nap SQL Servert hegesztek valahol. Le\u00edrom az \u00f6sszes eset tanuls\u00e1g\u00e1t, l\u00e1ssuk a legut\u00f3bbit.
\nAdott egy igen magas forgalm\u00fa SQL Server, 1000 batch\/sec k\u00f6r\u00fcli a terhel\u00e9se. A lek\u00e9rdez\u00e9sek derekasan optimaliz\u00e1lva voltak a megrendel\u0151 \u00e1ltal, m\u00e1sk\u00e9pp nem is b\u00edrta volna produk\u00e1lni a szerver ezt az \u00e1tereszt\u0151 k\u00e9pess\u00e9get (de g\u00e1z ez a sz\u00f3, nem egy intim bet\u00e9tr\u0151l \u00edrok).
\nA lass\u00fa lek\u00e9rdez\u00e9sek list\u00e1j\u00e1ban<\/a> volt egy gyan\u00fasan egyszer\u0171, de rengetegszer megh\u00edvott lek\u00e9rdez\u00e9s. Ez nem volt indokolt, ez\u00e9rt ezt most m\u00e1r csak egyszer h\u00edvj\u00e1k meg a kliensben, azt\u00e1n elt\u00e1rolj\u00e1k az eredm\u00e9ny\u00e9t. Ezt j\u00f3 \u00e9szben tartani, hi\u00e1ba 2 lapolvas\u00e1sos, seekes egy kveri, ha nagyon sokszor h\u00edvj\u00e1k meg, le tudja ez is fogni a szervert.
\nTov\u00e1bb n\u00e9zve l\u00e1tszott, hogy egy olyan trigger belseje vitte el az id\u0151t, amit m\u00e9g \u00e9n javasoltam nekik 1-2 \u00e9ve. :) A trigger feladata elad\u00e1sokn\u00e1l m\u00f3dos\u00edtani a k\u00e9szletet, \u00edgy nem kell szumm\u00e1kkal kisz\u00e1m\u00edtani list\u00e1z\u00e1skor az aktu\u00e1lis k\u00e9szletet. Denormaliz\u00e1lt adatokat friss\u00edtett. Ezzel azt lehet majd tenni, hogy a forr\u00e1st\u00e1bla nem minden oszlopa m\u00f3dos\u00edtja a k\u00e9szletet, \u00edgy egy IF UPDATE(…)-tel le lehet majd cs\u00f6kkenteni a sz\u00e1m\u00edt\u00e1sok sz\u00e1m\u00e1t.
\nA k\u00f6vetkez\u0151 pont a recompile-\u00e9s\u00f6n\u00f6k vizsg\u00e1lata volt. A legt\u00f6bb lek\u00e9rdez\u00e9s ad-hoc queryk\u00e9nt ment be, a procedure cache kihaszn\u00e1l\u00e1sa gyenge volt, 60% k\u00f6r\u00fcli. Mivel a hibajelens\u00e9g a nagy CPU terhel\u00e9s volt, gyan\u00fas volt, hogy a sok ford\u00edt\u00e1s-tervgener\u00e1l\u00e1s eszi a procikat (8 mag, 16 logikai proc 90%-on).
\nA lek\u00e9rdez\u00e9seket megvizsg\u00e1lva kider\u00fclt a gyenge cache reuse oka: a batch-ek elej\u00e9re kommentek voltak \u00edrva, amelyek kliensenk\u00e9nt egyediek voltak. \u00cdgy ugyanaz az ad-hoc query sok sz\u00e1zf\u00e9le verzi\u00f3ban is bement a szerverre, ami \u00edgy nem tudta hat\u00e9konyan cachelni.
\nA kommenteket kiv\u00e9ve a plan reuse felment 90% f\u00f6l\u00e9. :)
\nA harmadik dolog m\u00e9g egy update statistics with fullscan volt. A statisztik\u00e1k rendk\u00edv\u00fcl fontosak az SQL Server m\u0171k\u00f6d\u00e9s\u00e9hez, aki nem hallott m\u00e9g r\u00f3la olvasson ut\u00e1na, meg\u00e9ri. Norm\u00e1l esetben, nagy t\u00e1bl\u00e1kn\u00e1l csak mintav\u00e9telezve friss\u00edti a statisztik\u00e1kat a szerver, \u00e9rthet\u0151 m\u00f3don sp\u00f3rolva az er\u0151forr\u00e1sokkal. Viszont egyenetlen eloszl\u00e1s\u00fa oszlopok eset\u00e9n ez rossz hisztogramokat eredm\u00e9nyezhet, ami miatt rossz tervet fog gener\u00e1lni a szerver. Ezen seg\u00edthet, ha id\u0151nk\u00e9nt futtatunk full scanes update statisticset is. P\u00e9ld\u00e1ul h\u00e9tv\u00e9genk\u00e9nt. Erre van egy nagyszer\u0171 kis sql csomag, hamarosan \u00edrok r\u00f3la.<\/p>\n

Z\u00e1r\u00e1sk\u00e9nt tanuls\u00e1gul, az SQL kommentek messze nem olyan kis \u00e1rtatlan teremt\u00e9sek, mint gondoln\u00e1nk.<\/p>\n

Update: az elfelejtettem le\u00edrni, hogy az eredeti 90%-r\u00f3l lement 50%-ra a procihaszn\u00e1lat.<\/p>\n","protected":false},"excerpt":{"rendered":"

Az ut\u00f3bbi hetekben szinte minden nap SQL Servert hegesztek valahol. Le\u00edrom az \u00f6sszes eset tanuls\u00e1g\u00e1t, l\u00e1ssuk a legut\u00f3bbit. Adott egy igen magas…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,30,21,58,77,78],"tags":[],"class_list":["post-1417","post","type-post","status-publish","format-standard","hentry","category-szakmai-elet","category-sql-server","category-sql-server-2005","category-sql-server-2008","category-sql-server-2008-r2","category-sql-server-2012"],"_links":{"self":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1417","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1417"}],"version-history":[{"count":2,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1417\/revisions"}],"predecessor-version":[{"id":1419,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1417\/revisions\/1419"}],"wp:attachment":[{"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1417"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1417"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soci.hu\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1417"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}