∗∗∗THIS WILL EAT YOUR DATA, ONLY DO THIS IF YOU ARE SURE OF THE CONSEQUENCES∗∗∗
Now that the scary warning's out of the way we can be honest. There are plenty of situations where using the
changes below can be appropriate especially given the recent popularisation of immutable infrastructure.
I typically use these changes on throwaway vagrant machines where you don't want to burn cycles on your expensive SAN
for VMs that can be redeployed in seconds.
Some examples of the use-cases that I have found to be appropriate:
Throwaway development machines, esp. fast iteration docker/vagrant deployments
Overzealous analytics storage that's queried at most once every 6 months
Recreation of large envrionments for debugging purposes
Frozen VMs that automatically rollback on reboot
Replicated intermediatary data storage that filters & passes out to slower and more reliable storage (read data proxy)
A machine in a set which has a config that's stored in chef/puppet/etc. and can be redeployed in seconds if there's an issue
Kernel
Increase the amount of dirty blocks required before flushing
Increase the amount of RAM used for dirty block storage
Increase the timeout for dirty blocks to be flushed
This site is designed for a minimum horizontal resolution of 1250 pixels.
If you are using tablet you may be able to resolve this by turning it to a landscape orientation,
otherwise you can continue using the button below but the site may not work as intended.