Forecasting database performance
Download as PPTX, PDFâ˘3 likesâ˘1,050 views
The document discusses database capacity planning and analysis. It covers collecting and analyzing resource utilization data, developing mathematical models to predict performance, using queueing theory and response time analysis. Steps outlined include determining goals, gathering workload data, characterizing and modeling data, validating forecasts, and conducting case studies on deletion performance and evaluating MySQL capacity. The overall aim is to accurately measure current capacity, predict future growth, maintain balanced performance, and identify risks.
Forecasting database performance
- 1. Forecasting Database Performance Du Shenglin June 6th 2011
- 2. What do Capacity do?Manager ask âCan our database survive in next year or the new promotion programâ?Performance Tuning != Capacity planningDBA is not totally equal to Capacity Analyst
- 3. What do Capacity do?How Much headroom do we still have for further increasing, how many days can we hold without add/upgrade hardware?Whatâs the costs or impact to the site with adding or changing application codeWhat kind of platform/database/OS should we use for the new introduced applicationsHow to survive for the sudden performance deviations?
- 4. AgendaResourceModel and TheoryResponse Time AnalysisSteps to do Capacity AnalysisCase Study
- 5. Resource Site Level Machine, License, database, Storage, ManpowerâŚSystem Level CPU, IO, Memory, Disk, Network, Kernel SettingsDatabase Level Latch, Enqueue, Lock, Physical IO, Logical IOâŚ
- 6. Modeling - Making the Complex Simple The world is much too complex for us to understand. Mathematical ModelQueue theoryLine modelingRegression analysisUtilization BaselineModel is not perfect, not 100% precision
- 8. Linear Regression â Scalability
- 9. The Response Time CurveResponse Time=Service Time + Queue Time
- 10. Queuing TheoryRemain in the queue until its turn to be serviced Common FIFO or priority queueQueue lengthWait times and wait eventsCPU queue and IO queue
- 11. Response Time Drill DownResponse Time=Service Time + Queue TimeRt =St + QtCPUQueueNetworkTransferCPUUsr+SysMemoryQueueMemoryAccessDiskQueueDiskTransferNetworkQueue
- 12. Utilization and HeadroomHeadroom is available usable resources-Total Capacity minus Peak Utilization and Margin-Applies to CPU, RAM, Net, Disk and OS-Can be very complex to determine, it depends
- 13. CPU Capacity MeasurementsCPU utilization is defined as busy time divided by elapsed time for each CPUCPU time = CPU Queue + CPU usr+sysProcesses wait on a run queue, causing high load averages, then run on a CPU in user and system mode. More CPUs reduce queue wait. Faster CPUs reduce usr+sys time.
- 14. CPU Capacity MeasurementsU=Îť*St*MCPU Utilization=Arrival rate* cpu_time_exec(us)/POWER(10,6)/number_of_CPUCPU Utilization=buffer_gets* buffer_gets_time_per_exec(us)/POWER(10,6)/number_of_CPUWe can use this format for many cases
- 15. The Response Time Curve - Multiple CPU
- 16. IO Response Time ProfileRAM 60ns
- 17. HDD 5-10ms
- 18. SSD â 100 -500us
- 19. IO Service Time Includes 3 Components: - Access Time â Time It Takes To Move Heads To The Desired Track. - Rotation Time â Time It Takes To Locate The Desired Sector on The Track. -Transfer Time â Time It Takes To Read/Write The DataAccess Time Constitutes 70% of The Service TimeIO Average Wait Time db file sequential read â less than 15 ms
- 20. log file sync â less than 4msTrend Capacity MeasurementsSQL Execution Increase -> Traffic GrowthBuffer Gets Per Execution Fluctuates -> Normal Buffer ContentionsBuffer Gets Per Execution Increase Gradually -> SQL Efficiency ChangeCPU Increase Only -> System Overhead Increase, Latch SpinningâŚetcFind the commons during daily, weekly and yearly exexutions
- 21. Daily Executions
- 22. WoW Executions
- 23. YOY Executions
- 24. Data CollectionWhat kind of data to collectWhen to collect the dataWhere to put the dataHow often to collect the dataHow long to keep the dataHow to interpret and present the data A Picture Is Worth A Thousand Words Script and automate is necessary
- 25. Capacity Monitoring in database levelPeak executions SessionsShared pool usageLIO/execPIO/execCPU_time/LIORedo sizeFree memoryCommitsDisk space usageâŚ..
- 26. Risk Mitigation StrategiesCapacity Analyst is not only DBATuning/fixing the issue - DBA or SAâs task?Balancing existing workloadUpgrade and buy more CPU capacity Split and Sharding
- 27. Steps to take for Capacity Analysis1. Determine the question2. Gather workload data - What, how and how often3. Characterize the workload data - Map, Interpret the data 4. Develop and use appropriate model - Present your data, Graph5. Validate the forecast6. Forecast
- 28. Case Study #1 â Delete PerformanceQuestions:How many data can we delete every day?If the delete will catch up in no-peak time?How many thread can we use to do delete?Whatâs the main cost for delete job?
- 29. Case Study #1 â Delete Performancedelete performance is decided by IO response time/ PIO_Per_row.SNAP_TIME EXEC_PER_SEC LIO Per Exec PIO Per Exec Rows Per Exec-------------------- ------------ ------------ ------------ -------------2011/02/10 15:49 .04 10194.44 2323.02 10002011/02/10 16:04 .05 10200.82 2322 10002011/02/10 16:19 .06 10198.03 1967.9 999.92011/02/10 16:34 .06 10201.81 1985.98 10002011/02/10 16:49 .06 10194.11 2088.38 999.91/6m/(2323/1000)=1000000/6/2323=71 rowsThe real case:deletion started at: 2011-02-10 15:38:45rows to delete: 1232177rows deleted: 1232171deletion ended at: 2011-02-10 20:47:511232171/((TO_DATE('2011-02-1020:47:51','YYYY-MM-DDHH24:MI:SS')-TO_DATE('2011-02-1015:38:45','YYYY-MM-DDHH24:MI:SS'))*24*60*60)66.4386391
- 30. Case Study #2 â Using MySQLWhat capacity analysis Should we do to evaluate MySQL ?MySQL versionMachine OSLOCAL DISK/SSDKernel configurationMySQL Parametersmysql\MySQL InnoDB setup best practice.doc
- 31. Answers to what Capacity need to doMeasure the capacity of the site correctly and accurately.Be able to predict the growth of site, identify future performance problemDefine what is balance and find a strategy to keep dynamic balance.Impact analysis of system level change.Identify dangerous performance deviations.