Hi everybody!
This is a long doubt mine. And usually I want to apply this to testing machines that would not be a problem if crashed or destroyed at all. For the cases where I don't really care about the risks. In another words, not production at all.Sometime we have a machine that we work on and that is really really slow when doing I/O. I know that kernel will use memory to avoid doing I/O, and that it would be a kind of conservative in avoiding keep to much data on volatile memory susceptible to being lost on power failure. My question is, how to do the opposite, and avoid I/O as much as possible, doesn't matter the risks?
I'm using a virtual machine to test some ansible playbooks, the machine is just a testing environment so it will be created again and again and again. (And again). The playbook generates a lot of I/O, from yum installs, and another commands that inspect ISO images to create repositories, ... it doesn't matter, the problem is that it is really slow and that it doesn't contains any important data. What can I do to avoid I/O (by using memory) as much as possible? And how can I measure if it worked?
What I'm doing is keeping vm.dirty_background_ratio to the default (10) and setting vm.dirty_ratio to 90. From what I could grasp the first controls when the kernel thread will be scheduled to flush data to disk, and the second when the kernel will block I/O entirely. By the way, this is where the I/O wait from `top` comes from?
Anyway. The idea is that the flushing thread enters as soon as possible and that the blocking happens as late as possible so that I leave disks working but avoid I/O blocking.
How can I measure I/O blocking? Is there any counter for that so I can measure its frequency and compare before and after messing up with dirty_ratio?
Regards,
--
“If you're going to try, go all the way. Otherwise, don't even start. ..."
Charles Bukowski
Charles Bukowski
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
