Anthony Bourov wrote:
> Regarding performance of: lib/libc/net/nsdispatch.c
Have you tried nscd(8)? It should at least amortize the startup costs...
(see nsswitch.conf(5) for instructions how to set it up)
signature.asc
Description: OpenPGP digital signature
Regarding performance of: lib/libc/net/nsdispatch.c
When used from: lib/libc/net/getgrent.c (called by initgroups())
I don't normally post here but I wanted to get some feed back on a performance
issue that I spotted. I run a large number of high-volume web hosting servers
and noticed on
Hi,
ivo...@gmail.com wrote:
As for the original thread topic: I've communicated with the OP and it
appears his method of benchmarking had an error so the problems that
appear in his post are bogus.
It is not quite true that the "method" is bogus, there just seems to be
a huge difference bet
On Feb 13, 2009 8:27pm, Josh Paetzel wrote:
In my limited experience with VMWare linux seems to have near bare metal
disk performance. FreeBSD seems to incur a significant performance penalty.
For instance on my laptop, running OSX and VMWare Fusion, FreeBSd virtual
machines can't saturate
On Feb 11, 2009, at 1:02 PM, Ivan Voras wrote:
As previously demonstrated by me and others, Linux usually has
significantly better file system performance in the non-virtualized
case, so the difference could be simply increased by the
virtualization.
In my limited experience with VMWare l
2009/2/11 Antony Mawer :
> How would one go about gathering data on such a scenario to help improve
> this? We were planning a project involving VMware deployments with FreeBSD
> 7.1 systems in the near future, but if performance is that bad it is likely
> to be a show stopper.
I have now tested
Antony Mawer wrote:
> Ivan Voras wrote:
>> Sebastiaan van Erk wrote:
>>> Sebastiaan van Erk wrote:
(However, just to give you an idea I attached the basic 5.1.2
unixbench outputs (the CPU info for FreeBSD is "fake", since unixbench
does a cat /proc/cpuinfo, so I removed the /proc/ pa
Ivan Voras wrote:
Sebastiaan van Erk wrote:
Sebastiaan van Erk wrote:
(However, just to give you an idea I attached the basic 5.1.2
unixbench outputs (the CPU info for FreeBSD is "fake", since unixbench
does a cat /proc/cpuinfo, so I removed the /proc/ part and copied the
output under linux to
Sebastiaan van Erk wrote:
> Sebastiaan van Erk wrote:
>> (However, just to give you an idea I attached the basic 5.1.2
>> unixbench outputs (the CPU info for FreeBSD is "fake", since unixbench
>> does a cat /proc/cpuinfo, so I removed the /proc/ part and copied the
>> output under linux to the "pro
Sebastiaan van Erk wrote:
(However, just to give you an idea I attached the basic 5.1.2 unixbench
outputs (the CPU info for FreeBSD is "fake", since unixbench does a cat
/proc/cpuinfo, so I removed the /proc/ part and copied the output under
linux to the "procinfo" file.)
Of course I forgot t
Ivan Voras wrote:
Hi,
Thanks for the reply.
Sebastiaan van Erk wrote:
Hi,
[snip]
1 2 4
freebsd 12.0009 13.6348 12.9402 (MB/s)
linux 376.145 651.314 634.649 (MB/s)
Both virtual machi
Sebastiaan van Erk wrote:
> Hi,
>
> I want to deploy a production FreeBSD web site (database cluster, apache
> cluster, ip failover using carp, etc.), however I'm experiencing painful
> disk I/O throughput problems which currently does not make the above
> project viable. I've done some rudimentar
Hi,
I want to deploy a production FreeBSD web site (database cluster, apache
cluster, ip failover using carp, etc.), however I'm experiencing painful
disk I/O throughput problems which currently does not make the above
project viable. I've done some rudimentary benchmarking of two
identically
On Tue, 25 Oct 2005, Lukas Razik wrote:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/mp_machdep.c?only_with_tag=RELENG_5_4
"Add a knob for disabling/enabling HTT,
"machdep.hyperthreading_allowed".
Default off due to information disclosure on multi-user systems."
Does turnin
Joseph Koshy <[EMAIL PROTECTED]> schrieb am 24.10.05 07:57:32:
>
> On 10/24/05, Lukas Razik <[EMAIL PROTECTED]> wrote:
> >
> > O.K.
> >
> > I've found the reason for the issue.
> > After exchanging the newer
> > src/sys/i386/include/cpufunc.h,v 1.142.6.1 2005/05/13 00:12:57
> > src/sys/i386/i386/
On 10/24/05, Lukas Razik <[EMAIL PROTECTED]> wrote:
>
> O.K.
>
> I've found the reason for the issue.
> After exchanging the newer
> src/sys/i386/include/cpufunc.h,v 1.142.6.1 2005/05/13 00:12:57
> src/sys/i386/i386/mp_machdep.c,v 1.235.2.6.2.3 2005/05/13 00:12:56
> from 5.4-RELEASE-p1 by the old
>
O.K.
I've found the reason for the issue.
After exchanging the newer
src/sys/i386/include/cpufunc.h,v 1.142.6.1 2005/05/13 00:12:57
src/sys/i386/i386/mp_machdep.c,v 1.235.2.6.2.3 2005/05/13 00:12:56
from 5.4-RELEASE-p1 by the old
src/sys/i386/include/cpufunc.h,v 1.142 2004/04/07 20:46:05
src/sys
Hello!
Today I've done a cvsup to 5.4-RELEASE-p8 and built a new kernel.
But now I have problems with xine because if I watch a DVD then I get about two
short freezes per second.
With my old 5.4-RELEASE kernel I have no problems and the config is exactly the
same...
Does anyone know a solution
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
Does FreeBSD have any facilities setup for peoople wishing to work on
'sub projects' collaboratively? Something akin to http://pgfoundry.org
for PostgreSQL?
No, there's no such thing. But what stops you from using SF (or something
similar) as a CVS reposito
On Tue, May 10, 2005 at 01:35:40PM -0500, Jonathan Noack wrote:
> Sounds great! When do you begin? ;-)
>
> This has been proposed before and has been (to my knowledge) universally
> accepted as a Good Idea. If you have the interest and time to devote to
> it, I would urge you to work on it.
> This sounds somewhat similar to Solaris dtrace stuff?
Dtrace can be a (very useful) component for collecting
performance metrics. What I am talking about is a framework
where you'd apply dtrace or other micro/system level
performance tests or benchmarks on a regular basis for a
variety of machi
* Petri Helenius ([EMAIL PROTECTED]) [050510 12:52]:
>
> This sounds somewhat similar to Solaris dtrace stuff?
>
> Pete
This sounds more like a QA/Feedback process. dtrace isn't
just a conglomeration of the usual performance metrics. It's
closer to a total revamp of how you perform said metrics
This sounds somewhat similar to Solaris dtrace stuff?
Pete
Bakul Shah wrote:
This thread makes me wonder if there is value in runing
performance tests on a regular basis. This would give an
early warning of any peformance loss and can be a useful
forensic tool (one can pinpoint when some performan
On 5/10/2005 10:18 AM, Bakul Shah wrote:
This thread makes me wonder if there is value in runing
performance tests on a regular basis. This would give an
early warning of any peformance loss and can be a useful
forensic tool (one can pinpoint when some performance curve
changed discontinuously eve
This thread makes me wonder if there is value in runing
performance tests on a regular basis. This would give an
early warning of any peformance loss and can be a useful
forensic tool (one can pinpoint when some performance curve
changed discontinuously even though at the time of change it
may be
Jonathan Noack wrote:
On 5/9/2005 12:31 PM, Pete French wrote:
5.3 ships with SMP turned on, which makes lock operations rather
expensive on single-processor machines. 4.x does not have SMP
turned on by default. Would you be able to re-run your test with
SMP turned off?
I just ran a test here w
26 matches
Mail list logo
