This topic describes how to tune a sync node that runs slowly or has a significant delay between its scheduled and actual start times.
Prerequisites
Before you tune a sync node, obtain its runtime log and attributes.
For sync nodes, DataWorks provides level-1 scheduling resources and level-2 running resources.
-
Level-1 scheduling resources: Go to . Right-click the corresponding node and select More to view the node's Attribute.
-
Level-2 running resources: Go to to add and view level-2 running resources.
Background information
A sync node can run slowly for three main reasons:
-
The task starts significantly later than its scheduled time.
-
The task remains in the
WAITstate for an extended period. -
The data synchronization rate is low.
Scenario 1: Delayed start time
If you notice a large gap between the scheduled time and the actual start time, you must first obtain the runtime log and Attribute of the node. Comparing them often reveals that the start time in the Run Logs is much later than the scheduled time in the node's Attribute, indicating the task was delayed while waiting for scheduling resources.
Problem example
-
In Operation Center, go to . Right-click the corresponding node and select More. In the node's Attribute, you find that the scheduled time is 00:00, but the task actually started at 00:29. This suggests the delay was caused by waiting for scheduling resources.
-
Go to the page. Right-click the corresponding instance and select View Run Logs. The log shows that the task started at 00:29 and finished at 00:30, which took only one minute. This confirms that the task execution itself is not the problem.
Solution
-
Check whether a large number of tasks are scheduled to run at the same time in your workspace. The default resource group has limited level-1 scheduling resources. If too many tasks are scheduled to run concurrently, other tasks are queued.
-
The period from 00:00 to 02:00 is typically the peak time for business scheduling. Schedule your tasks to run during off-peak hours to avoid delays.
Scenario 2: Zero data rate during execution
When you check the runtime log, you may find that the task runs for a long time with a data rate of 0. This issue is often caused by a slow-running SQL query due to high CPU load or high network traffic on the source database. It can also be caused by pre-execution operations, such as truncate, that extend the processing time.
Problem example
-
The runtime log shows that the task ran for a long time, from 18:00 to 21:13, but the data rate remained at 0.
-
The runtime log also shows a
truncateoperation that ran from 18:00 to 21:13.
Solution
As shown in the example, the slow performance is likely caused by the truncate operation. You need to investigate why the truncate operation is slow on the source database.
Scenario 3: Low sync rate
When you check the runtime log, you see that the task is synchronizing data, but the rate is low.
Problem example
-
After you obtain the runtime log, you notice that the synchronization rate is low, at approximately 1.93 KB/s.
-
Checking the synchronization time fields, such as WaitWriterTime and WaitReaderTime, in the runtime log reveals that the WaitReaderTime is long, mainly due to waiting to read data.
Time | minDeltaGCTime | 0.000s | 0.000s , 7 records/s | Error 0 records, 0 bytes | All Task WaitWriterTime 293.585s All Task WaitReaderTime 12,428.700s | Percentage 100.00%
Solution
If the data rate is slow, identify whether the reader or the writer is the bottleneck by checking the WaitReaderTime and WaitWriterTime metrics. If the read or write process is slow, check the load on the corresponding source or destination database.