From 8d8a0a3f5be190c1abad2e153e2695da9d7f2b63 Mon Sep 17 00:00:00 2001 From: Martin Sumner Date: Wed, 26 Sep 2018 09:37:50 +0100 Subject: [PATCH 1/2] Improve explanation of max_journal_size Tighten guidance with regards to very small values, which aren't expected to make sense --- docs/STARTUP_OPTIONS.md | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/docs/STARTUP_OPTIONS.md b/docs/STARTUP_OPTIONS.md index dbcc27e..c15bdef 100644 --- a/docs/STARTUP_OPTIONS.md +++ b/docs/STARTUP_OPTIONS.md @@ -14,23 +14,14 @@ There is no current support for running leveled so that it supports both `head` ## Max Journal Size -The maximum size of an individual Journal file can be set using `{max_journalsize, netger()}`, which sets the size in bytes. The default value is 1,000,000,000 (~1GB), and the maximum size cannot exceed `2^32`. +The maximum size of an individual Journal file can be set using `{max_journalsize, integer()}`, which sets the size in bytes. The default value is 1,000,000,000 (~1GB). The maximum size, which cannot be exceed is `2^32`. It is not expected that the Journal Size should normally set to lower than 100 MB, it should be sized to hold many thousands of objects at least. -If there are smaller objects then lookups within a Journal may get faster if each individual journal file is smaller. +If there are smaller objects then lookups within a Journal may get faster if each individual journal file is smaller. Generally there should be o(100K) objects per journal. Signs that the journal size is too high may include: -An object is converted before storing in the Journal. The conversion -may involve compression, the duplication of index changes prompted by -the object's storage, and the object's key. The max journal size -should always be bigger than the biggest object you wish to store, -accounting for conversion. +- excessive CPU use and related performance impacts during rolling of CDB files, see log `CDB07`; +- excessive load caused during journal compaction despite tuning down `max_run_length`. -Attempting to store a bigger object will crash the store. Ensure there -is ample room - generally it is anticipated that `max_journalsize` -should be greater than 100 MB, and maximum object size should be less -than 10MB. - -If you wish to store bigger objects, scale up the `max_journalsize` -accordingly. +If the store is used to hold bigger objects, the `max_journalsize` may be scaled up accordingly. Having fewer Journal files (by using larger objects), will reduce the lookup time to find the right Journal during GET requests, but in most circumstances the impact of this improvement is marginal. ## Ledger Cache Size From 3df481941f3eb7dbb403225f8c81166c14f17538 Mon Sep 17 00:00:00 2001 From: Martin Sumner Date: Wed, 26 Sep 2018 10:19:24 +0100 Subject: [PATCH 2/2] Record time to calculate compation run As this is a factor in assessing suitability of Journal size --- docs/STARTUP_OPTIONS.md | 2 +- src/leveled_iclerk.erl | 7 ++++++- src/leveled_log.erl | 3 ++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/STARTUP_OPTIONS.md b/docs/STARTUP_OPTIONS.md index c15bdef..6214c88 100644 --- a/docs/STARTUP_OPTIONS.md +++ b/docs/STARTUP_OPTIONS.md @@ -21,7 +21,7 @@ If there are smaller objects then lookups within a Journal may get faster if eac - excessive CPU use and related performance impacts during rolling of CDB files, see log `CDB07`; - excessive load caused during journal compaction despite tuning down `max_run_length`. -If the store is used to hold bigger objects, the `max_journalsize` may be scaled up accordingly. Having fewer Journal files (by using larger objects), will reduce the lookup time to find the right Journal during GET requests, but in most circumstances the impact of this improvement is marginal. +If the store is used to hold bigger objects, the `max_journalsize` may be scaled up accordingly. Having fewer Journal files (by using larger objects), will reduce the lookup time to find the right Journal during GET requests, but in most circumstances the impact of this improvement is marginal. The primary impact of fewer Journal files is the decision-making time of Journal compaction (the time to calculate if a compaction should be undertaken, then what should be compacted) will increase. The timing for making compaction calculations can be monitored through log `IC003`. ## Ledger Cache Size diff --git a/src/leveled_iclerk.erl b/src/leveled_iclerk.erl index ed7a8f3..9614825 100644 --- a/src/leveled_iclerk.erl +++ b/src/leveled_iclerk.erl @@ -217,6 +217,10 @@ handle_cast({compact, Checker, InitiateFun, CloseFun, FilterFun, Inker, _TO}, State) -> % Empty the waste folder clear_waste(State), + SW = os:timestamp(), + % Clock to record the time it takes to calculate the potential for + % compaction + % Need to fetch manifest at start rather than have it be passed in % Don't want to process a queued call waiting on an old manifest [_Active|Manifest] = leveled_inker:ink_getmanifest(Inker), @@ -233,6 +237,7 @@ handle_cast({compact, Checker, InitiateFun, CloseFun, FilterFun, Inker, _TO}, case score_run(BestRun0, ScoreParams) of Score when Score > 0.0 -> BestRun1 = sort_run(BestRun0), + leveled_log:log_timer("IC003", [Score, true], SW), print_compaction_run(BestRun1, ScoreParams), ManifestSlice = compact_files(BestRun1, CDBopts, @@ -258,7 +263,7 @@ handle_cast({compact, Checker, InitiateFun, CloseFun, FilterFun, Inker, _TO}, {noreply, State} end; Score -> - leveled_log:log("IC003", [Score]), + leveled_log:log_timer("IC003", [Score, false], SW), ok = leveled_inker:ink_compactioncomplete(Inker), ok = CloseFun(FilterServer), {noreply, State} diff --git a/src/leveled_log.erl b/src/leveled_log.erl index 0df0aeb..a08d97b 100644 --- a/src/leveled_log.erl +++ b/src/leveled_log.erl @@ -296,7 +296,8 @@ {"IC002", {info, "Clerk updating Inker as compaction complete of ~w files"}}, {"IC003", - {info, "No compaction run as highest score=~w"}}, + {info, "Scoring of compaction runs complete with highest score=~w " + ++ "and run to be made=~w"}}, {"IC004", {info, "Score for filename ~s is ~w"}}, {"IC005",