From 78c53df1b9c062c25aaf83b57ab511adf1953e14 Mon Sep 17 00:00:00 2001 From: Patrick LeBlanc Date: Wed, 22 Apr 2020 17:14:41 -0400 Subject: [PATCH] MCOL-3889 part 1. Updated the storagemanager.cnf file. --- storage-manager/storagemanager.cnf | 35 ++++++++++-------------------- 1 file changed, 12 insertions(+), 23 deletions(-) diff --git a/storage-manager/storagemanager.cnf b/storage-manager/storagemanager.cnf index 2fa9b615c..17aba10f4 100644 --- a/storage-manager/storagemanager.cnf +++ b/storage-manager/storagemanager.cnf @@ -19,21 +19,14 @@ service = LocalStorage # # Regarding tuning, object stores do not support modifying stored data; # entire objects must be replaced on modification, and entire -# objects are fetched on read. This results in read and write amplification. -# -# Network characteristics are important to consider. If the machine is -# in the cloud and has low-latency and high-bandwidth access to the object -# store, then the limiting factor may be the get/put rate imposed by your -# cloud provider. In that case, using a larger object size will reduce -# the number of get/put ops required to perform a task. If the machine has -# low-bandwidth access to the object store, a lower value will reduce -# the degree of read/write amplification, reducing the total amount of data -# to transfer. +# objects are fetched on read. An access pattern that includes +# frequently accessing small amounts of data may benefit from +# a smaller object_size. An access pattern where data +# is accessed in large chunks may benefit from a larger object_size. # -# Of course, you will only really know how a complex system works by -# experimentation. If you experience poor performance using the default, -# our suggestion is to reduce it to 2M and try again, then increase it to -# 10M and try again. +# Another limitation to consider is the get/put rate imposed by your +# cloud provider. If that is the limitation, increasing object_size +# will result in higher transfer rates. # # object_size should not be changed after you have run postConfigure. # Things may fail that normally wouldn't. This is a temporary limitation which @@ -44,25 +37,21 @@ object_size = 5M # perspective, each file will be represented by a metadata file in this # path. A metadata file is a small json document enumerating the objects # that compose the file. -metadata_path = ${HOME}/storagemanager/metadata +metadata_path = /var/lib/columnstore/storagemanager/metadata # journal_path is where SM will store deltas to apply to objects. # If an existing object is modified, that modification (aka delta) will # be written to a journal file corresponding to that object. Periodically, # those deltas will be merged with the object they apply to, resulting # in a new object. -journal_path = ${HOME}/storagemanager/journal +journal_path = /var/lib/columnstore/storagemanager/journal # max_concurrent_downloads is what is sounds like, per node. # This is not a global setting. max_concurrent_downloads = 20 # max_concurrent_uploads is what is sounds like, per node. -# This is not a global setting. Currently, a file is locked while -# modifications to it are synchronized with cloud storage. If your network -# has low upstream bandwidth, consider lowering this value to the minimum -# necessary to saturate your network. This will reduce the latency of certain -# operations and improve your experience. +# This is not a global setting. max_concurrent_uploads = 20 # common_prefix_depth is the depth of the common prefix that all files @@ -110,7 +99,7 @@ bucket = some_bucket [LocalStorage] # path specifies where the module should store object data. -path = ${HOME}/storagemanager/fake-cloud +path = /var/lib/columnstore/storagemanager/fake-cloud # introduce latency to fake-cloud operations. Useful for debugging. fake_latency = n @@ -135,5 +124,5 @@ max_latency = 50000 cache_size = 2g # Cache/path is where cached objects get stored. -path = ${HOME}/storagemanager/cache +path = /var/lib/columnstore/storagemanager/cache