[SERVER-30389] Simple and generic way to restrict server parameter values Created: 28/Jul/17  Updated: 07/Jun/18  Resolved: 07/Jun/18

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-34345 Make it easier to provide validation ... Closed
is duplicated by SERVER-31719 Long overflow in setParameter Closed
Related
related to SERVER-27520 Allow unsigned types for MONGO_EXPORT... Closed
related to SERVER-30387 maxLogSizeKB parameter should only be... Closed
related to SERVER-30388 ttlMonitorSleepSecs parameter should ... Closed
related to SERVER-34952 Require validators for non-boolean se... Closed
Participants:

 Description   

Many numeric server parameters only make sense with positive values, or non-negative, but this is often not enforced. There may be negative impacts to the server if this is done (either deliberately or accidentally).

Part of the problem seems to be that there is no MONGO_EXPORT_SERVER_PARAMETER variant that can enforce simple restrictions on the permitted values. This means enforcing restrictions requires using ExportedServerParameter directly (with a fair amount of boilerplate), or MONGO_INITIALIZER hacks to enforce the restrictions through other means (only works for startup parameters). For the case of numeric parameters, SERVER-27520 explored the possibility of permitting unsigned types for parameters (and decided against it).

This ticket is to request a simple and easy way of enforcing simple restrictions for the most common cases, eg. min and/or max numeric value, string value from a set of allowed strings, non-empty string.

I can imagine a variant of MONGO_EXPORT_SERVER_PARAMETER which takes an extra argument to a "ServerParameterValidator" object (templated for genericism), which ExportedServerParameter then uses in the default validate() method. We could then provide some pre-canned ServerParameterValidators for the commonly-needed restrictions.



 Comments   
Comment by Kevin Pulo [ 07/Jun/18 ]

SERVER-34345 has implemented this mechanism, and SERVER-34952 is for adding validators to the existing parameters.

Comment by Kevin Pulo [ 28/Jul/17 ]

I did a quick audit of the numeric parameters in 3.4.6. (And more validation-less parameters are being added with MONGO_EXPORT_SERVER_PARAMETER all the time.)

These are the numeric parameters which use MONGO_EXPORT_SERVER_PARAMETER (or a variant) and don't enforce bounds. All of them are either a count, size, duration, or fraction/ratio, and only make sense with non-negative values.

  • ShardingTaskExecutorPoolHostTimeoutMS
  • ShardingTaskExecutorPoolMinSize
  • ShardingTaskExecutorPoolRefreshRequirementMS
  • ShardingTaskExecutorPoolRefreshTimeoutMS
  • clientCursorMonitorFrequencySecs
  • cursorTimeoutMillis
  • initialSyncOplogBufferPeekCacheSize
  • internalDocumentSourceCursorBatchSizeBytes
  • internalGeoNearQuery2DMaxCoveringCells
  • internalGeoPredicateQuery2DMaxCoveringCells
  • internalInsertMaxBatchSize
  • internalQueryCacheEvictionRatio
  • internalQueryCacheFeedbacksStored
  • internalQueryCacheSize
  • internalQueryEnumerationMaxIntersectPerAnd
  • internalQueryEnumerationMaxOrSolutions
  • internalQueryExecMaxBlockingSortBytes
  • internalQueryExecYieldIterations
  • internalQueryExecYieldPeriodMS
  • internalQueryFacetBufferSizeBytes
  • internalQueryMaxScansToExplode
  • internalQueryPlanEvaluationCollFraction
  • internalQueryPlanEvaluationMaxResults
  • internalQueryPlanEvaluationWorks
  • internalQueryPlannerMaxIndexedSolutions
  • internalQueryS2GeoCoarsestLevel
  • internalQueryS2GeoFinestLevel
  • internalQueryS2GeoMaxCells
  • jsHeapLimitMB
  • maxLogSizeKB
  • num3Dot2InitialSyncAttempts
  • numInitialSyncAttempts
  • numInitialSyncCollectionCountAttempts
  • numInitialSyncCollectionFindAttempts
  • numInitialSyncConnectAttempts
  • numInitialSyncListCollectionsAttempts
  • numInitialSyncListDatabasesAttempts
  • numInitialSyncListIndexesAttempts
  • numInitialSyncOplogFindAttempts
  • priorityTakeoverFreshnessWindowSeconds
  • replSnapshotThreadThrottleMicros
  • scriptingEngineInterruptIntervalMS
  • taskExecutorPoolSize
  • ttlMonitorSleepSecs

The numeric parameters which don't use MONGO_EXPORT_SERVER_PARAMETER, and also don't seem to enforce bounds:

  • connPoolMaxConnsPerHost
  • connPoolMaxShardedConnsPerHost
  • heapProfilingSampleIntervalBytes
  • syncdelay

The numeric parameters which use MONGO_EXPORT_SERVER_PARAMETER but enforce bounds some other way:

  • maxSyncSourceLagSecs > 0
  • replElectionTimeoutOffsetLimitFraction > 0.01

The numeric parameters which enforce bounds, without using MONGO_EXPORT_SERVER_PARAMETER:

  • diagnosticDataCollectionDirectorySizeMB >= 10
  • diagnosticDataCollectionFileSizeMB >= 1
  • diagnosticDataCollectionPeriodMillis >= 100
  • diagnosticDataCollectionSamplesPerChunk >= 2
  • diagnosticDataCollectionSamplesPerInterimUpdate >= 2
  • 1 <? journalCommitInterval <? 500
  • logLevel >= 0
  • 5 <= maxBSONDepth <= 1000
  • maxIndexBuildMemoryUsageMegabytes >= 100
  • oplogFetcherMaxFetcherRestarts >= 0
  • 1 <= replApplyBatchSize <= 1024
  • 1 <= replBatchLimitOperations <= 1000000
  • 1 <= replWriterThreadCount <= 256
  • scramIterationCount >= 5000
  • 0 <? tcmallocAggressiveMemoryDecommit <? 9223372036854775807
  • 0 <? tcmallocMaxTotalThreadCacheBytes <? 9223372036854775807
  • wiredTigerConcurrentReadTransactions > 0
  • wiredTigerConcurrentWriteTransactions > 0
Generated at Thu Feb 08 04:23:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.