Re: I like iostat, but...

On Tue, Sep 23, 2014 at 12:29:22AM +0300, Andriy Gapon wrote: > On 23/09/2014 00:22, David Wolfskill wrote: > > ... I rather wish I could get the same information via sysctl. (Well, > > something seems to be available via the "opaque" kern.devstat.all > > sysctl(8)

I like iostat, but...

... I rather wish I could get the same information via sysctl. (Well, something seems to be available via the "opaque" kern.devstat.all sysctl(8) variable, but sysctl(8) doesn't display all of it, and parsing it seems as if that would require knowledge about the internals of the system where the d

Reality check? compat.ia32.maxdsiz in jailed "32-bit" environment

I am supporting a performance-sensitive software development environment that: * Is presently contrained to operate in a FreeBSD/i386 (32-bit) environment. * Primarily uses svn, gcc (with various target architectures), and bmake. * Has more main memory than FreeBSD appears to be able to make co

Re: Apparent performance regression 8.3@ -> 8.4@r255966?

On Thu, Oct 10, 2013 at 04:02:47PM +0200, Ivan Voras wrote: > On 07/10/2013 19:28, David Wolfskill wrote:> At work, we have a bunch of > machines that developers use to build some > > software. The machines presently run FreeBSD/amd64 8.3-STABLE @rxx > > (with a few loca

Re: Apparent performance regression 8.3@ -> 8.4@r255966?

On Mon, Oct 07, 2013 at 09:19:38PM +0200, Erik Cederstrand wrote: > ... > > In examining the CPU utilization graphs, the CPU generally looks > > about 5% busy for the first 15 minutes; this would be bmake determining > > dependency graphs, I expect. > > Is that one process using 100% of one core,

Re: Apparent performance regression 8.3@ -> 8.4@r255966?

On Mon, Oct 07, 2013 at 10:32:57AM -0700, Adrian Chadd wrote: > On Oct 7, 2013 1:28 PM, "David Wolfskill" wrote: > > > > At work, we have a bunch of machines that developers use to build some > > software. The machines presently run FreeBSD/amd64 8.3-STABLE @rx

Apparent performance regression 8.3@ -> 8.4@r255966?

At work, we have a bunch of machines that developers use to build some software. The machines presently run FreeBSD/amd64 8.3-STABLE @rxx (with a few local patches, which have since been committed to stable/8), and the software is built within a 32-bit jail. The hardware includes 2 packages o

vm.exec_map_entries vs. hw.ncpu vs. ...?

A colleague at work has been researching the nature of some issues we're seeing in a FreeBSD/amd64 release/8.2.0 environment in which amd (which is providing services to a jail, where the "useful work" actually gets done) is apparently failing (on occasion) to perform the work it is supposed to do

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

I have compiled the data I have so far, and placed it, as well as ministat(1) plots and graphs (boxplots) generated with the R language. All of this is available at . In addition to the real time & CPU times, the above-referenced data inclue all of

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Tue, Oct 26, 2010 at 10:34:08AM -0400, Mike Tancsa wrote: > ... > ULE is the default in 7 as well. Perhaps remove some of the kernel > options not in 7, that are in 8 by default? What is the disk > subsystem ? just ata ? > > They seem innocuous enough, but worth a try > > optionsHWP

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Wed, Oct 27, 2010 at 01:06:18PM +0200, Ivan Voras wrote: > On 10/27/10 12:55, David Wolfskill wrote: > > > That *is* a problem, as I cannot justify a migration to a branch > > of FreeBSD that imposes about a 23% penalty in elapsed time on this > > workload. I want fo

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Wed, Oct 27, 2010 at 11:54:07AM +0200, Ivan Voras wrote: > ... > > the 8.x reference machine, and each terminated with a status code of 0: > > > > startstopreal usersys os > > 128867 1288111298 131.14 12.77 17.88 7.1-R+ > > > 1288109542 1288109653 111.26 12.

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Tue, Oct 26, 2010 at 02:03:34PM +0200, Ivan Voras wrote: > ... > Since you now have the two kernels readily available, can you rule out > NFS by just repeating the step which involves it in both kernels and > compare the results? On Tue, Oct 26, 2010 at 02:47:11PM +0200, Ivan Voras wrote: > ...

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Tue, Oct 26, 2010 at 10:34:08AM -0400, Mike Tancsa wrote: > At 07:29 AM 10/26/2010, David Wolfskill wrote: > > >OK -- but we were using the default scheduler in each case. The basic > >point I'm making here is the apparent performance regression for > >similarly

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Mon, Oct 25, 2010 at 10:09:53PM -0700, Julian Elischer wrote: > ... > >It appears to me that the last test runs show results that are just > >about identical to the "native" 8.1-S kernel+userland, so if I > >understand the logic correctly, that appears to implicate something in > >the 8.1-S kern

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Wed, Oct 20, 2010 at 04:50:10PM -0700, Julian Elischer wrote: > ... > try the 7.x machine but running the 8.x kernel.. i.e. change nothing, > but boot the new kernel. > ... OK; here are results of previous tests, along with the above. As noted earlier, I needed to set the UNAME_r environmant

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Fri, Oct 22, 2010 at 05:07:52PM -0700, Julian Elischer wrote: > On 10/22/10 4:48 PM, David Wolfskill wrote: > >On Fri, Oct 22, 2010 at 04:17:30PM -0700, David Wolfskill wrote: > >>On Wed, Oct 20, 2010 at 04:50:10PM -0700, Julian Elischer wrote: > >>>... > >&

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Fri, Oct 22, 2010 at 04:17:30PM -0700, David Wolfskill wrote: > On Wed, Oct 20, 2010 at 04:50:10PM -0700, Julian Elischer wrote: > > ... > > try the 7.x machine but running the 8.x kernel.. i.e. change nothing, > > but boot the new kernel. > > I just started that te

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Wed, Oct 20, 2010 at 04:50:10PM -0700, Julian Elischer wrote: > ... > try the 7.x machine but running the 8.x kernel.. i.e. change nothing, > but boot the new kernel. I just started that test, to run over the weekend. I did run another test (3 iterations) with the 7.1 OS (kernel+userland) on

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)

On Thu, Oct 21, 2010 at 04:53:30PM -0500, Dan Nelson wrote: > ... > An observation: on 8.1, both user and sys times are less, but real time is > higher. So 8.1 finished the build using less CPU, but spent more time > waiting for something else. Interesting; thanks for pointing that out. > Disk?

Possible evidence of performance regression for 8.1-S (vs. 7.1)

At work, my focus is on facilitating & improving the productivity of the developers. Much of the time they spend is in waiting for a build to complete -- thus, something that reduces the time thus spent is likely to be beneficial (all other things being approximately equal), while something that i

Presentation of performance data & analysis?

I apologize, as this is a bit tangential to the description of the list. I've been doing some measurements of workloads of interest (in my case, the workload is building some software, and the metric of greatest interest is "elapsed time" (which I obtain via /usr/bin/time)). And I've been using p

Re: Using sysctl(1) to gather resource consumption data

On Thu, Sep 18, 2008 at 12:39:27AM +1000, Norberto Meijome wrote: > ... > > Also, the only times I have used SNMP, it has been using a version that > > did not support encryption in any form (as for as I know), and since > > some of the transit was over facilities we don't control, I thought it > >

Re: Using sysctl(1) to gather resource consumption data

On Sun, Sep 14, 2008 at 09:11:36PM +1000, Norberto Meijome wrote: > ... > Out of curiosity, how does bsnmpd compare to your approach with regards to > impact on the system. It is part of 7.0 , not sure about previous versions, > and > it is definitely a more standard and cross platform approach ,

Using sysctl(1) to gather resource consumption data

At $work, I've been trying to gather information on "interesting patterns" of resource consumption during moderately long-running (5 - 8 hour) tasks; the hosts in question usually run FreeBSD 6.2, though there's an occasional 6.x that's more recent, as well as a bit of 7-STABLE. I wanted to have a

Are sysctl(8) values useful for measuring system resource consumption?

At ${work}, one of my projects is to help obtain information regarding the "developer experience," what resources are thus consumed, and figure out ways to mitigate the pain -- the objective, of course, being to help the developers be more productive within a FreeBSD environment. A couple of the p