[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(no subject)
From: |
root |
Subject: |
(no subject) |
Date: |
Mon, 13 Aug 2001 05:26:27 -0400 |
>From address@hidden Thu Feb 15 01:28:16 2001
>Return-Path: <address@hidden>
Received: from fencepost.gnu.org (address@hidden [199.232.76.164])
by gateway.camelot.jp (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id
BAA24053
for <address@hidden>; Thu, 15 Feb 2001 01:28:14 +0900
Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org)
by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
id 14T4iv-0005pk-00; Wed, 14 Feb 2001 11:24:09 -0500
Received: from mimesweeper2.cableol.net ([194.168.3.10]
helo=mast-dc0-sm02.private.ntl.com)
by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
id 14T4hZ-0005in-00
for <address@hidden>; Wed, 14 Feb 2001 11:22:45 -0500
Received: from mast-dc0-se03.private.ntl.com (unverified) by
mast-dc0-sm02.private.ntl.com
(Content Technologies SMTPRS 4.1.5) with ESMTP id <address@hidden> for
<address@hidden>;
Wed, 14 Feb 2001 16:22:41 +0000
Received: by mast-dc0-se03.private.ntl.com with Internet Mail Service
(5.5.2653.19)
id <15FL5BWH>; Wed, 14 Feb 2001 16:22:40 -0000
Message-ID: <address@hidden>
From: address@hidden
To: address@hidden
Cc: address@hidden
Subject: pserver causes slow serialization
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: address@hidden
Errors-To: address@hidden
X-BeenThere: address@hidden
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
<mailto:address@hidden>
List-Id: Announcements and discussions for the CVS version control system
<info-cvs.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/info-cvs>,
<mailto:address@hidden>
List-Archive: <http://mail.gnu.org/pipermail/info-cvs/>
Date: Wed, 14 Feb 2001 16:22:29 -0000
Status: O
Content-Length: 5699
Lines: 162
First I'm forced to use outlook .. so profuse apologies before I even start
:-)
One of 'my users :-)' has complained that cvs commits from his emacs session
are very slow.
We use 'pserver' to access the repository. I use emacs locally and have not
noticed this behaviour, time
to investigate:
We have lines like:
^com/ntl ( date; cat ; ($CVSROOT/bin/tedcheckin com/ntl %{s V v})&)
>> $CVSROOT/CVSROOT/updatelog 2>&1
in loginfo. This causes the script 'tedcheckin' to run whenever a file is
checked in (it does a rebuild)
since I don't want to rebuild files one at a time as each is checked-in I
have some script magic in the
background that waits around for 30 seconds to see if there is anything else
coming and batched it up.
Now I'm pretty careful to ensure I don't cause the various cvs command to
simply wait for me to finish, but
none the less if 'my user' checks in 3 files, they go in at a rate of one
every 30 seconds. Now the
important parts of tedchekin are (at end):
echo "About to do lastman cmd `date`"
nohup lastman ${SOURCE}/${module}/.touch 30 "dobuild ${module}" <
/dev/null &
echo "Done lastman cmd `date`"
exit 0
At which point I'm expecting the pserver to exit and the client can do the
next commit. But NO the
client waits the 30 seconds that 'lastman' takes to run before the pserver
exits. Looking at the source
I'm thinking that the parent part of the cvs-pserver is not wait(2)ing for
it's child until it see the
pipes closed. To that end I've done various thing with redirecting
stdin/stdout/stderr to no avail. lastman starts:
exec >> /tmp/$$.log 2>&1
Tracing via ps(1) we get:
$ date ; ps -fu priorc
Wednesday February 14 15:58:01 GMT 2001
UID PID PPID C STIME TTY TIME CMD
# All quiet ...
$ date ; ps -fu priorc
Wednesday February 14 15:58:02 GMT 2001
UID PID PPID C STIME TTY TIME CMD
priorc 3784 1 0 15:58:02 ? 0:00 sh -c ( date; cat ;
(/users/cvsroot/bin/tedcheckin com/ntl 'com/ntl/toys/htmlut
priorc 3774 184 0 15:58:01 ? 0:00 cvs
--allow-root=/users/cvsroot pserver
priorc 3785 3784 0 15:58:02 ? 0:00 sleep 2
priorc 3775 3774 0 0:00 <defunct>
# Sometimes that defunct shows as "cvs --allow .." Why don't 3774 clean up
his dead child? Waiting on IO?
$ date ; ps -fu priorc
Wednesday February 14 15:58:04 GMT 2001
UID PID PPID C STIME TTY TIME CMD
priorc 3784 1 0 15:58:02 ? 0:00 sh -c ( date; cat ;
(/users/cvsroot/bin/tedcheckin com/ntl 'com/ntl/toys/htmlut
priorc 3774 184 0 15:58:01 ? 0:00 cvs
--allow-root=/users/cvsroot pserver
priorc 3785 3784 0 15:58:02 ? 0:00 sleep 2
priorc 3775 3774 0 0:00 <defunct>
# 2 seconds nearly up ...
$ date ; ps -fu priorc
Wednesday February 14 15:58:05 GMT 2001
UID PID PPID C STIME TTY TIME CMD
priorc 3784 1 0 15:58:02 ? 0:00 sh -c ( date; cat ;
(/users/cvsroot/bin/tedcheckin com/ntl 'com/ntl/toys/htmlut
priorc 3774 184 0 15:58:01 ? 0:00 cvs
--allow-root=/users/cvsroot pserver
priorc 3775 3774 0 0:00 <defunct>
# ...
$ date ; ps -fu priorc
Wednesday February 14 15:58:06 GMT 2001
UID PID PPID C STIME TTY TIME CMD
priorc 3803 3797 0 15:58:05 ? 0:00 sleep 30
priorc 3774 184 0 15:58:01 ? 0:00 cvs
--allow-root=/users/cvsroot pserver
priorc 3797 1 0 15:58:05 ? 0:00 /bin/ksh
/users/cvsroot/bin/lastman /users/projects/src/com/ntl/.touch 30 dobui
priorc 3775 3774 0 0:00 <defunct>
# OK lastman is running (and asleep) we must have closed stdout and stderr,
stdin was closed already.
$ date ; ps -fu priorc
Wednesday February 14 15:58:08 GMT 2001
UID PID PPID C STIME TTY TIME CMD
priorc 3803 3797 0 15:58:05 ? 0:00 sleep 30
priorc 3774 184 0 15:58:01 ? 0:00 cvs
--allow-root=/users/cvsroot pserver
priorc 3797 1 0 15:58:05 ? 0:00 /bin/ksh
/users/cvsroot/bin/lastman /users/projects/src/com/ntl/.touch 30 dobui
priorc 3775 3774 0 0:00 <defunct>
# So 3774 ... what are you waiting for? Your (direct) children are dead, the
0,1 and 2 are closed. reap that dead
child and die yourself!
$ date ; ps -fu priorc
Wednesday February 14 15:58:11 GMT 2001
UID PID PPID C STIME TTY TIME CMD
priorc 3803 3797 0 15:58:05 ? 0:00 sleep 30
priorc 3774 184 0 15:58:01 ? 0:00 cvs
--allow-root=/users/cvsroot pserver
priorc 3797 1 0 15:58:05 ? 0:00 /bin/ksh
/users/cvsroot/bin/lastman /users/projects/src/com/ntl/.touch 30 dobui
priorc 3775 3774 0 0:00 <defunct>
# ...I'm guessing there is another open FD here? Would I be right?
$ date ; ps -fu priorc
Wednesday February 14 15:58:21 GMT 2001
UID PID PPID C STIME TTY TIME CMD
priorc 3803 3797 0 15:58:05 ? 0:00 sleep 30
priorc 3774 184 0 15:58:01 ? 0:00 cvs
--allow-root=/users/cvsroot pserver
priorc 3797 1 0 15:58:05 ? 0:00 /bin/ksh
/users/cvsroot/bin/lastman /users/projects/src/com/ntl/.touch 30 dobui
priorc 3775 3774 0 0:00 <defunct>
# ...
$ date ; ps -fu priorc
Wednesday February 14 15:58:39 GMT 2001
UID PID PPID C STIME TTY TIME CMD
# Ah! time is up?! So the tidy up of lastman was enough to free things up.
His IO was closed, his parent was dead. The
only tidy up I can think affects this would be other open FD.
--
Graeme
_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs
- (no subject), (continued)
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject),
root <=
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), root, 2001/08/13
- (no subject), Χριστόφορος Χριστοφοράτος, 2001/08/17
- (no subject), chrisc, 2001/08/22
- (no subject), xinhui, 2001/08/28