Examples: ScyllaDB, RedPanda. Both are using the Seastar framework for scheduling and IO.
6,486 karma · joined July 15, 2018
blog: tanelpoder.com
Examples: ScyllaDB, RedPanda. Both are using the Seastar framework for scheduling and IO.
In a busy database there are lots of processes reading a datafile and multiple processes writing (like DBWR checkpointing dirty blocks from buffer cache, but also some others), so this caused unnecessary file level contention in the OS kernel. Note that Oracle has I/O concurrency control built in, you can't have two processes accidentally writing the same block to the storage at the same time or a reader reading a "torn block" due to an ongoing write (the serialization happens at buffer lock/pin level in Oracle code).
So you wanted to have concurrent I/O and you either had to use raw devices or Veritas VxFS back then. Later on concurrent I/O became available for some other filesystems too, like Solaris UFS having the "cio" mount option, etc.
Edit: as in you have to code BASIC to change the channel
I think Google added an option to disable all/most autoplaying content in Chrome a couple of years ago. But they quickly backtracked and removed that flag, claiming that it breaks in-browser games or something like that. It's a pretty weak reason for me, I don't care about in-browser games, I just want to read a news article without some irrelevant video popup distracting me, plus blasting audio.
(Yes I know such sites/tricks may increase my download traffic and brower CPU usage, etc, but I would just stop using such sites then, as I do now)
Edit: Should add "won't be silently propagated"
So... they successfully built the solution, but then failed to build a suitable problem for it?
Might be that very few people (if anyone at all!) actually did that or needed that.
Edit: However, 384 GB of RAM seems a too low maximum though for a maxed out 2023 professional workstation.
Edit: add link:
https://www.manning.com/books/algorithms-and-data-structures...
But what the heck, this is not how wepages should work - click here to "unblur" the image? Why add such an extra step? To save bandwidth cost?
The other reason is that I've troubleshooted plenty of Linux load spike problems that are about CPU demand spikes only, usually due to some spinlock that gets held unusually long or some interrupt storm issue or some sort of a "database logon storm" due to connection pools in the app server suddenly creating thousands of additional DB connections...
Edit: I understand that PSI was created as an easy (and cheap) to query metric to see if your Android mobile device has a problem (and some apps need to be killed) and not really for full blown troubleshooting drilldown of server workloads.