You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1997/11/04 02:28:18 UTC
[PATCH] make SVSEM default on Solaris
Running the tests (500 iterations) on a Solaris 5.0 Ultra 1-140 I get
children time-FCNTL time-SEM time-PTHREAD
5 0.068885 0.057233 0.032462
10 0.142524 0.115559 0.075708
20 0.281315 0.232055 0.147536
40 2.117779 0.454873 0.280912
80 5.255021 0.909237 0.552102
160 13.540717 1.841652 1.104325
With 1000 iterations I get
children time-FCNTL time-SEM time-PTHREAD
5 0.148968 0.103287 0.054936
10 0.257543 0.204586 0.102403
20 1.188743 0.412165 0.219451
40 3.736451 0.818037 0.449842
80 9.344190 1.659889 0.832698
160 26.522825 Failure 1.697104
That last failure is a bummer, since otherwise I would have suggested
we use SVSEM as the default on Solaris (it is actually the one I was
testing on Friday that worked reliably). But at 160x1000 I get
fielding@kiwi% time-SEM 160 1000
accept_mutex_on: No space left on device
accept_mutex_on: No space left on device
accept_mutex_on: No space left on device
accept_mutex_on: No space left on device
WTF! shared_counter != num_child * num_iter!
3.268732
which obviously means it is resource limited in some way. Hmmm, on the
other hand, that may be reasonable if we consider that the iterations
corresponds to the number of accepted connections by the child.
Crikey, if I change the test from being iteration-intensive to being
child-intensive, then PTHREADS loses bigtime with 100 iterations
(which matches our default for maximum connections/child):
children time-FCNTL time-SEM time-PTHREAD
20 0.103061 0.087116 0.082224
40 0.532066 0.168017 0.156788
80 1.192119 0.331421 0.317818
160 2.970030 0.669179 0.935610
320 9.183506 1.365706 17.751631
So, I suggest we make the following change now and maybe consider
deleting the PTHREAD code if these tests are accurate.
....Roy
Index: conf.h
===================================================================
RCS file: /export/home/cvs/apachen/src/main/conf.h,v
retrieving revision 1.150
diff -u -r1.150 conf.h
--- conf.h 1997/10/25 01:52:45 1.150
+++ conf.h 1997/11/04 00:59:03
@@ -123,12 +123,9 @@
#undef NO_SETSID
#define HAVE_SYS_RESOURCE_H
#define bzero(a,b) memset(a,0,b)
-/*#define USE_FCNTL_SERIALIZED_ACCEPT */
-/*#define USE_SYSVSEM_SERIALIZED_ACCEPT */
-#if SOLARIS2 < 250
-#define USE_FCNTL_SERIALIZED_ACCEPT
-#else
-#define USE_PTHREAD_SERIALIZED_ACCEPT
+#if !defined(USE_FCNTL_SERIALIZED_ACCEPT) && \
+ !defined(USE_PTHREAD_SERIALIZED_ACCEPT)
+#define USE_SYSVSEM_SERIALIZED_ACCEPT
#endif
#define NEED_UNION_SEMUN
#define HAVE_MMAP
Re: [PATCH] make SVSEM default on Solaris
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 3 Nov 1997, Roy T. Fielding wrote:
> That last failure is a bummer, since otherwise I would have suggested
> we use SVSEM as the default on Solaris (it is actually the one I was
> testing on Friday that worked reliably). But at 160x1000 I get
>
> fielding@kiwi% time-SEM 160 1000
> accept_mutex_on: No space left on device
> accept_mutex_on: No space left on device
> accept_mutex_on: No space left on device
> accept_mutex_on: No space left on device
> WTF! shared_counter != num_child * num_iter!
> 3.268732
>
> which obviously means it is resource limited in some way. Hmmm, on the
> other hand, that may be reasonable if we consider that the iterations
> corresponds to the number of accepted connections by the child.
Uh, if sysvsem is *known* to fail then I give -1 to switching to it. I
will +1 switching back to fcntl.
Note that sysvsem has a DoS attack -- any CGIs can snarf the semaphore and
sleep forever with it. This isn't possible if you use suexec. But in
general it's possible. This DoS isn't present with any of the other
methods... although it may be present depending on how Marc fixes flock
(hey Marc, you're working on that right?).
sysvsem also has a kill -9 resource leak ... in general I find sysvsem
lame, and only on IRIX boxes where fcntl is even more lame have I
advocated it so far.
The 320 child case is interesting. But that's an over-the-top case I
suspect, how much ram does your system have? Are you sure it didn't start
swapping for some silly reason? pthread has to allocate a page of shared
memory, which could have pushed it over the top -- solaris does silly
things sometimes with page sharing. All the solaris boxes here are doing
heavy computing or I could test myself.
Dean
Re: [PATCH] make SVSEM default on Solaris
Posted by Dean Gaudet <dg...@arctic.org>.
It occured to me that we could make sysvsem do the same signal
blocking/catching as I'm proposing for pthreads, and doing that we could
skip the SEM_UNDO and get rid of the failure. So here's timings with this
change:
[35]manganese:~/ap/apachen6/src/test% ./time-SEM 200 10000
39.912311
[36]manganese:~/ap/apachen6/src/test% ./time-PTHREAD 200 10000
12.555036
[37]manganese:~/ap/apachen6/src/test% ./time-SEM 100 10000
19.330466
[38]manganese:~/ap/apachen6/src/test% ./time-PTHREAD 100 10000
6.575176
It's still a win to do PTHREAD. This is on the single cpu ultra-1 200Mhz,
256Mb RAM running 2.5.
Oh, weird. On this 2.5 box I can run 200 children using SEM_UNDO. I
can't do that on the 2.5.1 box. Oh joy. This is seriously crazy.
Dean
Re: [PATCH] make SVSEM default on Solaris
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 3 Nov 1997, Roy T. Fielding wrote:
> fielding@kiwi% time-SEM 160 1000
> accept_mutex_on: No space left on device
> accept_mutex_on: No space left on device
> accept_mutex_on: No space left on device
> accept_mutex_on: No space left on device
> WTF! shared_counter != num_child * num_iter!
> 3.268732
>From man semop:
ENOSPC The limit on the number of individual
processes requesting an SEM_UNDO would be
exceeded.
I wonder how you tune that limit. I couldn't find anything obvious...
it's probably one of those wonderfully documented /etc/system settings.
FWIW, the limit seems to be 29 on one of the systems here. This system
is an ultra 2 with dual 167MHz chips and 640Mb of RAM running 2.5.1.
Here's some timings:
% ./time-SEM 29 10000
9.407788
% ./time-PTHREAD 29 10000
1.309625
% ./time-PTHREAD 200 10000
8.442355
I suspect there's a difference between UP and MP boxes just like there
is under IRIX, bleh.
Ok here's timings on a 2.5 system with 256Mb of RAM and a single 200Mhz
UltraSPARC:
% ./time-SEM 29 10000
4.069612
% ./time-PTHREAD 29 10000
1.687709
% ./time-PTHREAD 100 10000
6.001535
% ./time-PTHREAD 200 10000
11.638046
I dunno, I don't see the pthread problem you're seeing, that looks like
close to linear degredation for pthread. Unlike, say, fcntl:
% =1/time-FCNTL 10 10000
2.254160
% =1/time-FCNTL 30 10000
17.364744
% =1/time-FCNTL 100 10000
81.941647
Oh BTW Roy, if you're going to time fcntl then you should "cd /var/tmp"
or otherwise make sure your cwd is not NFS mounted ... 'cause that's
where the lock file will be created. I just added a printf for that.
Dean