<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.dafne.bi-services.sk/index.php?action=history&amp;feed=atom&amp;title=Resource_management</id>
	<title>Resource management - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.dafne.bi-services.sk/index.php?action=history&amp;feed=atom&amp;title=Resource_management"/>
	<link rel="alternate" type="text/html" href="https://wiki.dafne.bi-services.sk/index.php?title=Resource_management&amp;action=history"/>
	<updated>2026-10-23T19:25:57Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.34.4</generator>
	<entry>
		<id>https://wiki.dafne.bi-services.sk/index.php?title=Resource_management&amp;diff=39&amp;oldid=prev</id>
		<title>Dafne: Created page with &quot;== Managing System Load and Parallel Processing ==    When processing a large number of tasks, system resources may become temporarily overloaded. In database environments, th...&quot;</title>
		<link rel="alternate" type="text/html" href="https://wiki.dafne.bi-services.sk/index.php?title=Resource_management&amp;diff=39&amp;oldid=prev"/>
		<updated>2025-03-25T18:45:09Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;== Managing System Load and Parallel Processing ==    When processing a large number of tasks, system resources may become temporarily overloaded. In database environments, th...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;== Managing System Load and Parallel Processing ==  &lt;br /&gt;
&lt;br /&gt;
When processing a large number of tasks, system resources may become temporarily overloaded. In database environments, this typically occurs due to excessive I/O operations, insufficient memory, or high CPU usage. Overload is defined as a situation where a combination of concurrently running tasks completes slower than if they were executed sequentially or with a lower degree of parallelism.  &lt;br /&gt;
&lt;br /&gt;
Overloading is generally undesirable and should be identified using database server and operating system monitoring tools. By continuously analyzing execution patterns, it is possible to determine which tasks require exclusive execution or should run only when no other high-resource tasks are active.  &lt;br /&gt;
&lt;br /&gt;
The **DWFC framework** provides several tools to manage system load:  &lt;br /&gt;
&lt;br /&gt;
* **Global parallelism limit settings**  &lt;br /&gt;
* **Parallelism limits at the group/connection level**  &lt;br /&gt;
* **Load limits at the group/connection level**  &lt;br /&gt;
* **Exclusive dependencies between tasks**  &lt;br /&gt;
&lt;br /&gt;
These methods can be combined for flexible workload management.  &lt;br /&gt;
&lt;br /&gt;
== Global Parallelism Limit ==  &lt;br /&gt;
&lt;br /&gt;
The global parallelism limit is considered every time a task attempts to start. The system evaluates the number of currently running tasks and, if the global limit is reached, prevents additional tasks from starting until one of the active tasks completes—regardless of whether it finishes successfully or fails.  &lt;br /&gt;
&lt;br /&gt;
This limit is configured in the application administration panel under **Settings &amp;gt; ParallelLimit**. The current value is displayed on the right side of the screen, and administrators can adjust it as needed. After confirming the change, the new limit becomes active.  &lt;br /&gt;
&lt;br /&gt;
This is the simplest method of workload management and is suitable for environments where tasks impose a similar level of load on system resources.  &lt;br /&gt;
&lt;br /&gt;
== Parallelism Limit at the Group/Connection Level ==  &lt;br /&gt;
&lt;br /&gt;
A more refined method of managing workload is by setting parallelism limits for specific task groups or database connections. These limits define the maximum number of tasks that can run simultaneously within a group or connection.  &lt;br /&gt;
&lt;br /&gt;
Each group or connection limit is configured independently. If both a group-level and a connection-level limit apply to a task, the stricter limit is enforced.  &lt;br /&gt;
&lt;br /&gt;
For example:  &lt;br /&gt;
* A task belongs to a group with a parallelism limit of 5, where 3 tasks are currently running.  &lt;br /&gt;
* The same task is assigned to a connection with a parallelism limit of 6, where all 6 available slots are occupied.  &lt;br /&gt;
* Since the connection limit is reached, the task will not start, even though the group limit allows it.  &lt;br /&gt;
&lt;br /&gt;
In such cases, the system evaluates other tasks based on priority (see [[Task Prioritization]]).  &lt;br /&gt;
&lt;br /&gt;
This method is suitable for moderately complex workloads where resource bottlenecks are infrequent or as an initial step before implementing more advanced load management strategies.  &lt;br /&gt;
&lt;br /&gt;
== Load Limit at the Group/Connection Level ==  &lt;br /&gt;
&lt;br /&gt;
If tasks impose varying loads on system resources, a **weight value** can be assigned to each task. This is configured in the task&amp;#039;s **Advanced Settings &amp;gt; Weight** field.  &lt;br /&gt;
&lt;br /&gt;
The weight represents the proportion of total system load consumed by a task within a group or connection. For example:  &lt;br /&gt;
* A task has a weight of 20, and the total allowed load for its connection is set to 100.  &lt;br /&gt;
* This means the task consumes 20% of the total available resources for that connection.  &lt;br /&gt;
&lt;br /&gt;
Weight values are manually assigned by administrators and do not automatically adjust based on actual resource consumption. If a task&amp;#039;s resource demands change significantly, its weight must be manually updated.  &lt;br /&gt;
&lt;br /&gt;
Before launching a task, the system evaluates the cumulative load of currently running tasks. If running the new task would exceed the defined limit, it is postponed, and other tasks are considered based on priority (see [[Task Prioritization]]).  &lt;br /&gt;
&lt;br /&gt;
Typical weight assignments in a Data Warehouse (DWH) environment can be estimated based on the number of records processed:  &lt;br /&gt;
&lt;br /&gt;
* Tables with **≤1,000 records**: 1–5% load  &lt;br /&gt;
* Tables with **≤100,000 records**: 10–30% load  &lt;br /&gt;
* Larger tables: Require individual evaluation, typically set around 40%  &lt;br /&gt;
&lt;br /&gt;
These estimates apply to basic ETL scenarios without complex transformations or large table joins. For more complex workflows, the load should be assessed by manually running the task and monitoring system performance.  &lt;br /&gt;
&lt;br /&gt;
== Exclusive Dependencies Between Tasks ==  &lt;br /&gt;
&lt;br /&gt;
Exclusive dependencies help prevent conflicts caused by resource contention, such as table locks. This mechanism ensures that two tasks requiring exclusive access to the same resource do not run simultaneously.  &lt;br /&gt;
&lt;br /&gt;
For example:  &lt;br /&gt;
* Two ETL tasks attempt to insert data into the same target table.  &lt;br /&gt;
* On some databases, this may cause performance degradation or deadlocks.  &lt;br /&gt;
* In systems like **Sybase IQ**, simultaneous inserts can cause task failures, requiring a retry.  &lt;br /&gt;
&lt;br /&gt;
To enforce an exclusive dependency, add a dependency to a task and change its type to **Exclusive**. This ensures that the dependent task will not start until the exclusive task has completed execution.  &lt;br /&gt;
&lt;br /&gt;
---&lt;br /&gt;
&lt;br /&gt;
By effectively managing task execution limits and dependencies, DWFC optimizes system resource usage while preventing overload-related performance issues.&lt;/div&gt;</summary>
		<author><name>Dafne</name></author>
		
	</entry>
</feed>