Performance Management: Day 5
Nov. 28th, 2008 03:12 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sawylShort final day, which involved running through the basic performance tuning methodology one last time and running through a couple of example cases.
The first study, a synthetic example from IBM, involved running through PerfPMR output in an attempt to determine whether the system was overloaded. After going through the output and spotting an absurd amount of IO being done to the root file system, we quickly decided that system would benefit from a reconfiguration of the disc devices to prevent data IO from contending with journal IO.
The second study, a real world example the instructor had picked up in a quid pro quo deal from a former course attendee who'd asked why their application showed poor response during peak hours. We ran through a few spreadsheets of nmon output, guessing from the number of fabric attached discs that the machine was probably running some sort of RDBMS, noticing substantial peaks in CPU during normal working hours. Looking closer, we noticed that the system was clocking up large amounts of time waiting for IO, but this failed to coincide with large amounts of file IO and when we looked at the physical disc activity, we noticed that most of the traffic was going to the root volume group suggesting heavy paging, something confirmed by one of the later spreadsheets which showed the system was moving hundreds of pages to and from the backing store every second. We discussed some of the obvious tunings — buy more memory; change the amount of internal caching use by the database to force data to be reloaded from the, presumably faster, fabric discs rather than caching it to disc on the relatively slow internal SCSI discs.
And with that, we called it a day, munched down our final round of course sandwiches and went home.
The first study, a synthetic example from IBM, involved running through PerfPMR output in an attempt to determine whether the system was overloaded. After going through the output and spotting an absurd amount of IO being done to the root file system, we quickly decided that system would benefit from a reconfiguration of the disc devices to prevent data IO from contending with journal IO.
The second study, a real world example the instructor had picked up in a quid pro quo deal from a former course attendee who'd asked why their application showed poor response during peak hours. We ran through a few spreadsheets of nmon output, guessing from the number of fabric attached discs that the machine was probably running some sort of RDBMS, noticing substantial peaks in CPU during normal working hours. Looking closer, we noticed that the system was clocking up large amounts of time waiting for IO, but this failed to coincide with large amounts of file IO and when we looked at the physical disc activity, we noticed that most of the traffic was going to the root volume group suggesting heavy paging, something confirmed by one of the later spreadsheets which showed the system was moving hundreds of pages to and from the backing store every second. We discussed some of the obvious tunings — buy more memory; change the amount of internal caching use by the database to force data to be reloaded from the, presumably faster, fabric discs rather than caching it to disc on the relatively slow internal SCSI discs.
And with that, we called it a day, munched down our final round of course sandwiches and went home.
