Presentation on theme: "Michael Wallace, Principal Systems Consultant, Sybase, Inc"— Presentation transcript:
1Advanced Analysis of Performance Problems with Adaptive Server Enterprise Monitoring Tables Michael Wallace, Principal Systems Consultant, Sybase, IncJeff Tallman, SW Engineer II/Architect, Sybase, Inc.Peter Dorfman, Senior SW Engineer, Sybase, Inc.
2Agenda MDA Table Relationships Setting Up a Monitoring Environment Common mistakes in MDA-based monitoringHow to use related tables to get desired statisticsSetting Up a Monitoring EnvironmentJob Scheduler & MDA RepositoriesWhat to collect & whenProblem Solving using MDA TablesPerformance DiagnosisConfiguration TuningServer Profiling
3THE UNWIRED ENTERPRISE ACHIEVES AN INFORMATION EDGE If at first you don't optimize, you won't succeed
4SYBASE SOLUTIONSHere's where it all begins…now let's make it faster!!!An information edge is created with data becomes usable knowledge at the point of action.It starts with high performance databases where the applications reside. (???)Data services are used to integrate and optimize heterogeneous data resources turning them into virtualized, knowledge-ready information that can now be applied as business intelligence.That information can be then securely extended to the point of action in an always-available state and extended still through on-demand or hosted services.Leveraging a unified application development platform that integrates and enables rapid client/server, Web and mobile application development & reuse.
5Assumptions, Goals, etc. Assumptions: Goals Disclaimer You are already familiar with MDA tables, installation, setup, useGoalsYou will learn how to construct a MDA-based monitoring environment that you can implement at your site – today.You will learn how to spot and diagnose the common performance problemsYou will learn the best practices for using the MDA tables effectivelyDisclaimerWhile the techniques we are discussing are field proven, every performance problem can have unique nuances that points to a different cause
6MDA Monitoring & Diagnostics API C level functions exposed as database RPC’sSignaled by the $ preceeding the rpc nameNo tempdb or data storage requirementsMemory for pipes onlyBut … does rely on a remote connection (OmniServer-<spid>)Nothing unique about the 'loopback' nameBorrowed from tcp localhost nomenclatureYou must change this for HA installsLoopback e.g. loopback_1 and loopback_2You will change it for remote monitoringLoopback real server network name in sysservers
7Common Mistakes in MDA monitoring Excessive PollingE.g. sampling every secondIf more than every minute, you'd better have a real good reasonDrives cpu & network I/O artificially highCollecting Everything for EverybodyInstead of using MDA parameters (especially SPID & KPID)"turn it all on and wait for magic to happen"…it won't!!!Using with sp_sysmonmore on this laterJoining MDA tables (or subqueries)Accuracy problems if self-joins, subqueries – even normal joinsResults in worktables (what is the access method for the join?)Enabling pipe tables too earlyDetermine that you have a bad query before looking for it
8sp_sysmon & MDA Some of the counters are shared with sp_sysmon monTableColumns.Indicator & 2 = 2So don’t run concurrentlyunless sp_sysmon used with noclear option inOtherwise it clears the counters and you have no record from the MDA perspective what the counter values were – just that some idiot (yourself?) cleared the countersReplace periodic runs of sp_sysmon with MDAEasier to parse results anyhowBetter info than ‘5 tablescans’ actually know who did the tablescans and which tables(and that they were all in tempdb, so who cares).Sp_sysmon unique monitorsRepAgent performance metricsOne of the few remaining sp_sysmon unique capabilities
9A Word about Counter Persistence Most counters are “cumulative” and wrap at 2Bnot reset for each sample periodmonTableColumns.Indicator & 1 = 1Sooo….to get rate info, you will need to compare the values “now” with the last sampled “values”Either subtract the current from last ….or plot over time to see trendSome counters are "transient"monProcessStatement – ya gotta be quickRationale:When doing performance monitoring, you need to consider:The counter valueThe rate of change (Δ / time)Monitoring often is "looking back" – not "as it happens"
10A Few Other Caveats Counters & Clock Ticks Guidelines: Counters that measure time are measured in cpu ticksThis can lead to inaccuracies at low volumes – i.e. measuring the amount of ticks short statements or a single I/O takes is about impossible – look at 1,000's/10,000'sChanging the server cpu tick length may help accuracy, but may hurt application performance.It also can be inaccurate when ASE is bumped off of the cpui.e. tempdb devices on UFS will cause a ASE to sleep – it is likely that ASE will get bumped from the cpuGuidelines:Don't worry about the small stuff (i.e. 100ms) – look for the big pain points (they will be visible)
11For Example (monProcessWaits): SPIDWaitsWaitTimeDescription226200wait for buffer read to complete3522500waiting for CTLIB event to complete1waiting on run queue after yield14499400waiting for incoming network data48waiting for network send to completeSPIDWaitsWaitTimeDescription226200wait for buffer read to complete3913100waiting for CTLIB event to complete1waiting on run queue after yieldwaiting on run queue after sleep16523800waiting for incoming network data50waiting for network send to complete* Translations for these and others come later….
12MDA MetaData1 = Cumulative2 = sp_sysmon3 = 1 & 2This table lists which columns you should provide to improve performance of the mda accesses (i.e. eliminates collecting everything) – ala the “where clause”
16Who’s Hogging the System??? “Who to Blame”“CPU…”“I/O…”“Locks…”“tempdb…”“activity…”“Network Bandwidth”
17“Currently Executing Queries” "My Queries Are Slow…"“Currently Executing Queries”“Previous Queries”“CPU Hog"“Waiting"“IO Hog""Long Running"“Currently Executing SQL”“Text Chunk #"
18Statement & SQLText Gotchas & Tips monProcessStatement/monSysStatementLineNumber GotchasNot all exec'd line numbers will appearShould – but don'tBeing researched why notMay be a pipe sizing issue?Line numbers can repeat, skipLoops, if/else, etc.monSysSQLText/monProcessSQLTextText is chunked (ala syscomments)monSysSQLText.SequenceInBatchmonProcessSQLText.SequenceInLinemonSysPlanText.SequenceNumber
19User Object Activity “Index level I/O detail” “Proc/Trigger” Bad/Poor Index choicesTempdb I/O’s“scan counts…”“temp & work tables…”
20Table Statistics“How many pages were read from the base table (IndexID=0,1) – Are we table scanning?”“tempdb object sizes (DBID=2)”“Hot tables/ indexes”“Unused indexes”“Who has the cartesian product in tempdb??? (DBID=2)”“How many index rows were inserted/updated as a result of each DML operation?”“DML statistics”“DML & Proc Exec Count(in some versions)*”“Table/Index Contention”* In some ASE versions, Operations tracked stored proc execs – discontinued in later releases”
22Data & Procedure Cache “Allocated vs. Used by Pool Size” “Cache Misses”“Wash Size”“How many & which procs are cached”“Cache Hogs”“Popular Objects”“Proc Cache Size"(less statement & subquery cache
23Tempdb Analysis (DBID=2) “Join monProcessObject to monProcess to get tempdb sizing for multiple tempdb’s by application/login names”“Size & IO”“Space Hogs”“Logged I/O”“Tempdb Objects”“Tempdb Cache Usage”(can be used to size individual tempdb caches if multiple tempdb's)
24Agenda MDA Table Relationships Setting Up a Monitoring Environment Common mistakes in MDA-based monitoringHow to use related tables to get desired statisticsSetting Up a Monitoring EnvironmentJob Scheduler & MDA RepositoriesWhat to collect & whenProblem Solving using MDA TablesPerformance DiagnosisConfiguration TuningServer Profiling
26MDA Environment Components Monitored ServerHas MDA tables installed locally for adhoc/local monitoringStatic configuration parameters setMDA CollectionCentral Repository (Optional)Mainly used when cross-server analysisASE w/ Job Scheduler to move data from local collectorsLocal (LAN) CollectorLAN-based – not WAN basedConsists of ASE w/ Job SchedulerGood use of ASE 15 – get a jump start by using it hereMDA Repository DBOne MDA Repository per ASE server monitored
27MDA Repositories Why Repositories? Avoids redundant/excessive direct monitoring by all the DBA'sProvides historical data for trend analysisProvides join/subquery supportAvoids impacting the IO, etc. of monitored serverProvides a level of protection for production serversApp developers can query statistics without needing mon_roleOne MDA DB for each server monitoredRationale:MDA tables can vary slightly with each version of the serverAllows easier archive/retrieval for analysisShould be local (LAN) to monitored serverAvoid impact due to prolonged data transfers via CIS
28Local Collector ASE's Add DBA's & App Developer Logins DBA's can have sa_role as normal – plus mon_roleApp Developers may use a single app_dev role or have roles for each individual applicationCreate multiple tempdb'sFairly good size to support analysis driven work tablesBind different logins to different tempdb'sSetup Job SchedulerSee instructions laterTune for CIS/Bulk operationsSee CIS tuning recommendationsCreate each MDA repository DBDetails to follow
29Job Scheduler Install Tips Tricky parts to installation/setupYou have to read the manualAdd the JS server to the collector's sysserverssp_addserver <myJSserver>, ASEnterprise, <servername>Recommend you create a “mon_user” w/ passwordGrant all the roles to the mon_userGrant mon_role, sa_role, js_admin_role, js_user_roleSa_role is not required – local to repository server - If not granted sa_role, you may want to alias mon_user as dbo in all the repository databases to avoid permission hassles.Note that we are discussing the mon_user used by the collector – individual DBA's, app developers, etc. will need their own respective roles/permissionsMap the external loginSp_addexternlogin <myJSserver>, mon_user, mon_user, <password>
30Job Scheduler Scheduling Steps Create individual jobs for each profiling procMake sure timeout is high – i.e. 180 minsCreate repeating scheduleMake sure it starts in future (i.e mins)Schedule jobs before schedule startsAgain, long timeout as appropriateUse sp_sjobcontrol sjob_12, run_now to testStart the jobssp_sjobcontrol null, start_js
32CIS & Database Tuning Tuning CIS to compete with bcp: Database options --exec sp_configure "enable cis", 1 /* on by default */exec sp_configure "cis bulk insert array size", 10000exec sp_configure "cis bulk insert batch size", 10000exec sp_configure "cis cursor rows", 10000exec sp_configure "cis packet size", 2048exec sp_configure "cis rpc handling", 1exec sp_configure "max cis remote connections", 20Database optionsSelect into/bulkcopyTruncate log on checkpointDelayed commit (ASE 15)This will help significantly
33MDA Tables & Performance Most non-pipes will not have significant impactSome that do:Statement/Per Object/SQL Text statistics & pipe (5-12%)SQL Plan & Pipe (22%)Guidance:Leave them off until necessary if you don't have the headroomi.e. if contention starts, enable object statistics to see whereOnly use the SQL/Plan pipes only when necessaryEnable object/statement statistics periodically and collect information for analysis/profiling of the applicationProcedure execution profileTable/Tempdb usage profileWhen using statement statistics, you may need a large pipestatement pipe max messages = 50,000+
34Impact on SQL Language Commands All Disabled(0)834.8Monitoring Enabled Only1.2%824.6Server Wait Events Enabled0.4%831.5Process Wait Events1.1%825.6Object Lock Wait Timing1.4%823.2Deadlock Pipe2.2%816.8Errorlog Pipe2.5%814.1Object Statistics Enabled13.0%726.2Statement Statistics Enabled12.3%732.2Statement Pipe Enabled12.5%730.6SQL Text Pipe Enabled14.3%715.2Plan Text Pipe Enabled21.7%653.610 JDBC 2000 atomic inserts each, committing every 10 using SQL Language Statements
35Impact on Fully Prepared Statements All Disabled(0)2399.8Monitoring Enabled Only0.8%2379.4Server Wait Events Enabled1.4%2366.4Process Wait Events2.2%2346.3Object Lock Wait Timing2.1%2348.6Deadlock Pipe1.0%2376.3Errorlog Pipe1.2%2371.2Object Statistics Enabled4.2%2299.4Statement Statistics Enabled4.0%2302.7Statement Pipe Enabled4.2%2297.9SQL Text Pipe Enabled4.6%2288.3Plan Text Pipe Enabled21.8%1875.610 JDBC 2000 atomic inserts each, committing every 10 using DYNAMIC_PREPARE=true
36Creating MDA Repository DB: MDA proxy tables for monitored serverMake a copy of that server's installmontables – add a use db at the top and then change loopback to the servername in sysserversLocal copies of system tablesUnioned copies of sysobjects (sysindexes optional)Only ID's & Names – but with DBID appendedmaster..sysdatabases, syslogins (suid & name)MDA catalog (monTables, monTableColumns, monTableParameters, monWaitClassInfo, monWaitEventInfo)Repository tablesSame schema as proxy tablesbut with SampleDateTime added to PKeyDon't enforce any FKeysLightly indexed for joins, queriesStored proceduresUnique collection procs for each db due to variations in MDA tablesUnique analysis procs for each db due to different applications
37Monitoring Server Profiling Application Profiling Server resource usage, configuration settingsApplication ProfilingApplication resource usageTable & Index level IO statisticsHot tables, contention, spinlock contention, tempdb usage(On Demand) User MonitoringIO & CPU time statisticsStatement level statisticsQuery plan, SQL text
38Tables to Poll System Application monDeviceIO monIOQueue monErrorLog monStatemonCachePoolmonDataCachemonProcedureCachemonSysWaitsmonEnginemonNetworkIOmonDeadLocksmonOpenObjectActivitymonOpenDatabasesmonSysStatementOptional (pipe table)Aggregated info for stored procedure/trigger analysisLong running procsFrequently exec'd procs
40Detailed Tables for SPID(s) SQL/ExecObject ContentionmonProcessmonProcessActivitymonProcessProceduresmonProcessStatementmonProcessSQLTextmonSysStatementmonSysSQLTextmonProcessWaitsmonProcessObjectmonLocks
41Sample Profiling Jobs & Analysis Server profiling – every 10 minutessp_mda_server_cpu_profilemonSysWaits, monEngine, monStateTop n WaitEvents, cpu usage and when counters were clearedsp_mda_server_io_profilemonDeviceIO, monIOQueue, monNetworkIOIO waits, hot devices, io tuningsp_mda_server_mem_profilemonCachePool, monDataCache, monProcedureCacheCache Usage/Free, Cache Efficiency, Pool Sizing, StallsApplication Profiling – every 30 minutessp_mda_app_obj_profilemonOpenDatabases, monOpenObjectActivityHot tables, contention, tempdb usage, DML executionsmonCachedObject, monCachedProceduresNamed cache effectiveness, cache hogs, proc concurrencymonDeadLocks
42Collector Proc Template -- use a common timestamp for enabling joins; this effectively is-- part of your key and allows you to join tables within the same-- sample period…a common mistake is to use the sample-- time for each table individually-- select all local proxy MDA tables into tempdb to avoid CIS binding-- issues, etc. Note we did not use master..monSysWaits--– we are using the local proxies that point to the monitored serverSelect * into #monSysWaits from monSysWaitsSelect * into #monEngine from monEngine-- insert into repository tables from tempdbInsert into mdaSysWaits (collist)<collist> from #monSysWaitsInsert into mdaEngine (collist)<collist> from #monEngine
43Agenda MDA Table Relationships Setting Up a Monitoring Environment Common mistakes in MDA-based monitoringHow to use related tables to get desired statisticsSetting Up a Monitoring EnvironmentJob Scheduler & MDA RepositoriesWhat to collect & whenProblem Solving using MDA TablesPerformance DiagnosisConfiguration TuningServer Profiling
45Slow Response Times The key is monProcessWaits/monSysWaits This will tell you whether the next step is query related, client software, hardware or contention in ASEIf known SQL query related, you may be able to skip monProcessWaits and go directly to monProcessActivity/ monProcessStatement/monSysStatementMost closely approximates sp_sysmon context switching section…but gives you the details you always lacked…and lets you focus down to the process detail levelUnfortunately, the “WaitEvents” need a bit of decoding as they are in engineer-eeseWait Event classesWait Events
46WaitEvent Classes ID Description Process is running (we wish) 1 Process is running (we wish)1waiting to be scheduled (cpu)2waiting for a disk read to complete (read)3waiting for a disk write to complete (write)4waiting to acquire the log semaphore (log contention)5waiting to take a lock (lock contention)6waiting for memory or a buffer (address contention)7waiting for input from the network (client speed)8waiting to output to the network (client fetch/net sat)9waiting for internal system event (PLC, index balance)10waiting on another thread (contention)
47ASE ProxyDB MDA monProcessWaits WaitEventIDWaitsWaitTimeDescription363098698500wait for mass to stop changing1719847531700waiting for CTLIB event to complete31178274200200wait for buffer write to complete51169434180200waiting for disk write to complete55181921137000259385100waiting until last chance threshold is cleared298068500wait for buffer read to complete526953520054481200214182433600waiting on run queue after yield27219500waiting for lock on PLC15033400waiting for semaphore2506waiting for incoming network data251waiting for network send to completeRed – mass changes due to large io processingOrange – suspect this is waiting data to come in – i.e. waiting for ct_fetch()Yellow – i/o write wait timesBlue – this is an example of the suspends – for this run, it only log suspended 3 times thanks to the log prunerAn alternative explanation would that the top three are all related to incoming data – where 1 & 3 refer to the dirty page writes and #2 refers to the wait time on pending array insertsExample from a platform migration test – remember 36, 51, 55, 52, 54
48What’s a MASS??? Memory Address Space Segment synchronizes access to buffers by waiting until no one else is writing the bufferchunk of contiguous memory containing one or more 2K pages (the quantity being determined by the configured pool size, 2K, 4K, etc).Analogous to “extents”With large IO the state of any page in the MASS is taken to be the state of the MASS itself. This means, for example, if you use 16K IO then access is synchronized across all 8 2K pages - if one is being written to then all are considered to be written to.Large IO writes tempdb select/into, bcp, array inserts, etc. User queries will not reflect large I/O
49MASS Waits…Event IDDescription30wait in bufwrite for mass to finish changing before writing buffer36wait for mass write to complete before setting change flag37wait for mass to finish changing before setting change flag53waiting in writedes for mass to finish changing before writing buffer69wait in DBCC delbuf for mass to finish changing before removing bufferFrom earlier, we were waiting on slow disks (hence 36 – write completion)…memory or logical I/O would have been 30 or 37 (depending)…this also could be a sign of a cartesian or unexpectedly large result in tempdb has saturated the IO
50Disk Write Waits…Event IDDescription50Write was restarted because previous attempt failed – if you see this check sys error log51waiting for last MASS on which i/o was issued52waiting for last MASS on which i/o was issued by some other task53waiting in writedes for mass to finish changing before writing buffer54waiting to write of the last page of the log55waiting after write of the last page of the logFrom earlier, slow disks hit us on the MASS large I/O’s and waiting for the log to flush to slow disks (disks were U160 – not SAN) – yellow – otherwise, it was then 52 & 54 (negligible delays)Remember 51 & 52 (MASS caused delays)
51Those Pesky Semaphores Which ones?Normal table, row, page locks?Transaction log?Device?Answer: It DependsTypically will be logical lock on a row or pageSee what other events are near it that typically drive a semaphoreI.e. if disk writes 54 & 55 – then log semaphore is indicatedCompare sum(LockWaits) from monOpenObjectActivityIf latches are high – likely is exclusive lock on last index page in DOL table for monotonically increasing indicesIf waiting for buffer reads/run queue after sleep are high – answer could be high read activity (semaphore = shared lock)
52Common Wait Events: Client S/W Client Related S/W Issueswaiting for CTLIB event to completenon-data related: i.e. waiting for TDS tokens such as ACK for packets sent, or waiting on next command to be sent (i.e. gap between ct_command() and ct_send())…if CIS is involved, it is waiting on ct_fetch()/result set materialization at remote serverNext move is to look at the client codewaiting for network send to completeThis is data stream related – outbound commands (RPC’s, RepAgent, etc.) will be ‘waiting for CTLIB event to complete’ due to waiting for ct_sendpassthru(), etc. to execute.Next table to check out is monProcessNetIO – probably going to be a change to fetch block size in program and/or packet sizewaiting for incoming network dataEquivalent to ‘awaiting command’ – nothing expected, ..or…Big gap could point to network handling of language cmds time (try ct_dynamic) or BLOB processing
53Common Wait Events: ASE Transaction Log Delays:waiting until last chance threshold is clearedTransaction log keeps filling and crossing the lct – you need to add a threshold to dump earlier, or make the log biggerSomething to watch if tempdb is fillingWaiting for semaphoreWaitEventID = 150Check monOpenDatabases and compare appendLogRequests to appendLogWaitsDisk I/O wait events 54 & 5554 – you are waiting to write to the last log page55 – you are waiting for the last log page you wrote to flushYou don’t commit until page is flushed to disk
54Common Wait Events: Contention Wait to acquire latchAddress locking contention (tran log)DOL index contention (last index page – ASE 15 partition table/local index)Waiting for semaphoreTypically normal row/pg lock, but could be log semaphore or spinlock contentionWait for someone else to finish reading in massMemory access contentionMay show up with Wait Event 52 – "waiting for last MASS on which i/o was issued by some other task"Possible causes:Tempdb in same data cache as primary tablesuser does select/into (bulk I/O)The last mass in use will be appended to with the new logical pages being writtenBut the previous user is still reading the previous pagesMost likely cause – two nearly concurrent select/into's in tempdbSee above progession – think about it – select/into tempdb and then you immediately read outNext task has to wait to access memoryMost Likely Answer: multiple tempdb's
55Common Wait Events: H/W H/W Issues: CPU contentionwaiting on run queue after yieldTask reached timeslice - No I/O wait, so task is cpu-intensivein memory scan, join operations, sorting, looping logic in proc, etc.waiting on run queue after sleepCould also indicate high write activityi.e. BCP, or other write intensive process will sleep while waiting I/O…Remember, log writes also mean SPID sleeps –Slow cpu's could result in higher waits on log semaphore and disk writes 54 & 55Either one could be due to a cpu pignext step is to look at monProcessActivity.CPUtimeIf no obvious cpu hogs, you may need to add cpu's/online additional enginesH/W issues: Device I/O relatedwait for buffer read to completeLogical read or network readwait for buffer write to completeLogical write (update in cache before disk flush)/network sendwaiting for disk write to completeExceeded disk i/o structures and delayed for pending i/o queue???
56Common Wait Events (Config) “waiting while no network read or write is required”Netserver checked and no network read/write pendingServer level – shouldn’t see this in monProcessWaitsCheck "i/o polling process count"If CPU & IO bound – reduce "i/o polling process count"For – look at the following in monEngine: DiskIOChecks, DiskIOPolled, DiskIOCompleted
57Query Performance Step 1: Gather current statement statistics monProcessStatement & monProcessSQLtextMay have to use monSysStatement/monSysSQLtext for previous queriesFind out the cpu & i/o pattern for the queryFind out the SQL text (without being truncated)Proc is also in monProcessStatementStep 2: Get SPID Resource ConsumptionmonProcessActivityGet CPU time, IO (phys, log, reads/writes), locks heldGet Wait TimeGet Tempdb objects (TempDBobjects, WorkTables)Step 3: If High Wait Time – Find causemonProcessWaitsCheck for contention, network issues, I/OStep 4: If High I/O Write waits or Tempdb is suspectmonProcessObject & monOpenObjectActivityTemp table sizes, rows IUD & Reads on tempdb (DBID=2)monProcessObject also tells what indexes a process is using
58Query Performance Step 5: If Contention Check monOpenObjectActivity to find table(s) with most contention (LockWaits)Check monProcess for BlockingCheck monLocks, monDeadLocksStep 6: If Proc (somewhere in proc is slow)Understand: Batch Context Line NumberFor example, if your first batch calls a proc at line 5 (batch=1; context=1; line number=5) , the proc is a new context (2) and each line within the proc now increases.monProcessStatement only gives metrics on current statement within the current batch/context/lineIssue may have been previous statement or loopmonSysStatement – historical view of the query treeCPU, I/O, etc. at various sample points – not every line (should be – but isn't)
60Usage: SP backtraceMy SP has hit an unexpected error condition, how did it get there?The user/application developer can create a SP to be called that prints the executed SQL and the backtrace of SPs to help diagnose the problem - similar to ASE’s ucbacktrace to errorlog.Must be called from within the outer executing proc/triggerPreviously executed statements are in monSysStatementsCREATE PROCEDURE int ASBEGINSELECT SQLTextFROM master..monProcessSQLTextWHERE ANDPRINT “Proc/Trigger Call Stacktrace:"SELECT ContextID, DBName, OwnerName, ObjectName, ObjectTypeFROM master..monProcessProceduresORDER by ContextID descENDThis could be useful to some application developers with complicated stored procedures that have varying calling sequences based on different conditions. If, for example, an unexpected error condition occurs in some SP one can find out where the SP was called from by creating an sp_backtrace SP similar to the above and calling it when the unexpected error occurs.Here is some sample output, after creating nested SPs each calling the next up the chain until sp_backtrace is called at the bottom level.SQLTextexec proc_nest_1(1 row affected)Stacktrace:ContextID DBName OwnerName ObjectName15 testdb cushion sp_backtrace14 testdb cushion proc_nest_1413 testdb cushion proc_nest_1312 testdb cushion proc_nest_1211 testdb cushion proc_nest_1110 testdb cushion proc_nest_109 testdb cushion proc_nest_98 testdb cushion proc_nest_87 testdb cushion proc_nest_76 testdb cushion proc_nest_65 testdb cushion proc_nest_54 testdb cushion proc_nest_43 testdb cushion proc_nest_32 testdb cushion proc_nest_21 testdb cushion proc_nest_1(16 rows affected)(return status = 0)
61Batch SQL Exec TraceTrace the execution path/statements for a SQL BatchYou may need a copy of sysobjects to translate proc/trigger names into EnglishIf SPID/Batch is still running you may have to combine with monProcessStatementYou can use the ContextID to form indenting (pretty print)select ContextID, StartTime=convert(varchar(30),StartTime,109),ProcedureID, LineNumber, datediff(ms,StartTime,EndTime)from monSysStatementwhere and andunion all -- optional part for still executing batchesProcedureID, LineNumber, datediff(ms,StartTime,getdate())from monProcessStatementorder by ContextID, StartTime, ProcedureID, LineNumer
62MDA: Configuration Tuning Cache SizingBuffer Pool Sizes/UtilizationHow much cache is:IndexText/Image chains (Indid=255)Proc CacheMultiple TempDBFor logged I/O operations watch monOpenDatabases.appendLogRequests & appendLogWaits columnBut this is only part of the pictureMonitor monProcessActivity TempDbObjects & WorkTablesULC SizingDisk structure sizingAre pending IO's close to number of disk structures?
63Server Profiling… Focus on the "Waits" Log, Tempdb, data IO, WaitEventsUse MS Excel or OpenOffice to plot Requests vs. WaitsLook at monOpenObjectActivity for explanationThe next few slides are from a real-world customer:Illustrates starting with server profiling to see where problems areDrilling into problems with application profilingCustomer Application ScenarioMessage processing for event trackingExtensive BLOB writes for message dataBLOBs were logged for recoverability (remember this)ObjectID's will be used to protect the customer identity~36 Hours of MDA data collected
64monSysWaits: The Server Picture IDDescriptionWaitsWaitTime250waiting for incoming network data401,805,949101,758,76841wait to acquire latch13,961,6403,131,597179waiting while no network read or write is required766,149,8502,380,910150waiting for semaphore32,458,1662,285,117215waiting on run queue after sleep1,876,974,6622,128,49729wait for buffer read to complete121,549,9641,811,070251waiting for network send to complete422,275,581919,71719xact coord: pause during idle loop9,592575,60752waiting for disk write to complete19,736,242419,969124wait for someone else to finish reading in mass26,507,762298,2715132,364,721296,411
68Tempdb MASS Contention WaitEvents 52 Someone writing MASS51 Waiting MASS write124 Someone reading MASS
69Real World … Tempdb…. monOpenObjectActivity where DBID=2 ObjectIDIndexIDObjectNameWritesPages Written2#rev_items___1,699,686183,6161,462,383wrk_bundle_item251,399NULL24,814194,25622,626177,29122,361175,33922,346175,06522,325175,03022,201174,05921,865171,371…answer was that a single large batch process that was selecting records to purge into a temp table was the primary cause…..
73Real World….App DB Log (Writes)…. ObjectIDIndidWritesInsertsUpdatesDeletesOperLockReqLockWait2559,898,4239,338,257207,998911,675916,7158,056,3369,842,072600156,461857,907845,7017,685,0139,246,818543241,947905,57341,776852,73417,332119,208224,294175,9852,820,0671,58917,050127,100238,605178,5982,337,1631,47617,015127,770239,529179,8212,319,2991,49916,808126,183236,688178,3232,509,6691,42280% of the writes were to BLOB's – given the speed of BLOB writes (STS index node maintenance, write offset location, extent allocation, etc.) – this likely is the cause of log contention.
74Real World….App Contention… DBObjectIDIndidWritesInsertsUpdatesDeletesOperLockReqLock Wait232,6771,081,2751,2823,318,644108,3302066,1781,664,41214,794,01513,049,7257,399696,510487,889523,9045,783,577437,49916,691,7006,1062,346,840837,0752,632,914446,36274,85426,408,6683,6412,512,390626,2672,141,810446,33480,15312,391,7112,714584,1722,595,16419,504,90618,340,9491,7532117,332119,208224,294175,9852,820,0671,58916,455118,664223,334178,3322,815,0781,54516,586121,161228,014179,9452,854,6001,53217,015127,770239,529179,8212,319,2991,499All things considered, not a lot of blocking, except DB 23 – looks like a several batch processes kick in updating ~1,000 rows at a time in parallel and they get serialized – should check to see if DOL, if lock escalation to table due to config at defaults for lock escalation, etc.
75What Did It Mean??? TempDB Contention App Contention BLOB Processing Resulted in heavy inbound network issuesDriving some of the latch contentionSince it was logged, it was driving log semaphore contentionTempDB ContentionMASS contention between concurrent temp tablesLarge batch processApp ContentionNot much, except the one DB (timed batch processes)Overall SynopsisCPU and Network bound more than diskIn fact, it waited longer on net sends than disk writesThis was due mainly to BLOB network processing and logging of BLOB's serializing access
76Suggestions Tempdb Client Upgrade HW to more current cpu's BLOB Data Larger page size + use XNL varchar + compress BLOB datadrop BLOBSTempdbSplit into multiple tempdb'sOne dedicated tempdb for batch process(es)3-4 application tempdbsUse separate named cache for eachReduce the MASS contentionClientUse larger packet size for clientUpgrade HW to more current cpu'sMachines were 7+ years old
77Summary MDA Monitoring Building a Monitoring Repository Replaces periodic sp_sysmonsMore detailed results & easier to analyzeBuilding a Monitoring RepositoryUse a dedicated DB per serverUse scheduled profiling jobs (server & application)Use on-demand user profiling collectorsProblem Isolation Key TablesOverallmonSysWaits/monProcessWaits, monOpenObjectActivityFollowed by monEngine, monIOQueue, monOpenDatabasesFor query performancemonProcessActivity, monSysStatement, monSysSQLText