Yifan Zhang has posted comments on this change. ( http://gerrit.cloudera.org:8080/15995 )
Change subject: [maintenance] use workload statistics to scale perf_improvement ...................................................................... Patch Set 2: (3 comments) http://gerrit.cloudera.org:8080/#/c/15995/1/src/kudu/tablet/tablet_mm_ops.h File src/kudu/tablet/tablet_mm_ops.h: http://gerrit.cloudera.org:8080/#/c/15995/1/src/kudu/tablet/tablet_mm_ops.h@76 PS1, Line 76: uint64_t > Perhaps use MonoDelta for this instead? Or do we need the CPU and everythin Done http://gerrit.cloudera.org:8080/#/c/15995/1/src/kudu/tablet/tablet_mm_ops.cc File src/kudu/tablet/tablet_mm_ops.cc: http://gerrit.cloudera.org:8080/#/c/15995/1/src/kudu/tablet/tablet_mm_ops.cc@156 PS1, Line 156: uint64_t scans_started = metrics->scans_started->value() - last_scans_started_; > While "rows scanned" does measure activity, it also scales as the dataset > grows, meaning larger tablets will tend to look more active. We should also > probably think about what scan rate warrants us calling a tablet "active" for > scans, and make sure the below values agree with that assessment. Ignoring > writes for a second, here we are saying that any tablet that scans more than > 1000 rows per second is considered very active. I'm not sure whether rows per > second is better than, e.g. number of scanners started, or number of scanners > started per second. Yes, I think number of scanners started per second is better. > "key lookups per op" also does measure activity, but it is more of a measure > of rowset overlap (e.g. if you have 10 overlapping rowsets, an insert op to > the overlapped keyspace may check 10 key indexes for that op). This scales as > the batch size grows. That said, I'm not sure why write activity should > result in more compaction. Can you further describe the desired performance > characteristics of your workloads that you're trying to improve? I use "key file lookup ops", i.e. "total count" of "key file lookups per op", I think it indicated how many write operations that performed key file lookups, so maybe it could be used to measure the frequency of key file lookup operations. And we want to improve performance of these ops. http://gerrit.cloudera.org:8080/#/c/15995/1/src/kudu/tablet/tablet_replica_mm_ops.cc File src/kudu/tablet/tablet_replica_mm_ops.cc: http://gerrit.cloudera.org:8080/#/c/15995/1/src/kudu/tablet/tablet_replica_mm_ops.cc@132 PS1, Line 132: // performs to update perf_improvement. The perf score will be improved depend on : // how 'hot' the tablet was, and will be improved by at most 1.0 because : // we want all tablets that have very large read traffic have equal : // opportunity to perfom flush. : double read_rate = static_cast< > I'm not sure I understand the rationale behind flushing "hot" MRSs. If > they're hot, isn't it better to keep them in memory? Or is the idea that the > MRS isn't as efficient as reading the DRS from the block cache? Also, if > there's non-zero bytes in the MRS, doesn't that indicate that it's hot? I think flushing may speed up scans so we may prefer flush MRSs for scan-heavy tablets. It seems better to only use scan rate here to update perf_improvement. If a tablet is write-heavy, there would be some large MRSs and thus the tablet flush op would have a high perf score. > I'm also somewhat concerned about flush starvation. Does this make it > possible that cold MRSs will never flush, and will anchor RAM and WALs > indefinitely? When cold MRSs become larger or "older" than hot MRSs, they will flush. Consider that now we use scanner started per second, which is quite low for most tablets, so flush starvation is seldom possible. -- To view, visit http://gerrit.cloudera.org:8080/15995 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Ie3afcc359002d1392164ba2fda885f8930ef8696 Gerrit-Change-Number: 15995 Gerrit-PatchSet: 2 Gerrit-Owner: Yifan Zhang <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Yifan Zhang <[email protected]> Gerrit-Comment-Date: Wed, 03 Jun 2020 02:48:14 +0000 Gerrit-HasComments: Yes
