Child processes: The sandbox is blocked from spawning child processes. For example, the non-customizable Python or R package. The unique folder provides access to the image/package that matches the sandbox's type. Disk: A sandbox has a unique and independent directory attached to it. Reaching the limit results in termination of the sandbox, and a query execution error. Memory: The maximum amount of RAM a sandbox can consume of its host's RAM is limited (default is 20GB). When the limit is reached, the sandbox's CPU use is throttled, but execution continues. 
CPU: The maximum rate of CPU a sandbox can consume of its host's processors is limited (default is 50%). A sandbox can't interact with another sandbox. Network: A sandbox can't interact with any resource on the virtual machine (VM) or outside of it. Requests that are made when there's no available sandbox will be throttled. Number of sandboxes per node: The number of sandboxes per node is limited. Some of the parameters can be controlled using a cluster-level sandbox policy, for each kind of sandbox. New sandbox allocation could take up to 10-15 seconds per sandbox, depending on the SKU and available resources on the data node. If there are no pre-allocated sandboxes available to serve a query operator, it will be throttled until new sandboxes are available. Once a sandbox is used, a new one is automatically made available to replace it. Each node maintains a predefined number of sandboxes that are ready for running incoming requests. When a node is restarted, for example, as part of a service upgrade, all running sandboxes on it are disposed of. 
This means that the first execution of a plugin that uses sandboxes on a node will include a short warm-up period. Sandboxes are lazily initialized on a node, the first time a query requires a sandbox for its execution. A sandbox is only used for a single run, isn't shared across multiple runs, and is disposed of once that run completes. A sandboxed query operator may use one or more sandboxes for its execution. For more information on hyper-threaded VM sizes, see Virtual machine sizes. 
Hyper-threading is disabled for hyper-threaded VM sizes when sandboxes are enabled. This affects the cluster's data capacity, and may affect the cost of the cluster. The estimated size is 20 GB, that is roughly 2.5% the SSD capacity of a D14_v2 VM, for example, or 0.7% the SSD capacity of a L16_v1 VM. The required packages (images) for running the sandboxes are deployed to each of the Data Engine's nodes, and require dedicated SSD space to run. 
In this case, stop and start the cluster.
If encryption is enabled on the data engine before encryption at host is adopted as the default for supported VM sizes, the data engine may not support both features side by side. For more information on supported VM sizes, see Virtual machine sizes. Data engines that enable both disk encryption and sandboxes features must run on a VM size that supports encryption at host. Sandboxes are run locally (meaning, processing is done close to the data), with no extra latency for remote calls. Kusto can run sandboxes for specific flows that must be run in a secure and isolated environment.Įxamples of these flows are user-defined scripts that run using the Python plugin or the R plugin.
0 kommentar(er)
