cancel
Showing results for 
Search instead for 
Did you mean: 

ASA16 vs ASA11 thread counts

Former Member
0 Kudos

In ASA11 we had the thread count set to 30 in an installation with approx. 1300 db connections.  Monitoring the active vs unscheduled requests we rarely saw the active go over 20 and unscheduled, when they rarely happened, were always below 10.

Install ASA16 on new server and rebuilt the db, and removed the thread count option on the server service as 16 is supposed to handle this internally. Now monitoring active and unscheduled I see anywhere from 20 to a high of 81 active and the unscheduled range from 30 to over 500.

Has anyone else seen the same issue, should I turn off the auto-threading option that is on by default in ASA16?

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

loading the latest ebf resolved the problem.  The thread counts are now back down to what they were when the db was running on sybase 11.

Former Member
0 Kudos

Hi Brian,

Have you opened an incident with SAP? The description sounds like this the same case that I've been working on.

Former Member
0 Kudos

yes I did, thank you for your help.  Loading the latest ebf has resolved the issue

Former Member
0 Kudos

You're very come Brian. Could you tell me which the SQLA 16 build you experienced the issue?

Former Member
0 Kudos

version 16.0.0.2076

former_member188493
Contributor
0 Kudos

If you have the freedom to experiment, try turning off intra-query parallelism...

SET OPTION PUBLIC.MAX_QUERY_TASKS = '1';

If you want to do some investigation beforehand, have a look for the occasional runaway connection that uses up all the processors by starting a whole bunch of "INT: EXCHANGE" chil... to do some heavy parallel processing.

That may or may not be the problem... but 500 unscheduled requests is an astronomically high number, probable evidence of a nasty bottleneck [ insert Foxhound pitch here :]

(Caveat: High numbers of unscheduled requests are not always cause for alarm in themselves, if the latency is otherwise low and the throughput high... it's like high blood pressure, a warning to investigate further.)

Dedicated servers with steady heavy load from large numbers of busy OLTP connections may not need features like dynamic cache sizing, automatic tuning of the mulitprogramming level and intra-query parallelism... they are primarily designed for changing workloads and database servers that must share a computer with other processes.

former_member207653
Active Participant
0 Kudos

http://dcx.sap.com/index.html#sa160/en/dbadmin/da-running-configure-auto-tuning.html

http://dcx.sap.com/index.html#sa160/en/dbadmin/running-s-3713576.html

Hi Brian,

How many logical processors have you?

Is it a standalone server?

Is it  a mirroring server?

What is the SQL Anywhere 16 build number (dbeng16 -v)?

What are the switches used to run dbsrv16?

You can test disabling dynamic multiprogramming level and setting a minimum and maximum multiprogramming level.