Internal warning: Request task 62 dispatch took 13 seconds

[Former Member]

Internal warning: Request task 62 dispatch took 13 seconds Seeing this type of message in an ASA 12 server.

Does this mean that it took 13 seconds to execute the query or that it took 13 seconds before the query could be executed?

If it is the time it took before the query could start executing, what can I do to eliminate or reduce this time?

Command line to start the server is: -z -c 95P -os 1M -o c:EMRdatabaseconsole_log.txt -x tcpip -n emrmpg c:EMRdatabaseemr.db

Excerpts from the log:

11/07 20:05:26. SQL Anywhere Network Server Version 12.0.1.3152
11/07 20:05:26. OEM Authenticated Edition, licensed only for use with authenticated OEM applications.
11/07 20:05:26. Connection limit (licensed seats): 200
11/07 20:05:26. Processors detected: 1 (containing 4 logical processors)
11/07 20:05:26. Maximum number of physical processors the server will use: 1
11/07 20:05:26. Running Windows 2008R2 Build 7601 Service Pack 1 on X86_64
11/07 20:05:26. Server built for X86_64 processor architecture
11/07 20:05:28. 77694908K of memory used for caching
11/07 20:05:28. Minimum cache size: 77694908K, maximum cache size: 77699052K
11/07 20:05:28. Using a maximum page size of 4096 bytes
11/07 20:05:28. Multiprogramming level: minimum:4, current:20, maximum:80
11/07 20:05:28. Automatic tuning of multiprogramming level is enabled

Server is using all 4 CPUs, total memory is 79871 MB.

Alex

[Former Member]

It means that a request took a total of 13 seconds to execute from start to finish. This warning is generated from the SQL Anywhere task scheduler. The task scheduler monitors execution of tasks and outputs this warning whenever a task takes more than 10 second to execute without context switching.

If you see this message once in a while, then I wouldn't worry about it. If you see it frequently then you might be able to use application profiling to find the SQL statement that is taking long to execute. You will need to correlate the application profiling information with the time the message was displayed in the log in order to find the offending statement. Once you have the SQL statement then please open a bug report with that repro.

[Former Member]

When you say 'Context switching', do you mean that the task ran w/o any delays due to I/O or other interrupts?

We see this from 4-20 times per day.

[Former Member]

I think he means that any time when the task is "swapped out" is not counted.

[Former Member]

Yes. Blocking on I/O or waiting for other database locks held by other connections automatically causes a task to context switch. This warning will not count time spent blocking on I/O or locks. In other words, this warning says that a task was able to run for 13 seconds without sharing the CPU with other tasks in the server.

Now the side affect of this is that there will be a slight performance degradation by not allowing other tasks to execute or share the CPU with this current task. Unfortunately there is nothing you can do at your end to prevent this warning. It would be help if you can figure out the SQL statement that is causing it so that we can try to find out why such query is not giving up or yielding the CPU for other tasks in the system.