Wed, Jul 18
Tue, Jul 10
This service is now disabledd/removed on the RESTBase cluster; Thanks a bunch for the assist!
Fri, Jul 6
fio --randrepeat=1 \ --ioengine=libaio \ --direct=1 \ --gtod_reduce=1 \ --name=test \ --filename=/srv/sda4/fio.test \ --bs=4k \ --iodepth=4 \ --size=4G \ --readwrite=randrw \ --rwmixread=90
So (just to be clear), I use gbp on this repo, and the Debian packaging is in the debian branch, changes to master get merged there before building. I've done that (the merge), and tagged master as upstream/1.0.3. I also updated the changelog to 1.0.3-1.
Thu, Jul 5
The change is merged, but we still need to get a package built, have it added to the APT repo, and then upgrade the machines.
With the default settings of c-foreach-restart it's no longer possible to reliably restart Cassandra on the restbase hosts (probably due to increased data set sizes or higher I/O), resulting in tracebacks like the following:
Tue, Jul 3
This ticket is old, and comes from a period when we were having problems that elevated the importance of this type of reporting. I'm content to call this "unneeded" at this point, and close the issue.
@fgiunchedi, is this still a thing?
@elukey, is this still a thing?
I believe this was completed by virtue of the new storage strategy implementation.
I think this is solved by the migration to Prometheus (feel free to reopen if that is not the case).
This was resolved by the upgrade to 1:0.3.0
RESTBase has been upgraded:
AQS has been partially upgraded:
Fri, Jun 29
Tue, Jun 26
Mon, Jun 25
Fri, Jun 22
Wed, Jun 20
We have a good understanding of the limits of the Samsung devices (since we routinely run them past those limits), less so for the Intel/HPs, because they are so very under-utilized. Perhaps the easiest way to create a concrete comparison (and infer needed capacity), would be to shutdown Cassandra and benchmark a quiescent storage device. We could do this for a Samsung-equipped host (say restbase2001), and an Intel-equipped one (say restbase2010). Another Intel-equipped host not in use could work as well.
Jun 19 2018
Jun 18 2018
I've verified these myself, by for sake of posterity, I propose applying the following:
Jun 15 2018
Jun 14 2018
Jun 13 2018
These ALTERs LGTM; For posterity, here they are as YAML:
Jun 12 2018
Jun 11 2018
The RESTBase Cassandra cluster has been upgraded to 3.11.2; Resolving