FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-10-2010, 12:38 AM
Dallas Clement
 
Default Slow signal delivery to server process with heavy I/O

Hi All,

I've noticed that asynchronous signals such as SIGINT, SIGTERM etc are
delivered to my process long after the signal is sent if the receiving
process is handling lots of I/O. My process is a multi-threaded web
server. It's got one thread waiting on 'select' to accept incoming
connections and a thread pool which reads the data with 'recv'.

When I batter the web server with incoming traffic and I try to
shutdown the server by sending a SIGINT or SIGTERM, I have observed
that the web server finishes handling the incoming traffic before the
kernel dispatches the signal to the process. It appears that the
'select' and 'recv' calls are getting highest priority with regard to
scheduling.

I realize this test may appear unnatural and is perhaps unrealistic,
but I would like to be able to shutdown my server gracefully within a
reasonable amount of time, no matter what kind of load it is handling.
Don't want to have to wait several minutes for my signals to get
handled under heavy load. Could someone please explain why signal
delivery is slow under these conditions?

Thanks in advance,

Dallas


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikXNKtEkIRi-BbDkY6lVl8upw3EjkCW7kmzHneY@mail.gmail.com">http://lists.debian.org/AANLkTikXNKtEkIRi-BbDkY6lVl8upw3EjkCW7kmzHneY@mail.gmail.com
 
Old 07-10-2010, 09:33 AM
Stan Hoeppner
 
Default Slow signal delivery to server process with heavy I/O

Dallas Clement put forth on 7/9/2010 7:38 PM:

> I realize this test may appear unnatural and is perhaps unrealistic,
> but I would like to be able to shutdown my server gracefully within a
> reasonable amount of time, no matter what kind of load it is handling.
> Don't want to have to wait several minutes for my signals to get
> handled under heavy load. Could someone please explain why signal
> delivery is slow under these conditions?

Wrong list Dallas. Try the devs list: debian-devel@lists.debian.org

--
Stan


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C383E6D.2070204@hardwarefreak.com">http://lists.debian.org/4C383E6D.2070204@hardwarefreak.com
 
Old 07-10-2010, 10:59 PM
Dallas Clement
 
Default Slow signal delivery to server process with heavy I/O

Hi All,

I've noticed that asynchronous signals such as SIGINT, SIGTERM etc are
delivered to my process long after the signal is sent if the receiving
process is handling lots of I/O. My process is a multi-threaded web
server. It's got one thread waiting on 'select' to accept incoming
connections and a thread pool which reads the data with 'recv'.

When I batter the web server with incoming traffic and I try to
shutdown the server by sending a SIGINT or SIGTERM, I have observed
that the web server finishes handling the incoming traffic before the
kernel dispatches the signal to the process. It appears that the
'select' and 'recv' calls are getting highest priority with regard to
scheduling.

I realize this test may appear unnatural and is perhaps unrealistic,
but I would like to be able to shutdown my server gracefully within a
reasonable amount of time, no matter what kind of load it is handling.
Don't want to have to wait several minutes for my signals to get
handled under heavy load. Could someone please explain why signal
delivery is slow under these conditions?

Thanks in advance,

Dallas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTilGgIesK7YGgZ-ujpJE3EPm8EL5H8orMH4XS66H@mail.gmail.com">http://lists.debian.org/AANLkTilGgIesK7YGgZ-ujpJE3EPm8EL5H8orMH4XS66H@mail.gmail.com
 
Old 07-10-2010, 11:13 PM
Ben Hutchings
 
Default Slow signal delivery to server process with heavy I/O

On Sat, 2010-07-10 at 17:59 -0500, Dallas Clement wrote:
> Hi All,
>
> I've noticed that asynchronous signals such as SIGINT, SIGTERM etc are
> delivered to my process long after the signal is sent if the receiving
> process is handling lots of I/O. My process is a multi-threaded web
> server. It's got one thread waiting on 'select' to accept incoming
> connections and a thread pool which reads the data with 'recv'.
>
> When I batter the web server with incoming traffic and I try to
> shutdown the server by sending a SIGINT or SIGTERM, I have observed
> that the web server finishes handling the incoming traffic before the
> kernel dispatches the signal to the process. It appears that the
> 'select' and 'recv' calls are getting highest priority with regard to
> scheduling.
[...]

A signal sent to a multithreaded process will be delivered to one of its
threads, and unless you specifically mask signals then it could be
delivered to any of them. You can either use signal masking to ensure
that only the dispatcher thread receives these signals, or have the
signal handler wake the dispatcher by writing to a control pipe included
in the select().

Anyway, you are asking on the wrong list. This is about development of
the Debian system, not development of programs using Debian.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 

Thread Tools




All times are GMT. The time now is 08:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org