In the case of 9.5.5 where this has been simplified in a Windows BES install to being on or off…
If it is a recommended setting that seems to have great value, why isn’t it enabled by default?
1 Like
Excellent question!
We tend to be conservative in making changes to our default configuration. In this case we had done some slow enablement and while most experiences were very good, we had one customer where there was negative impact. Until we had a proper explanation for this one case, we wanted to be cautious. We were able to drive a resolution for the customer (we are talking January time frame) and it was based on improper configuration outside of BigFix.
We are working now to enable as the default, and are simply choosing our timing.
1 Like
Great reply! May I ask what this other companies symptoms were? It would also be nice to have some parser or benchmark that could show this being a benefit. I assume this would be in the FillDB Performance Log? To put it simply, it would be nice to take a before and after and say, “these numbers look good and there was a performance increase”.
Yes, this was a result of monitoring the FillDB Performance Log with a well defined baseline. We could see degradation in terms of the throughput rates.
With the new parallel FillDB, we have on our list to prepare a blog to describe how it may be tuned beyond what we ship out of the box (e.g. if you have spare IO and CPU capability and want to “amp things up” further). As part of this, we will show how to monitor FIllDB (at the system and log levels) and better understand what it is doing.
Sounds great and I look forward to the BLOG.
I just enabled DatabaseBoostLevel on my production server and I started to get the following entries in my BESRelay.log about every 15 seconds. Changing the regkey to 0 and restarting FillDB stopped those errors. There didn’t seem to be any errors in the FillDBPerf.log that I could see.
The errors look like they are being triggered by my external WebUI ETL process?
I’m using SQL 2016 on my BES with a local database.
Mon, 19 Jun 2017 06:01:05 -0400 - /api/etl/computer-property-text (8476) - Database Error: [Microsoft][SQL Server Native Client 11.0][SQL Server]Transaction (Process ID 103) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. (40001: 1,205)
This is correct (though ideally should not be happening). We are working on improvements to the ETL process as it tends to acquire large sets of locks that compound this (in particular, when an ETL refresh occurs).
May I take that to mean that I can go ahead and turn DatabaseBoostLevel back on and ignore these errors as they are currently expected?
I would leave disabled for now as I put a high value on clean logs. I would also like to double check on a couple of things on our end in the interim. Thanks.
As am I and will do. Please let me know if you need me to try anything in the future.
Revisiting this thread. We are still on 9.5.5 and we had run the task to update the WebUI (I guess there were ETL improvements) some time ago. I just enabled DatabaseBoostLevel yesterday and I am not seeing those errors that I had in the BESRelay.log. After 24 hours both that log and FillDB.log seem fine.
On another note. There was talk of a FillDB BLOG. Did that ever happen?
I have a 24 hour FillDB Perf log using 9.5.5 just prior to an upgrade to 9.5.8. I then took a 24 hour log after the upgrade to 9.5.8. I think this would be good information to compare, but I don’t know how. I thought there was going to be a BLOG for folks to learn more about the FillDB.
You’ll want to use the FillDB PerfLog Analyzer to parse the logs and provide some comparable output. You should run the tool on a separate system from the server, and then look at the BIG BATCH insertion rates in both output files to compare. The first 4 rows are the most important, e.g.:
BIG BATCH insertion rates (number of batches with over 100 messages: 16940 ):
Fixlet Results: 42906300 rows / 37412227 ms = 1146 rows/sec (mean: 4420 +/- 1895)
Action Results: 11907739 rows / 3098053 ms = 3843 rows/sec (mean: 6288 +/- 2762)
Question Results: 33321053 rows / 18618182 ms = 1789 rows/sec (mean: 4700 +/- 1457)
Long Question Results: 976153 rows / 1943554 ms = 502 rows/sec (mean: 1432 +/- 872)I’ve used that in the past without much luck, but I’ll take another shot (now that I know what to look for). Thanks!
Is it normal to have these errors stream constantly during the parse? I’m running the EXE with no arguments. The log file and the EXE are all that are in the directory.
I’m going to guess it didn’t run:
c:>BESPerfLogParser-3.0.3.40.exe
Use of uninitialized value $regvalue in string ne at BESPerfLogParser.pl line 1764, line 165.
FillDB performance log found at: FillDBPerf-9-5-5.log
Analyzing logs…
Parsing lines…ERROR: Unable to parse line:
Mon, 05 Mar 2018 08:03:19 -0500 – 1096 – FillDB parallelism enabled for normal reports, with the following parameters:
9.5.5
BIG BATCH insertion rates (number of batches with over 100 messages: 0 ):
REPLICATION rates
MINIMUM insertion rates:
Fixlet Results: 1 rows / 24073 ms = 0 rows/sec
Action Results: 1 rows / 1089 ms = 0 rows/sec
Question Results: 1 rows / 500 ms = 2 rows/sec
9.5.8
BIG BATCH insertion rates (number of batches with over 100 messages: 0 ):
REPLICATION rates
MINIMUM insertion rates:
Fixlet Results: 1 rows / 28514 ms = 0 rows/sec
Action Results: 1 rows / 4108 ms = 0 rows/sec
Question Results: 1 rows / 514 ms = 1 rows/sec
Will someone be able to provide a working parser tool so that we can analyze our two FillDB PerfLogs? I can’t be the only one looking to do this.
It is normal to have some errors due to additional information in the log that isn’t needed for performance analysis. But it looks like it hasn’t been updated to account for the FillDB parallelism introduced recently. I’ll check if there is an updated version to post to the wiki.
hello @AlexaVonTess
at this link:
you should be able to get the right parser for the parallel mode of the FillDb
Let me know if it works for you.
Regards