bexhoma.configurations module
- Date:
2022-10-01
- Version:
0.6.0
- Authors:
Patrick K. Erdelt
Class for managing an DBMS configuation. This is plugged into an experiment object.
Copyright (C) 2020 Patrick K. Erdelt
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
- class bexhoma.configurations.benchbase(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')
Bases:
default
- Date:
2022-10-01
- Version:
0.6.0
- Authors:
Patrick K. Erdelt
Class for managing an DBMS configuation. This is plugged into an experiment object.
- param experiment:
Unique identifier of the experiment
- param docker:
Name of the Docker image
- param configuration:
Name of the configuration
- param script:
Unique identifier of the experiment
- param alias:
Unique identifier of the experiment
Copyright (C) 2020 Patrick K. Erdelt
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
- create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', num_pods=1)
Creates a job template for the benchmarker. This sets meta data in the template and ENV. This sets some settings specific to YCSB.
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms
- Returns:
Name of file in YAML format containing the benchmarker job
- class bexhoma.configurations.default(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')
Bases:
object
- Date:
2022-10-01
- Version:
0.6.0
- Authors:
Patrick K. Erdelt
Class for managing an DBMS configuation. This is plugged into an experiment object.
- param experiment:
Unique identifier of the experiment
- param docker:
Name of the Docker image
- param configuration:
Name of the configuration
- param script:
Unique identifier of the experiment
- param alias:
Unique identifier of the experiment
Copyright (C) 2020 Patrick K. Erdelt
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
- OLD_get_items(app='', component='', experiment='', configuration='')
- add_benchmark_list(list_clients)
Add a list of (number of) benchmarker instances, that are to benchmark the current SUT. Example: [1,2,1] means sequentially we will have 1, then 2 and then 1 benchmarker instances.
- Parameters:
list_clients – List of (number of) benchmarker instances
- add_benchmarking_parameters(**kwargs)
Sets ENV for benchmarking components. Can be set by experiment before creation of configuration. This generates a list, where each entry corresponds to a set of clients in a sequence of benchmarkers.
- Parameters:
kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’
- attach_worker()
Attaches worker nodes to the master of the sut. This runs the dockertemplate[‘attachWorker’] command.
- check_DBMS_connection(ip, port)
Check if DBMS is open for connections. Tries to open a socket to ip:port. Returns True if this is possible.
- Parameters:
ip – IP of the host to connect to
port – Port of the server on the host to connect to
- Returns:
True, iff connecting is possible
- check_load_data()
Check if loading of the sut has finished. If yes, store timeLoadingStart, timeLoadingEnd, timeLoading as labels and in this object as attributes. If there is a loading job: check if all pods are completed. Copy the logs of the containers in the pods and remove the pods. If there is no loading job: Read the labels. If loaded is True, store the timings in this object as attributes.
- check_sut()
Check if the pod of the sut is running. If yes, store it’s name in self.pod_sut.
- client
If we have a sequence of benchmarkers, this tells at which position we are
- configuration
Name of the configuration, default: Name of the Docker image
- connection_parameter
Collect all parameters that might be interesting in evaluation of results
- copyLog()
- create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', env={}, template='', num_pods=1)
Creates a job template for the benchmarker. This sets meta data in the template and ENV.
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms
env – Dict of environment variables
template – Template for the job manifest
- Returns:
Name of file in YAML format containing the benchmarker job
- create_manifest_job(app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, env={}, template='', nodegroup='', num_pods=1, connection='', patch_yaml='')
Creates a job and sets labels (component/ experiment/ configuration).
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
experimentRun – Number of run of the configuration in this experiment
client – Number of client of the job for this experiment run
parallelism – Number of parallel pods in this job
env – Dict of environment variables for the job manifest
template – Template name of the job manifest
nodegroup – Nodegroup of the pods of the job
num_pods – Number of pods that run in total
- create_manifest_loading(app='', component='loading', experiment='', configuration='', parallelism=1, alias='', num_pods=1, connection='')
Creates a job template for loading. This sets meta data in the template and ENV.
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job
- Returns:
Name of file in YAML format containing the loading job
- create_manifest_maintaining(app='', component='maintaining', experiment='', configuration='', parallelism=1, alias='', num_pods=1, connection='')
Creates a job template for maintaining. This sets meta data in the template and ENV.
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job
- Returns:
Name of file in YAML format containing the maintaining job
- create_monitoring(app='', component='monitoring', experiment='', configuration='')
Generate a name for the monitoring component. Basically this is {app}-{component}-{configuration}-{experiment}-{client}
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- delay(sec, silent=False)
Function for waiting some time and inform via output about this. Synonymous for wait()
- Parameters:
sec – Number of seconds to wait
silent – True means we do not output anything about this waiting
- docker
Name of the Docker image
- dockerimage
Name of the Docker image of the SUT
- dockertemplate
Template of the Docker information taken from cluster.config
- execute_command_in_pod_sut(command, pod='', container='dbms', params='')
Runs an shell command remotely inside a container of a pod. This defaults to the current sut’s pod and the container “dbms”
- Parameters:
command – A shell command
pod – The name of the pod - default current sut’s pod
container – The name of the container in the pod - default dbms
params – Optional parameters, currently ignored
- Returns:
stdout of the shell command
- experiment
Unique identifier of the experiment
- experiment_done
True, iff the SUT has performed the experiment completely
- generate_component_name(app='', component='', experiment='', configuration='', experimentRun='', client='')
Generate a name for the component. Basically this is {app}-{component}-{configuration}-{experiment}-{client}
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of the client, if it comes from a sequence of same components (in particular benchmarker)
- getTimediff()
- get_connection_config(connection, alias='', dialect='', serverip='localhost', monitoring_host='localhost')
Returns information about the sut’s host disk space. Basically this calls df / on the host.
- Returns:
Size of disk in Bytes
- get_host_all()
Calls all get_host_x() methods. Returns information about the sut’s host as a dict.
- Returns:
Dict of informations about the host
- get_host_cores()
Returns information about the sut’s host CPU’s cores. Basically this calls grep -c ^processor /proc/cpuinfo on the host.
- Returns:
CPU’s cores of the host
- get_host_cpu()
Returns information about the sut’s host CPU. Basically this calls more /proc/cpuinfo | grep ‘model name’ on the host.
- Returns:
CPU of the host
- get_host_cuda()
Returns information about the sut’s host CUDA version. Basically this calls nvidia-smi | grep ‘CUDA’ on the host.
- Returns:
CUDA version of the host
- get_host_diskspace_used()
Returns information about the sut’s host disk space. Basically this calls df / on the host.
- Returns:
Size of disk in Kilobytes
- get_host_diskspace_used_data()
Returns information about the sut’s host disk space used for the data (the database) in kilobyte. Basically this calls du on the host directory that is mentioned in cluster.config as to store the database.
- Returns:
Size of disk used for database in Kilobytes
- get_host_gpu_ids()
Returns information about the sut’s host GPUs. Basically this calls nvidia-smi -L on the host and generates a list of UUIDs of the GPUs.
- Returns:
List of GPU UUIDs of the host
- get_host_gpus()
Returns information about the sut’s host GPUs. Basically this calls nvidia-smi -L on the host and aggregates result.
- Returns:
GPUs of the host
- get_host_memory()
Returns information about the sut’s host RAM. Basically this calls grep MemTotal /proc/meminfo on the host.
- Returns:
RAM of the host
- get_host_node()
Returns information about the sut’s host name. Basically this calls kubectl get pod to receive the information.
- Returns:
Node name of the host
- get_host_system()
Returns information about the sut’s host OS. Basically this calls uname -r on the host.
- Returns:
OS of the host
- get_instance_from_resources()
Generates an instance name out of the resource parameters that are set using set_resources(). Should be DEPRECATED and replaced by something better.
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- get_patched_yaml(file, patch='')
Applies a YAML formatted patch to a YAML file and returns merged result as a YAML object.
- Parameters:
file – Name of YAML file to load
patch – Optional patch to be applied
- Returns:
YAML object of (patched) file content
- get_service_sut(configuration)
Returns the same of the service where to connect to the SUT. This in general is the name of the service of the deployed component. For SUT, that require a component that is not controlled by bexhoma, this may be overwritten.
- Parameters:
configuration – name of the configuration
- Returns:
name of the configuration’s sut’s service
- get_worker_endpoints()
Returns all endpoints of a headless service that monitors nodes of a distributed DBMS. These are IPs of cAdvisor instances. The endpoint list is to be filled in a config of an instance of Prometheus. By default, the workers can be found by the name of their component (worker-0 etc).
- Returns:
list of endpoints
- get_worker_pods()
- load_data(scripts, time_offset=0, time_start_int=0, script_type='loaded')
Start loading data into the sut. This runs load_data_asynch() as an asynchronous thread. At first prepare_init_dbms() is run.
- loading_after_time
Time as an integer when initial loading should start - to give the system time to start up completely
- loading_finished
Time as an integer when initial loading has finished
- loading_started
Time as an integer when initial loading has started
- maintaining_is_pending()
Returns True, iff maintaining is in pending state.
- Returns:
True, if maintaining is in pendig state
- maintaining_is_running()
Returns True, iff maintaining is running.
- Returns:
True, if dbms is running
- monitor_loading
Fetch metrics for the loading phase, if monítoring is active - this is set to False when loading is skipped due to PV
- monitoring_is_pending()
Returns True, iff monitoring is in pending state.
- Returns:
True, if monitoring is in pendig state
- monitoring_is_running()
Returns True, iff monitoring is running.
- Returns:
True, if monitoring is running
- patch_benchmarking(patch)
Patches YAML of loading components. Can be set by experiment before creation of configuration.
- Parameters:
patch – String in YAML format, overwrites basic YAML file content
- patch_loading(patch)
Patches YAML of loading components. Can be set by experiment before creation of configuration.
- Parameters:
patch – String in YAML format, overwrites basic YAML file content
- pod_sut
Name of the sut’s master pod
- prepare_init_dbms(scripts)
Prepares to load data into the dbms. This copies the DDL scripts to /tmp on the host of the sut. Optionally parameters in DDL script are replaced by ddl_parameters. The files are renamed filled_ then.
- reset_sut()
Forget that the SUT has been loaded and benchmarked.
- run_benchmarker_pod(connection=None, alias='', dialect='', query=None, app='', component='benchmarker', experiment='', configuration='', client='1', parallelism=1)
Runs the benchmarker job. Sets meta data in the connection.config. Copy query.config and connection.config to the first pod of the job (result folder mounted into every pod)
- Parameters:
connection – Name of configuration prolonged by number of runs of the sut (installations) and number of client in a sequence of
alias – An alias can be given if we want to anonymize the dbms
dialect – A name of a SQL dialect can be given
query – The benchmark can be fixed to a specific query
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker this is in a sequence of
parallelism – Number of parallel benchmarker pods we want to have
- set_additional_labels(**kwargs)
Sets additional labels, that will be put to K8s objects (and ignored otherwise). This is for the SUT component. Can be set by experiment before creation of configuration.
- Parameters:
kwargs – Dict of labels, example ‘SF’ => 100
- set_benchmarking_parameters(**kwargs)
Sets ENV for benchmarking components. Can be set by experiment before creation of configuration.
- Parameters:
kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’
- set_connectionmanagement(**kwargs)
Sets connection management data for the experiment. This is for the benchmarker component (dbmsbenchmarker). Can be overwritten by configuration.
- Parameters:
kwargs – Dict of meta data, example ‘timout’ => 60
- set_ddl_parameters(**kwargs)
Sets DDL parameters for the experiments. This substitutes placeholders in DDL script. Can be set by experiment before creation of configuration.
- Parameters:
kwargs – Dict of meta data, example ‘index’ => ‘btree’
- set_eval_parameters(**kwargs)
Sets some arbitrary parameters that are supposed to be handed over to the benchmarker component. Can be set by experiment before creation of configuration.
- Parameters:
kwargs – Dict of meta data, example ‘type’ => ‘noindex’
- set_experiment(instance=None, volume=None, docker=None, script=None, indexing=None)
Read experiment details from cluster config
- set_loading(parallel, num_pods=None)
Sets job parameters for loading components: Number of parallel pods and optionally (if different) total number of pods. By default total number of pods is set to number of parallel pods. Can be set by experiment before creation of configuration.
- Parameters:
parallel – Number of parallel pods
num_pods – Optionally (if different) total number of pods
- set_loading_parameters(**kwargs)
Sets ENV for loading components. Can be set by experiment before creation of configuration.
- Parameters:
kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’
- set_maintaining(parallel, num_pods=None)
Sets job parameters for maintaining components: Number of parallel pods and optionally (if different) total number of pods. By default total number of pods is set to number of parallel pods. Can be set by experiment before creation of configuration.
- Parameters:
parallel – Number of parallel pods
num_pods – Optionally (if different) total number of pods
- set_maintaining_parameters(**kwargs)
Sets ENV for maintaining components. Can be set by experiment before creation of configuration.
- Parameters:
kwargs – Dict of meta data, example ‘PARALLEL’ => ‘64’
- set_metric_of_config(metric, host, gpuid)
Returns a promql query. Parameters in this query are substituted, so that prometheus finds the correct metric. Example: In ‘sum(irate(container_cpu_usage_seconds_total{{container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_container_name=”dbms”}}[1m]))’ configuration and experiment are placeholders and will be replaced by concrete values.
- Parameters:
metric – Parametrized promql query
host – Name of the host the metrics should be collected from
gpuid – GPU that the metrics should watch
- Returns:
promql query without parameters
- set_nodes(**kwargs)
- set_resources(**kwargs)
Sets resources for the experiment. This is for the SUT component. Can be overwritten by experiment and configuration.
- Parameters:
kwargs – Dict of meta data, example ‘requests’ => {‘cpu’ => 4}
- set_storage(**kwargs)
Sets parameters for the storage that might be attached to components. This is in particular for the database of dbms under test. Example:
storageClassName = ‘ssd’, storageSize = ‘100Gi’, keep = False
Can be set by experiment before creation of configuration.
- Parameters:
kwargs – Dict of meta data, example ‘storageSize’ => ‘100Gi’
- start_loading(delay=0)
Starts data ingestion by calling scripts inside the sut (dbms) container.
- Parameters:
delay – Number of seconds to wait after calling scripts
- start_loading_pod(app='', component='loading', experiment='', configuration='', parallelism=1, num_pods=1)
Starts a job for parallel data ingestion.
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job
- start_maintaining(app='', component='maintaining', experiment='', configuration='', parallelism=1, num_pods=1)
Starts a maintaining job.
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
parallelism – Number of parallel pods in job
- start_monitoring(app='', component='monitoring', experiment='', configuration='')
Starts a monitoring deployment.
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- start_sut(app='', component='sut', experiment='', configuration='')
Start the system-under-test (dbms). This also controls optional worker and storage. Resources are set according to set_resources().
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- stop_loading(app='', component='loading', experiment='', configuration='')
Stops a loading job and removes all its pods.
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- stop_maintaining(app='', component='maintaining', experiment='', configuration='')
Stops a monitoring deployment and removes all its pods.
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- stop_monitoring(app='', component='monitoring', experiment='', configuration='')
Stops a monitoring deployment and removes its service.
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- stop_sut(app='', component='sut', experiment='', configuration='')
Stops a sut deployment and removes all its services and (optionally) stateful sets. It also stops and removes all related components (monitoring, maintaining, loading).
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- sut_is_pending()
Returns True, iff system-under-test (dbms) is in pending state.
- Returns:
True, if dbms is in pendig state
- sut_is_running()
Returns True, iff system-under-test (dbms) is running.
- Returns:
True, if dbms is running
- timeGenerating
Time in seconds the system has taken for generating the data
- timeIndex
Time in seconds the system has taken for indexing the database
- timeIngesting
Time in seconds the system has taken for ingesting existing
- timeLoading
Time in seconds the system has taken for the initial loading of data
- timeSchema
Time in seconds the system has taken for creating the db schema
- use_distributed_datasource
True, iff the SUT should mount ‘benchmark-data-volume’ as source of (non-generated) data
- use_storage()
Return True, iff storage for the database should be used. Otherwise database is inside ephemeral-storage.
- wait(sec, silent=False)
Function for waiting some time and inform via output about this
- Parameters:
sec – Number of seconds to wait
silent – True means we do not output anything about this waiting
- class bexhoma.configurations.hammerdb(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')
Bases:
default
- Date:
2022-10-01
- Version:
0.6.0
- Authors:
Patrick K. Erdelt
Class for managing an DBMS configuation. This is plugged into an experiment object.
- param experiment:
Unique identifier of the experiment
- param docker:
Name of the Docker image
- param configuration:
Name of the configuration
- param script:
Unique identifier of the experiment
- param alias:
Unique identifier of the experiment
Copyright (C) 2020 Patrick K. Erdelt
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
- create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', num_pods=1)
Creates a job template for the benchmarker. This sets meta data in the template and ENV. This sets some settings specific to HammerDB.
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms
- Returns:
Name of file in YAML format containing the benchmarker job
- class bexhoma.configurations.kinetica(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')
Bases:
default
- Date:
2022-10-01
- Version:
0.6.0
- Authors:
Patrick K. Erdelt
Class for managing an DBMS configuation. This is plugged into an experiment object. This class contains specific settings for a Kinetica installation. This is handled outside of bexhoma with the official KAgent. The service name is fixed to be “bexhoma-service-kinetica”
- param experiment:
Unique identifier of the experiment
- param docker:
Name of the Docker image
- param configuration:
Name of the configuration
- param script:
Unique identifier of the experiment
- param alias:
Unique identifier of the experiment
Copyright (C) 2020 Patrick K. Erdelt
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
- create_monitoring(app='', component='monitoring', experiment='', configuration='')
Generate a name for the monitoring component. Basically this is {app}-{component}-{configuration}-{experiment}-{client}. For Kinetica, the service to be monitored is named ‘bexhoma-service-kinetica’.
- Parameters:
app – app the component belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
- get_service_sut(configuration)
Returns the same of the service where to connect to the SUT. This in general is the name of the service of the deployed component. For SUT, that require a component that is not controlled by bexhoma, this may be overwritten. Here, always “bexhoma-service-kinetica” is returned.
- Parameters:
configuration – name of the configuration
- Returns:
name of the configuration’s sut’s service
- get_worker_endpoints()
Returns all endpoints of a headless service that monitors nodes of a distributed DBMS. These are IPs of cAdvisor instances. The endpoint list is to be filled in a config of an instance of Prometheus. For Kinetica the service is fixed to be ‘bexhoma-service-monitoring-default’ and does not depend on the experiment.
- Returns:
list of endpoints
- set_metric_of_config(metric, host, gpuid)
Returns a promql query. Parameters in this query are substituted, so that prometheus finds the correct metric. Example: In ‘sum(irate(container_cpu_usage_seconds_total{{container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_pod_name=~”(.*){configuration}-{experiment}(.*)”, container_label_io_kubernetes_container_name=”dbms”}}[1m]))’ configuration and experiment are placeholders and will be replaced by concrete values. Here: We do not have a SUT that is specific to the experiment or configuration.
- Parameters:
metric – Parametrized promql query
host – Name of the host the metrics should be collected from
gpuid – GPU that the metrics should watch
- Returns:
promql query without parameters
- bexhoma.configurations.load_data_asynch(app, component, experiment, configuration, pod_sut, scriptfolder, commands, loadData, path, volume, context, service_name, time_offset=0, time_start_int=0, script_type='loaded')
- class bexhoma.configurations.ycsb(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')
Bases:
default
- Date:
2022-10-01
- Version:
0.6.0
- Authors:
Patrick K. Erdelt
Class for managing an DBMS configuation. This is plugged into an experiment object.
- param experiment:
Unique identifier of the experiment
- param docker:
Name of the Docker image
- param configuration:
Name of the configuration
- param script:
Unique identifier of the experiment
- param alias:
Unique identifier of the experiment
Copyright (C) 2020 Patrick K. Erdelt
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
- create_manifest_benchmarking(connection, app='', component='benchmarker', experiment='', configuration='', experimentRun='', client='1', parallelism=1, alias='', num_pods=1)
Creates a job template for the benchmarker. This sets meta data in the template and ENV. This sets some settings specific to YCSB.
- Parameters:
app – app the job belongs to
component – Component, for example sut or monitoring
experiment – Unique identifier of the experiment
configuration – Name of the dbms configuration
client – Number of benchmarker if there is a sequence of benchmarkers
parallelism – Number of parallel pods in job
alias – Alias name of the dbms
- Returns:
Name of file in YAML format containing the benchmarker job
- class bexhoma.configurations.yugabytedb(experiment, docker=None, configuration='', script=None, alias=None, num_experiment_to_apply=None, clients=[1], dialect='', worker=0, dockerimage='')
Bases:
default
- Date:
2022-10-01
- Version:
0.6.0
- Authors:
Patrick K. Erdelt
Class for managing an DBMS configuation. This is plugged into an experiment object. This class contains specific settings for a YugabyteDB installation. This is handled outside of bexhoma with the official helm chart. The service name is fixed to be “yb-tserver-service”
- param experiment:
Unique identifier of the experiment
- param docker:
Name of the Docker image
- param configuration:
Name of the configuration
- param script:
Unique identifier of the experiment
- param alias:
Unique identifier of the experiment
Copyright (C) 2020 Patrick K. Erdelt
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
- get_service_sut(configuration)
Returns the same of the service where to connect to the SUT. This in general is the name of the service of the deployed component. For SUT, that require a component that is not controlled by bexhoma, this may be overwritten. Here, always “yb-tserver-service” is returned.
- Parameters:
configuration – name of the configuration
- Returns:
name of the configuration’s sut’s service