Many servers, especially databases like MySQL, are dealing with hard drive IO on every data insert, so in order to get much performance out of such databases with extensive amount of data inserts, it is critical to tune the IO writes. Tuning IO is a tedious task which requires many iterations until you eventually reach your goals or see any results.While tuning IO, I think that tuning for read performance is a different task from tuning for write performance. Combing them both can sometimes be one of the hardest tasks a SysAdmin can face. I decided to focus on write performance in the first article.
Top-downWearing both hats of a SysAdmin and developer, I like to implement development methodologies into system administration. This time it is the ‘top-down‘ development methodology – analyzing all steps from the top – the application behavior, operating system, filesystem and then eventually – the bottom – the hardware. When analyzing IO performance and designing for proper performance, always imagine IOPS as water running down a pipe – from your application to the hardware.If any part of the pipe is narrower – it wouldn’t run properly. And our task here is to examine this pipe and widen it where needed.
Characterize your IOSpeaking of write performance, you would usually find your IO either very sequential – such as writing video blocks one after the other. Or rather fairly random – such as user driven DB updates in places you can’t really expect them. Tuning the latter is a rather harder task as the input would be rather random.
Tune your applicationDevelopers are always afraid of using too much memory. Why? – I don’t know…Memory today is cheap, and by far too many times I have found developers investing countless hours developing something more optimized and save a “huge” amount of 4kb of memory. Memory is by far cheaper than labor.
Read more: monitis
QR:
Top-downWearing both hats of a SysAdmin and developer, I like to implement development methodologies into system administration. This time it is the ‘top-down‘ development methodology – analyzing all steps from the top – the application behavior, operating system, filesystem and then eventually – the bottom – the hardware. When analyzing IO performance and designing for proper performance, always imagine IOPS as water running down a pipe – from your application to the hardware.If any part of the pipe is narrower – it wouldn’t run properly. And our task here is to examine this pipe and widen it where needed.
Characterize your IOSpeaking of write performance, you would usually find your IO either very sequential – such as writing video blocks one after the other. Or rather fairly random – such as user driven DB updates in places you can’t really expect them. Tuning the latter is a rather harder task as the input would be rather random.
Tune your applicationDevelopers are always afraid of using too much memory. Why? – I don’t know…Memory today is cheap, and by far too many times I have found developers investing countless hours developing something more optimized and save a “huge” amount of 4kb of memory. Memory is by far cheaper than labor.
Read more: monitis
QR: