Bufferbloat, rotational disk + BBU style. In case you still you magnetic disks to back a database taking writes, it can be worthwhile to disable "intelligent" controllers that do their own caching/readahead:pic.twitter.com/OoNs560vNU
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
By collecting a lot of random writes in the BBU's writeback cache, and causing additional IOs for it's internal readahead, IO latencies grow absurdly. And on e.g. plenty LSI SAS controllers, the queue management for that is wholly unusable.
Note that for other workloads, with fewer random writes (e.g. increasing shared buffers to contain the whole working set, making small sequential writes more important by using logged tables in an OLTP setup) and more synchronous writes that's not true:pic.twitter.com/B8ru6zbsFf
The queuing logic inside the controller still clearly is crappy, but it's outweighed by being able to acknowledge WAL flushes. So, WAL should be on a drive with the BBU's caching enabled, data absolutely not.
It is about hardware raid controllers?
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.