Most of us are aware of AMP worker tasks, and some of us are even obsessive about not running out of this finite resource. But that’s on the AMP. What about the tasks supporting user work on the parsing engine (PE)? Should we be just as vigilant about what’s happening with tasks at the PE level?
Not really. Here’s why.
Each parsing engine has a pool of tasks called SQLDriver tasks that perform PE activities. There are 128 of these tasks per PE, and similar to AMP worker tasks (AWT), they are initiated at startup time and stay active until the database shuts down.
You do not need to be concerned about running out of SQLDriver tasks, as only one will ever be used by a single session, and a PE is limited to 120 sessions. There are a few additional SQLDriver tasks (8 more than the number of sessions allowed) for special internal purposes. I am not aware of any issues involved in running out of SQLDriver tasks, so you can cross them off your monitoring list.
There a couple of interesting differences between AWTs and SQLDriver tasks I want to share with you:
When you look at AMP CPU seconds for a request you are seeing an accumulation across all AMPs. Because AWTs may be accumulating time on different CPUs in parallel, the wall-clock time for getting the AMP work could be less than the reported CPU seconds.
On the other hand, PE CPU seconds usually take a longer amount of wall-clock time to consume than their reported CPU seconds because one SQLDriver task on a single CPU on one node is doing all the PE work.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.