Reko Turja wrote on Sun, Dec 02, 2007 at 12:23:15AM +0200:
> On Sat, 01 Dec 2007 23:37:32 +0200, Alexey Vlasov <[EMAIL PROTECTED]> wrote:
>
> >kernel:
> >machine i386
> >cpu I686_CPU
> >ident F1RNT1
> >
> >options PAE
>
> One very probable culprit for slowne
> > Now we also have terribly performing PostgreSQL on 8-core server. We
> > noticed the slowdown after moving PostgreSQL from 2xXeon 3.0
> > Apache+PostgreSQL server to dedicated PostgreSQL server. I collected
> > some stats (see attach) before moving to Linux.
I'm sure that some code optimiza
On Tue, 2007-12-04 at 14:11 +0100, Ivan Voras wrote:
> Robert Watson wrote:
>
> > Changing
> > locking primitives, as I mentioned in an earlier post, is a risky thing:
> > after all, it intentionally changes the timing for critical kernel data
> > structures in the file system code. I've given S
Tom Evans wrote:
On Tue, 2007-12-04 at 13:00 +0100, Ivan Voras wrote:
Krassimir Slavchev wrote:
There is another report for such problems:
http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong
Of course - FreeBSD 6.x is really bad at SMP where number of CPUs is
larger then
On Tue, 4 Dec 2007, Ivan Voras wrote:
Krassimir Slavchev wrote:
There is another report for such problems:
http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong
Of course - FreeBSD 6.x is really bad at SMP where number of CPUs is larger
then about 2 and the loads include m
Robert Watson wrote:
> Changing
> locking primitives, as I mentioned in an earlier post, is a risky thing:
> after all, it intentionally changes the timing for critical kernel data
> structures in the file system code. I've given Stephan, the author of
> the patch, a ping to ask him about this, b
On Tue, 4 Dec 2007, Krassimir Slavchev wrote:
Evidence in-hand seems to suggest that 8 core systems work very well for
most users, and reflect a significant performance increase with 7.0 over
previous FreeBSD releases.
I disagree with that. Heavily loaded Apache, MySQL, Postgres does not
wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Watson wrote:
>
> On Tue, 4 Dec 2007, Krassimir Slavchev wrote:
>
Evidence in-hand seems to suggest that 8 core systems work very well
for most users, and reflect a significant performance increase with
7.0 over previous FreeBSD
On Tue, 2007-12-04 at 13:00 +0100, Ivan Voras wrote:
> Krassimir Slavchev wrote:
>
> > There is another report for such problems:
> >
> > http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong
>
> Of course - FreeBSD 6.x is really bad at SMP where number of CPUs is
> larger then a
On Tue, 4 Dec 2007, Krassimir Slavchev wrote:
Evidence in-hand seems to suggest that 8 core systems work very well for
most users, and reflect a significant performance increase with 7.0 over
previous FreeBSD releases.
I disagree with that. Heavily loaded Apache, MySQL, Postgres does not wor
Krassimir Slavchev wrote:
> There is another report for such problems:
>
> http://blog.insidesystems.net/articles/2007/04/09/what-did-i-do-wrong
Of course - FreeBSD 6.x is really bad at SMP where number of CPUs is
larger then about 2 and the loads include much kernel work (e.g. IO,
context switc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexey Popov wrote:
> Hi
>
> Robert Watson wrote:
>> Evidence in-hand seems to suggest that 8 core systems work very well
>> for most users, and reflect a significant performance increase with
>> 7.0 over previous FreeBSD releases.
> I disagree with t
Hi
Robert Watson wrote:
Evidence in-hand seems to suggest that 8 core systems work very well for
most users, and reflect a significant performance increase with 7.0 over
previous FreeBSD releases.
I disagree with that. Heavily loaded Apache, MySQL, Postgres does not work well.
The right path
On Mon, 3 Dec 2007, Alexey Popov wrote:
Robert Watson wrote:
Is there any other FreeBSD developer who can take care of performance
problems on many-cores systems? Seems like upcoming 7-RELEASE and
6.3-RELEASE would be completely unusable for us on that kind of systems
i.e. mostly on all mod
Hi.
Robert Watson wrote:
Is there any other FreeBSD developer who can take care of performance
problems on many-cores systems? Seems like upcoming 7-RELEASE and
6.3-RELEASE would be completely unusable for us on that kind of
systems i.e. mostly on all modern hardware.
There are many FreeBSD
Antony Mawer wrote:
> Have you tried testing with different values for kern.hz? I am by no
> means an expert, but have stumbled across various postings over the past
> few years that suggest the high value (1000) used by modern (5.x+?)
> kernels can be pessimistic for some workloads...
>
> If you
Hi
Alexey Popov wrote:
Now we also have terribly performing PostgreSQL on 8-core server. We
noticed the slowdown after moving PostgreSQL from 2xXeon 3.0
Apache+PostgreSQL server to dedicated PostgreSQL server. I collected
some stats (see attach) before moving to Linux.
FYI there's top output o
On Mon, 3 Dec 2007, Alexey Popov wrote:
Mark Linimon wrote:
I used 7.0-BETA3 and it is much worse.
Ouch. A lot of systems see improvement. Thanks for trying it out. I hope
that one of the people that has been doing the actual work can now comment
(I am just an onlooker), and that you can
On 3/12/2007 8:50 PM, Alexey Popov wrote:
Hi
Alexey Popov wrote:
Now we also have terribly performing PostgreSQL on 8-core server. We
noticed the slowdown after moving PostgreSQL from 2xXeon 3.0
Apache+PostgreSQL server to dedicated PostgreSQL server. I collected
some stats (see attach) befor
Hi
Alexey Popov wrote:
Now we also have terribly performing PostgreSQL on 8-core server. We
noticed the slowdown after moving PostgreSQL from 2xXeon 3.0
Apache+PostgreSQL server to dedicated PostgreSQL server. I collected
some stats (see attach) before moving to Linux.
Sorry for the broken to
Hi
Mark Linimon wrote:
I used 7.0-BETA3 and it is much worse.
Ouch. A lot of systems see improvement. Thanks for trying it
out. I hope that one of the people that has been doing the actual
work can now comment (I am just an onlooker), and that you can be
patient in the meantime.
Unfortunatel
On Sunday 02 December 2007, Alexey Vlasov wrote:
> I used 7.0-BETA3 and it is much worse.
Ouch. A lot of systems see improvement. Thanks for trying it
out. I hope that one of the people that has been doing the actual
work can now comment (I am just an onlooker), and that you can be
patient in t
On Sat, Dec 01, 2007 at 11:04:41PM +0100, Daniel Gerzo wrote:
> Please try with RELENG_7 (aka. FreeBSD 7.0-BETA3) and ULE scheduler.
I used 7.0-BETA3 and it is much worse.
ULE, w/o PAE (or with PAE)
# ./ab -n 100 -c 20 -t 30 http://somesite-freebsd.com/ab/
This is ApacheBench, Version 2.0.40-dev
> > options PAE
>
> One very probable culprit for slowness
I'd say it IS the culprit. PAE is known to decrease performance, and
this is probably 95% of the cause.
> Using _ULE might yield a bit more performance as well
Yes, in 7.0-BETA3 I'm seeing a 7% increase in performance (sysbench
w
Hello Alexey,
Saturday, December 1, 2007, 10:37:32 PM, you wrote:
> I use OS Linux on my hosting for web-servers, base for all servers is
> the same m/b S5000PAL ( SR1500), 2 quad kernel cpu Xeon E5320 or E5345,
> 8Gb RAM. I decided to install FreeBSD 6.2 i386 on one of the servers,
> and the re
On Sat, 01 Dec 2007 23:37:32 +0200, Alexey Vlasov <[EMAIL PROTECTED]> wrote:
kernel:
machine i386
cpu I686_CPU
ident F1RNT1
options PAE
One very probable culprit for slowness
options SMP
options SCHED_4BSD
Using _ULE might yield a bit
I use OS Linux on my hosting for web-servers, base for all servers is
the same m/b S5000PAL ( SR1500), 2 quad kernel cpu Xeon E5320 or E5345,
8Gb RAM. I decided to install FreeBSD 6.2 i386 on one of the servers,
To be a bit mor specific with my previous reply, in order to use SCHED_ULE
you ne
On Sun, Dec 02, 2007 at 12:37:32AM +0300, Alexey Vlasov wrote:
> I decided to install FreeBSD 6.2 i386 on one of the servers, and the
> result was totally non productive.
The 6.x series was intended to get us back to the stability that we had
had pre-SMP integration. I believe we mostly succeeded
Hi,
It seems that I'm not the only one who faced the problem that FreeBSD is
non productive on multiprocessors platforms.
I use OS Linux on my hosting for web-servers, base for all servers is
the same m/b S5000PAL ( SR1500), 2 quad kernel cpu Xeon E5320 or E5345,
8Gb RAM. I decided to install Fr
Alexey Popov wrote:
Hi
Kris Kennaway wrote:
One more patch which may or may not help is:
http://www.freebsd.org/~jhb/patches/namei_rwlock.patch
(may also require porting since it was against an older version of
7.0-CURRENT). When I have tested this in the past it was a
performance loss f
Hi
Kris Kennaway wrote:
One more patch which may or may not help is:
http://www.freebsd.org/~jhb/patches/namei_rwlock.patch
(may also require porting since it was against an older version of
7.0-CURRENT). When I have tested this in the past it was a performance
loss for reasons that I thi
Alexey Popov wrote:
Hi
Kris Kennaway wrote:
Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP
realpath_cache_size (producing 2000+ lstats per request) can handle
up to ~24 rps as opposed to max. 17 rps without your patch. %sys
never grows over %user with your patch. On the server
Joseph Koshy wrote:
Also I tried to find what else is slow in FreeBSD, I tried hwpmc as
module and in kernel, but it fails with error:
pmc: Unknown Intel CPU.
module_register_init: MOD_LOAD (hwpmc, 0x804833e0,
0x809338a0) error 78
There are patches you need to enable it on wood
Krassimir Slavchev wrote:
> That's true but if the tests are same then they can be compared.
>
>> - the code is most likely checking for changes in PHP libraries)
>
> This is not recommended for production systems.
PHP code accelerators / caches do that all the time. require_once() also
does i
> > Also I tried to find what else is slow in FreeBSD, I tried hwpmc as
> > module and in kernel, but it fails with error:
> > pmc: Unknown Intel CPU.
> > module_register_init: MOD_LOAD (hwpmc, 0x804833e0,
> > 0x809338a0) error 78
> There are patches you need to enable it on woodcr
Hi
Kris Kennaway wrote:
Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP
realpath_cache_size (producing 2000+ lstats per request) can handle
up to ~24 rps as opposed to max. 17 rps without your patch. %sys
never grows over %user with your patch. On the server with optimized
realp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ivan Voras wrote:
> On 23/11/2007, Krassimir Slavchev <[EMAIL PROTECTED]> wrote:
>
>> Would someone define what exact tests to be performed.
>> Ok, using "ab" is fine but with what parameters it is used and against
>> what, script or static html? It w
Alexey Popov wrote:
Hi.
Kris Kennaway wrote:
Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP
realpath_cache_size (producing 2000+ lstats per request) can handle
up to ~24 rps as opposed to max. 17 rps without your patch. %sys
never grows over %user with your patch. On the serve
On 23/11/2007, Krassimir Slavchev <[EMAIL PROTECTED]> wrote:
> Would someone define what exact tests to be performed.
> Ok, using "ab" is fine but with what parameters it is used and against
> what, script or static html? It will be good to have written some perl,
In this thread, it's always PHP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ivan Voras wrote:
> On 20/11/2007, Alexey Popov <[EMAIL PROTECTED]> wrote:
>
>> CPU states: 5.9% user, 0.0% nice, 81.3% system, 0.0% interrupt, 12.8% idle
>> CPU states: 82.2% user, 0.0% nice, 13.8% system, 0.0% interrupt, 4.0% idle
>
> Interes
Hi.
Kris Kennaway wrote:
Now FreeBSD 7-STABLE ULE 8-core server without optimized PHP
realpath_cache_size (producing 2000+ lstats per request) can handle up
to ~24 rps as opposed to max. 17 rps without your patch. %sys never
grows over %user with your patch. On the server with optimized
rea
On 22/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> It looks like lockmgr, and the patch should definitely have helped.
> Maybe you forgot to enable vfs.lookup_shared?
No, I haven't.
But the machine I tested it on is only 4-core; maybe it would help on
8-core machines.
Ivan Voras wrote:
On 22/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
OK, let's take a step back here. Did you obtain the lock profiling
trace and verify that you're seeing the same problem as Alexey? Can I
see the trace?
Here it is:
http://ivor
On 22/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Ivan Voras wrote:
> > Kris Kennaway wrote:
> >> OK, let's take a step back here. Did you obtain the lock profiling
> >> trace and verify that you're seeing the same problem as Alexey? Can I
> >> see the trace?
> >
> > Here it is:
> >
> >
Ivan Voras wrote:
Kris Kennaway wrote:
Ivan Voras wrote:
On 21/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Ivan Voras wrote:
Yes, but I had to verify it anyway :)
You haven't verified anything until you look at how much work the system
is doing, before and after.
I have, and it's roug
Alexey Popov wrote:
Hi.
Kris Kennaway wrote:
In the meantime there is unfortunately not a lot that can be done,
AFAICT. There is one hack that I will send you later but it is not
likely to help much. I will also think about how to track down the
cause of the contention further (the profilin
Kris Kennaway wrote:
> Ivan Voras wrote:
>> On 21/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
>>> Ivan Voras wrote:
>>
Yes, but I had to verify it anyway :)
>>> You haven't verified anything until you look at how much work the system
>>> is doing, before and after.
>>
>> I have, and it's
Hi.
Kris Kennaway wrote:
In the meantime there is unfortunately not a lot that can be done,
AFAICT. There is one hack that I will send you later but it is not
likely to help much. I will also think about how to track down the
cause of the contention further (the profiling trace only shows th
On Tuesday 20 November 2007, Kris Kennaway wrote:
> Kris Kennaway wrote:
> > Kris Kennaway wrote:
> >> In the meantime there is unfortunately not a lot that can be done,
> >> AFAICT. There is one hack that I will send you later but it is not
> >> likely to help much. I will also think about how t
Hi.
Max Laier wrote:
I rolled a tiny, simple, possibly braindamaged benchmark (but then again
php code tends to be braindamaged): test.php includes 1000 different,
essential empty files and is strated over and over from a shell script
which counts the runs completed within 60seconds. 1-8,128
Ivan Voras wrote:
On 21/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Ivan Voras wrote:
Yes, but I had to verify it anyway :)
You haven't verified anything until you look at how much work the system
is doing, before and after.
I have, and it's roughly the same (50 +/- 2 queries/s).
(m
Alexey Popov wrote:
Hi.
Kris Kennaway wrote:
In the meantime there is unfortunately not a lot that can be done,
AFAICT. There is one hack that I will send you later but it is not
likely to help much. I will also think about how to track down the
cause of the contention further (the profilin
On Wed, Nov 21, 2007 at 02:13:19PM +0300, Alexey Popov wrote:
>As mentioned in the description of your patch there is probably a
>scalability problem with stat() syscall on FreeBSD.
I wrote a quick tool to lstat() path elements on an otherwise idle
dual-core system (1.6GHz Turion64x2, FreeBSD6.3/
Hi all.
Sorry, forgot to attach top & vmstat oputput on 8-core 7-stable with
optimized PHP realpath_cache_size.
With best regards,
Alexey Popov
last pid: 91239; load averages: 4.64, 4.72, 7.82
up 0+19:13:37 14
On 21/11/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Ivan Voras wrote:
> > Yes, but I had to verify it anyway :)
>
> You haven't verified anything until you look at how much work the system
> is doing, before and after.
I have, and it's roughly the same (50 +/- 2 queries/s).
(meaning that I
Alexey Popov wrote:
Also could you explain what to look for in the lock profiling results?
Does large "wait_total" values indicate problem or other columns???
All of the columns (well, maybe except for the "lock name" ;-) can
indicate potential problems of various kinds, so you have to look a
Hi.
Kris Kennaway wrote:
In the meantime there is unfortunately not a lot that can be done,
AFAICT. There is one hack that I will send you later but it is not
likely to help much. I will also think about how to track down the
cause of the contention further (the profiling trace only shows th
Ivan Voras wrote:
Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Try this one instead, it applies to HEAD. You'll need to manually enter
the paths though because of how p4 mangles diffs.
It doesn't help, at least in my case (only 4 clients) - the sys time is
still around 30% on
Kris Kennaway wrote:
> Ivan Voras wrote:
>> Kris Kennaway wrote:
>>
>>> Try this one instead, it applies to HEAD. You'll need to manually enter
>>> the paths though because of how p4 mangles diffs.
>>
>> It doesn't help, at least in my case (only 4 clients) - the sys time is
>> still around 30% on
Ivan Voras wrote:
Kris Kennaway wrote:
Try this one instead, it applies to HEAD. You'll need to manually enter
the paths though because of how p4 mangles diffs.
It doesn't help, at least in my case (only 4 clients) - the sys time is
still around 30% on a 4-CPU machine.
I've already explain
Kris Kennaway wrote:
> Try this one instead, it applies to HEAD. You'll need to manually enter
> the paths though because of how p4 mangles diffs.
It doesn't help, at least in my case (only 4 clients) - the sys time is
still around 30% on a 4-CPU machine.
___
Kris Kennaway wrote:
Kris Kennaway wrote:
In the meantime there is unfortunately not a lot that can be done,
AFAICT. There is one hack that I will send you later but it is not
likely to help much. I will also think about how to track down the
cause of the contention further (the profiling tr
> The issue in this thread is not if they are fast, but could they be made
> faster by shortening sys time :)
Yes, I'm aware of that. :-) The comment was related to the former mail
where some uncertainty came along when he read this thread.
> (btw. what is your sys time under stress?)
I'll take
Claus Guttesen wrote:
FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x
dual-core 3GHz on the same type of m/b, apparently because of better
bandwidth to memory. However, this is on a compute-intensive workload
running 1 job per core so would be pretty insensitive to
scheduler/l
> > FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x
> > dual-core 3GHz on the same type of m/b, apparently because of better
> > bandwidth to memory. However, this is on a compute-intensive workload
> > running 1 job per core so would be pretty insensitive to
> > scheduler/locki
Bob Bishop wrote:
Hi,
FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x
dual-core 3GHz on the same type of m/b, apparently because of better
bandwidth to memory. However, this is on a compute-intensive workload
running 1 job per core so would be pretty insensitive to
schedu
Hi,
FWIW, we are seeing 2 x quad-core 2.66GHz outperform (per core) 2 x
dual-core 3GHz on the same type of m/b, apparently because of better
bandwidth to memory. However, this is on a compute-intensive workload
running 1 job per core so would be pretty insensitive to scheduler/
locking iss
Kris Kennaway wrote:
In the meantime there is unfortunately not a lot that can be done,
AFAICT. There is one hack that I will send you later but it is not
likely to help much. I will also think about how to track down the
cause of the contention further (the profiling trace only shows that it
Alexey Popov wrote:
Hi
Kris Kennaway wrote:
CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5%
interrupt, 8.0% idle
A wild idea that might not help: try reducing kern.hz in
loader.conf to
something like 100 and see if something significant changes.
Usually on PHP backends slow PHP code
Claus Guttesen wrote:
> I'm running two DL360 G5 webservers each with two quad-core cpu's.
> Each have 8 GB of ram, one is 2 Ghz and the other is 2.33 Ghz. They
> run just fine. These two webservers have twice the weight of three
> opterons with two dual-core cpu's on our coyote load-balancer.
Th
> > Thank you for your research. I think you can get more %sys with 4-core
> > processors. For me 2xquad-core systems are now completely unusable as
> > PHP backends.
>
> I am getting very alarmed by this discussion as we just took delivery
> of ten 2x quad core systems to be deployes as heavy webs
Hi.
Tom Evans wrote:
After that I rebuilt with SMP GENERIC kernel and put on that server 2
times more requests that UP could handle. For the first time it worked
good. Then I increased load to 2.5 times more than UP. Immediately
Apache child count increased to MaxClients (24), most of them in
> Thank you for your research. I think you can get more %sys with 4-core
> processors. For me 2xquad-core systems are now completely unusable as
> PHP backends.
I am getting very alarmed by this discussion as we just took delivery
of ten 2x quad core systems to be deployes as heavy webservers in
Hi.
Ivan Voras wrote:
CPU states: 5.9% user, 0.0% nice, 81.3% system, 0.0% interrupt, 12.8% idle
CPU states: 82.2% user, 0.0% nice, 13.8% system, 0.0% interrupt, 4.0% idle
Interesting coincidence: 1 CPU generates almost 8x less "sys time" then 8 CPUs.
But it seems that you have found some
On 20/11/2007, Alexey Popov <[EMAIL PROTECTED]> wrote:
> CPU states: 5.9% user, 0.0% nice, 81.3% system, 0.0% interrupt, 12.8% idle
> CPU states: 82.2% user, 0.0% nice, 13.8% system, 0.0% interrupt, 4.0% idle
Interesting coincidence: 1 CPU generates almost 8x less "sys time" then 8 CPUs.
B
On Tue, 2007-11-20 at 19:27 +0300, Alexey Popov wrote:
> Hi.
>
> After that I rebuilt with SMP GENERIC kernel and put on that server 2
> times more requests that UP could handle. For the first time it worked
> good. Then I increased load to 2.5 times more than UP. Immediately
> Apache child cou
Hi.
Ivan Voras wrote:
> Many people (including me) have run FreeBSD on machines like yours
without such problems, so let's dig further.
You don't have WITNESS, INVARIANTS, DIAGNOSTICS or something similar
enabled? Can you try a generic SMP kernel (called "SMP" in 6.x; the
"GENERIC" in 7.x has
Hi Alexey,
Can you please send and dmesg from FreeBSD 7 on this server?
As I'm little puzzled what you mean by 7-stable :)
Alexey Popov wrote:
Hi.
I have a large pool of web backends (Apache + mod_php5) with
2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The
workload is mo
Hi.
Ivan Voras wrote:
Some more ideas: How is your disk load (iostat, systat -vm, diskinfo -t)
during the load? You don't use NFS for the web directories, do you?
Can you run bonnie++ while the machine is idle (i.e. apache is stopped)
just to verify it isn't a stupid problem with the disks or th
Hi
Kris Kennaway wrote:
CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5%
interrupt, 8.0% idle
A wild idea that might not help: try reducing kern.hz in
loader.conf to
something like 100 and see if something significant changes.
Usually on PHP backends slow PHP code eats most of the CPU
Alexey Popov wrote:
Hi.
Kris Kennaway wrote:
CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt,
8.0% idle
A wild idea that might not help: try reducing kern.hz in loader.conf to
something like 100 and see if something significant changes.
Now it runs with hz=100, number of co
Hi.
Kris Kennaway wrote:
CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt,
8.0% idle
A wild idea that might not help: try reducing kern.hz in loader.conf to
something like 100 and see if something significant changes.
Now it runs with hz=100, number of context switches became
On Nov 19, 2007 8:03 AM, Alexey Popov <[EMAIL PROTECTED]> wrote:
>
> Ivan Voras wrote:
> >
> > Also, did you try configuring and running pecl-APC for PHP?'s
> I'm using eAccelerator. Again, the same soft works good on less-CPU
> system and on Linux.
FWIW, when playing with eaccelerator on RELENG_7
Ivan Voras wrote:
Kris Kennaway wrote:
It's explained in the MUTEX_PROFILING(9) manpage (LOCK_PROFILING(9) on 7.0)
cnt_hold The number of times the lock was held and another
thread attempted to acquire the lock.
cnt_lock The number of times t
Kris Kennaway wrote:
> It's explained in the MUTEX_PROFILING(9) manpage (LOCK_PROFILING(9) on 7.0)
>
> cnt_hold The number of times the lock was held and another
>thread attempted to acquire the lock.
>
> cnt_lock The number of times the lock w
Ivan Voras wrote:
Kris Kennaway wrote:
My guess is that you're hitting contention in the TCP send path, but I
missed the start of this conversation so I don't know what problems you
are seeing.
Here it is:
http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038371.html
there's so
Alexey Popov wrote:
Hi.
Ivan Voras wrote:
CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0%
idle
A wild idea that might not help: try reducing kern.hz in loader.conf to
something like 100 and see if something significant changes.
Now it runs with hz=100, number of conte
Kris Kennaway wrote:
> My guess is that you're hitting contention in the TCP send path, but I
> missed the start of this conversation so I don't know what problems you
> are seeing.
Here it is:
http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038371.html
there's some mutex profili
On Mon, Nov 19, 2007 at 07:35:09PM +0100, Ivan Voras wrote:
> Some more ideas: How is your disk load (iostat, systat -vm, diskinfo -t)
> during the load? You don't use NFS for the web directories, do you?
Don't forget about gstat(8), which (if the issue is an I/O bottleneck)
may help pinpoint what
Alexey Popov wrote:
> Here is it: http://83.167.98.162/gprof/kdump.txt.gz
I don't see anything unusual there.
Some more ideas: How is your disk load (iostat, systat -vm, diskinfo -t)
during the load? You don't use NFS for the web directories, do you?
Can you run bonnie++ while the machine is id
Alexey Popov wrote:
Hi.
Robert Watson wrote:
I tried SCHED_ULE, but got no difference:
Did you see no change in throughput, or no change in reported CPU use?
No significant changes.
We should probably take this thread to performance@ and get Kris
involved. He may be interested in trying to
On Nov 19, 2007 2:32 PM, Alexey Popov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I have a large pool of web backends (Apache + mod_php5) with
> 2 x Xeon 3.2GHz processors and 2 x Xeon 5120 dual-core processors. The
> workload is mostly CPU-bound. I'm using 6-STABLE-amd64 and also tried
> 7-STABLE.
>
> No
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
What version of apache do you use and what are:
StartServers
MinSpareServers
MaxSpareServers
MaxClients
KeepAliveTimeout
settings in both configurations?
Best Regards
Alexey Popov wrote:
> Hi.
>
> I have a large pool of web backends (Apac
Hi.
Robert Watson wrote:
I tried SCHED_ULE, but got no difference:
Did you see no change in throughput, or no change in reported CPU use?
No significant changes.
We should probably take this thread to performance@ and get Kris
involved. He may be interested in trying to reproduce your workl
Hi.
Ivan Voras wrote:
last pid: 5266; load averages: 24.67, 22.65, 17.44 up 0+03:56:38
121 processes: 41 running, 62 sleeping, 18 waiting
CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0%
idle
This is really unusual - the number of processes is not that high, but
On Mon, 19 Nov 2007, Alexey Popov wrote:
Robert Watson wrote:
FreeBSD 7 contains significant optimization for increased numbers of cores,
and is where a lot of the work optimizing MySQL has ended up. I see you're
trying out a 6.3 beta, any chance you could try out a 7.0 beta instead?
Also, c
On Mon, 19 Nov 2007 15:54:32 +0100, Alexey Popov <[EMAIL PROTECTED]> wrote:
Hi
Robert Watson wrote:
FreeBSD 7 contains significant optimization for increased numbers of
cores, and is where a lot of the work optimizing MySQL has ended up. I
see you're trying out a 6.3 beta, any chance you c
Hi.
Ivan Voras wrote:
CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0%
idle
A wild idea that might not help: try reducing kern.hz in loader.conf to
something like 100 and see if something significant changes.
Now it runs with hz=100, number of context switches became ~
Hi
Robert Watson wrote:
FreeBSD 7 contains significant optimization for increased numbers of
cores, and is where a lot of the work optimizing MySQL has ended up. I
see you're trying out a 6.3 beta, any chance you could try out a 7.0
beta instead? Also, consider switching to "options SCHED_ULE
Alexey Popov wrote:
> CPU states: 9.5% user, 0.0% nice, 82.0% system, 0.5% interrupt, 8.0%
> idle
A wild idea that might not help: try reducing kern.hz in loader.conf to
something like 100 and see if something significant changes.
___
freebsd-stabl
1 - 100 of 105 matches
Mail list logo
