Hi,

I'm just clueless with one particular behavior of the readlines
function. I've written a sample program that illustrates this "prehaps
bug" I'm encountering.

The box I used for this is an AMD Sempron 2800+ with 256 Mb of RAM :
- When run on this standard etch box as a cgi script in apache2, it
runs in less than a second.
- When run in a vserver guest on this standard etch box from the
commandline, it runs in less than a second.

When run in a vserver guest on this standard etch box as a cgi script
in apache2, it takes 7 seconds to complete! During this time, CPU
usage is 100%.

A friend of mine cannot reproduce on a Gentoo box with a similar
setup. Updating vserver and the kernel to the latest version does not
fix the problem. Using a brand new vserver (using newvserver and
aptitude install apache2, with standard conffiles) does not fix the
issue.

I've narrowed the problem to the readlines() function.

Questions arise from this :
- can I narrow it better than readlines(), perhaps in C/C++ ?
- is this apache2's or vserver's fault although similar perl or php
programs (i.e. that read input) do not have the same problem?
- any ideas, advices on all this?

Thanks in advance,

Alexandre

So, I finally solved my problem[1].

Darcsweb was slow under vserver because python dup2 is slow when
ulimit -H -n is high : closing all those fd's in a python loop is
slow, see Lib/popen2.py in the python source that says :
for i in xrange(3, MAXFD):
try:
os.close(i)

And in a vserver, the default ulimit -H -n which is RLIMIT_NOFILE is
1024^2. This means that MAXFD is also 1024^2 and that the loop is
long.

This does not happen on a Gentoo box because the gentoo apache2
initscript does not use apache2ctl whereas debian does. And because of
this magic line in /usr/sbin/apache2ctl :
ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`"
soft limits become hard and apache gains 1024^2 max fd's.

Thanks to the good guys at #vserver irc channel, I fixed my slowness doing :
echo 1024 >/etc/vservers/<guest>/ulimits/nofile.hard

I still do not know where this 1024 on the host or this 1024^2 on the
guest come from, but my problem is fixed.

Cheers everybody,

Alexandre

[1] http://lists.debian.org/debian-user/.../msg02688.html


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org