Hi Dmitri, > -----Original Message----- > From: lds [mailto:[EMAIL PROTECTED]] > Sent: Donnerstag, 16. Januar 2003 04:04 > To: [EMAIL PROTECTED] > Subject: I/O performance and SAP DB threading model (for 7.3 version) > > ... > As I found out the SAP DB threading model > presumes a combination of the native threads and coroutines. correct if _USE_THRD_FOR_TSK is not set to YES. If it is set, instead a group of threads in used instead of coroutines. A thread group means all 'system scope' threads where if a thread decides to call the dispatcher and gets informed it will resume the next active thread and suspend itself. This is 'C++ exception save' where coroutine in combination with C++ exception are not defined (as is longjmp in combination with C++ exception). Indeed without further action C++ exceptions do not work correctly in a coroutine context if the another coroutine is called during stack unwinding... The threads containing either 'thread groups' or 'coroutines' (or 'fibers' in Win32 context...) are called User Kernel Threads (UKT). The number of UKTs created for user tasks is controlled by MAXCPU. The I/O activity is handled by other native threads, so called device threads. The performance degradation (...for the task switch code...) if using threads instead of coroutines is severe. But it hurts only if the number of task switches is really high in the application. Nevertheless we are trying to reintroduce coroutines into 7.4 for those platforms where a workaround for a combination of coroutines and C++ exceptions is found.
> Datawriter task is implemented as a coroutine. Is the actual physical writing > to the disk made by the datawriter task or it spawns the native threads? Spawning would consume to much time. The Tasks that does I/O either detect its alone in its UKT and does the I/O as a blocking call or it queues the request into a device thread. Instead of spawing the device threads on demand, they are created during startup phase for each devspace and during attach for each backup device. Each of these threads have a request queue, and are informed about incoming I/O requests via a semaphore. On Win32 I/O completion ports are used if possible and a I/O completion worker resumes the taks waiting for I/O to complete. > In the first case it means that while synchronous I/O operation is > performed all other activities are stopped. All datawriters are normally combined in a UKT, so they will always use the device threads for I/O. > Is there any settings besides _USE_THRD_FOR_TSK > (which I don't want to alter as dispatching of the coroutines > generally much faster than pthreads) that controls the threading model behaviour? The threading model is controlled by the 'TASKCLUSTER' parameters, which describes how much UKTs are created and how much and of which sort of taks are combined within them. The _IOPROCS_PER_DEV parameters (old name from times where SAPDB was a multiprocess application) defines the number of I/O threads spawned per devspace. NOTE: As for coroutines see my note above... Current 7.4 release do not support any coroutines anymore due to C++ exception handling problems. You want even find the '_USE_THRD_FOR_TSK' parameter in 7.4. But the performance effect is not that dramatic as it sounds. > Is the parameter _USE_IOPROCS_ONLY ensures that all the I/O > operations performed asynchronously if it sets to true? > It enforces using the I/O thread even if a task detected, that it is running alone in its UKT. Unfortunatly asynchronous I/O on UNIX is good for non-multithreaded processes, but not that good for a multithreaded program since handling the identification of completed I/O the number of outstanding I/O requests It would be good to have a I/O completion port at least on UNIX, but discussions with Linus i read were not that promissing ;-) Especially for the number of I/O Threads per devspace is defined with _IOPROCS_PER_DEV which defaults to 2. That means two I/O threads doing blocking I/O on a single device in parallel. This is a good parameter to tune I/O performance. CU jrg _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
