|
Occasionally we get in Sybase 10 the Message "All active database threads are blocked" (at Sybase 16 no errors) Multiprogramming-Level is at I have read that there is a thread-deadlock. others are all waiting...and no free threads are avalible http://dcx.sap.com/index.html#1001/en/dbugen10/ug-deadlock.html Is it a possible solution increase the multiprogramming-level from 20 up to 30? Is there a link between Sybase threads and CPU threads? (busy core or busy CPU = busy Database?) |
Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 15 Mar '16, 06:33
question was seen: 1,636 times
last updated: 15 Mar '16, 11:25
at what - the default (20), I guess?
The database engine's "worker threads" do not correspond to OS threads (at least not in Windows and Linux), they are implemented there as so-called "fibers" (i.e. "lightweight threads").
If such thread deadlock is a rare situation, I would give -gn 30 (or the like) a try. However, if it is a result of inproper design (say, "too long" transactions, race conditions and the like), increasing -gn usually will not help...
Volker's suggestion "jack up gn and see if still breaks" is the simplest and easiest approach.
If it doesn't work, you might find Foxhound to be of assistance.
In addition to what Volker said, the default maximum number of workers is different in 10 and 16. This could explain why you aren't seeing the issue on 16.
In 16 the default for -gn is 20, but the number of workers will dynamically grow up to 80 (-gnh) if needed. In 16 we always try to adjust the worker count up before throwing this error.
There are also several known bugs in version 10 that are fixed in versions 12 and later. In particular, there is one that can leave worker threads 'abandoned' so they are occupied but doing no work. This occurs when intra-query parallelism is enabled (max_query_tasks != 1) and is more likely to occur when the machine has lots of cores.
I'd try increasing the gn value and see what happens.
HTH