Re: FreeBSD on Amazon AWS EC2 long standing performance problems

2021-02-05 Thread Brendan Gregg
G'Day Gunther,

I can at least share some experiences from the other side, and how
they can apply to FreeBSD.

On Sat, Feb 6, 2021 at 1:53 AM Gunther Schadow  wrote:
>
> Hi, I've been with FreeBSD since 386BSD 0.0new. Always tried to run
> everything on it. I saw us lose the epic race against Linux over the
> stupid BSDI lawsuit. But now I'm afraid I am witnessing the complete
> fading of FreeBSD from relevance in the marketplace as the performance
> of FreeBSD on AWS EC2 (and as I see in the chatter from other "cloud"
> platforms) falls far behind that of Linux. Not by a few % points, but
> by factors if not an order of magnitude!
>
> The motto "the power to serve" meant that FreeBSD was the most solid
> and consistently performing system for heavy multi-tasking network
> and disk operation. A single thread was allowed to do better on another
> OS without us feeling shame, but overall you could rely on FreeBSD
> being your best choice to overall server performance.
>
> The world has changed. We used to run servers on bare metal in a cage
> in physical data center. I did that. A year or two of instability with
> the FreeBSD drivers for new beefy hardware didn't scare me off.
>
> Now the cost and flexibility calculations today changed the market
> away from bare metal to those "cloud" service providers, Amazon AWS
> (>38% market share), Azure (19% market share), and many others. I
> still remember searching for "hosting" providers who would
> offer FreeBSD (or any BSD) as an option and it was hard to find. On
> Amazon AWS we have the FreeBSD image ready to launch, that is good.
>
> But the problem is, it's disk (and network?) performance is bad (to
> horrible) and it's really sad and embarrassing. Leaving FreeBSD beaten
> far behind and for realistic operations, it's impossible to use, despite
> being so much better organized than Linux. I have put significant
> investment into a flexible scalable FreeBSD image only to find now that I
> just cannot justify using FreeBSD when Linux out of the box is several
> times faster.
>
> There have been few problem reports about this over many years, and
> they all end the same way: either no response, or defensive response
> ("your measures are invalid"), with the person reporting the problem
> eventually walking away with no solution. Disinterest. I can link to
> those instances. Examples:
>
> https://lists.freebsd.org/pipermail/freebsd-performance/2009-February/003677.html
> https://forums.freebsd.org/threads/aws-disk-i-o-performance-xbd-vs-nvd.74751/
> https://forums.freebsd.org/threads/aws-ec2-ena-poor-network-performance-low-pps.77093/#post-492744
> https://forums.freebsd.org/threads/poor-php-and-python-performances.72427/
> https://forums.freebsd.org/threads/freebsd-was-once-the-power-to-server-but-in-an-aws-world-we-have-fallen-way-waaay-behind-and-there-seems-no-interest-to-fix-it.78738/page-2
>
> My intention is not to rant, vent, proselytize to Linux (I hate Linux)
> but to see what is wrong with FreeBSD? And how it can be fixed? Why does
> it seem nobody is interested in getting the dismal AWS EC2 performance
> resolved? This looks to me like a vicious cycle: FreeBSD on AWS is
> bad so nobody will use it for any real work, and because nobody uses it
> there is no interest in making it work well. In addition there is no interest
> on the side of FreeBSD people to make it better. It's got to be the lack
> of interest, not of anyone not having access to the AWS EC2 hardware.

I think the better question is how many full time staff work on EC2
FreeBSD performance, and how to create more roles.

Large companies have performance engineering teams to reduce cost, as
do latency-sensitive companies of any size. I'd estimate there are
well over 100 staff with the title "performance engineer" who work on
Linux: most of whom work on Linux as part of another product.

There is a mentality with these large companies, whether it makes
sense or not, to run their own datacenters. So most of the performance
engineers on Linux are looking at bare metal performance and not EC2.

Fortunately for Linux, there are a few of us who do work on EC2. I
work at Netflix on the streaming side, and myself and a colleague
(Amer) are performance engineers who work on Linux EC2 a lot (as well
as other things). Other teams work on Linux EC2 performance from time
to time (e.g., BaseOS and Titus). If you were to add up all our
collective time, it probably works out to 2 full time engineers
working on Linux EC2 performance. Our focus is LTS releases, so we
aren't finding issues every day (we likely would if we were looking at
mainline), but we do find some and get them fixed.

So who is the Netflix of EC2 FreeBSD? What large company, with a
performance team (or is large enough to create one) runs (or may
consider running) FreeBSD on EC2? I'd identify the company and
management, and help them with a proposal and job description for a
performance engineer. My Systems Performance book (2nd Ed) docu

Re: pmcstat -z32 -G truncates callgraph to 8

2014-10-30 Thread Brendan Gregg
G'Day Ed,

On Wed, Oct 29, 2014 at 12:40 PM, Ed Maste  wrote:
> On 28 October 2014 13:38, Brendan Gregg  wrote:
>> Ah, thanks, I'm on 10.0-STABLE and I have:
>>
>> kern.hwpmc.callchaindepth: 8
>>
>> Glad it's something simple!
>
> Those are the best kinds of problems to have, although we ought to
> make sure this point is covered in the FreeBSD profiling documentation
> that we have or create.

Yes; at least we have this thread now, which should be searchable.

>
> Also, do you think that we should bump the compiled-in default up to 32?

Yes. When I'm using profiling data, I like full stacks for making
flame graphs. For the FreeBSD kernel, 32 frames should usually be
enough (I have a flame graph that reaches 24 frames for the kernel,
but no more). For user-level, I'd probably need ~100. So making the
compiled-in default to 32 would hopefully be sufficient for most
kernel profiling, and one would need to bump that up for deep
user-level stacks. I guess this would also need
PMC_CALLCHAIN_DEPTH_MAX = 128 to work.

Brendan
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"


Re: pmcstat -z32 -G truncates callgraph to 8

2014-10-28 Thread Brendan Gregg
G'Day Stefan,

On Tue, Oct 28, 2014 at 2:45 AM, Stefan Parvu
 wrote:
>
>> I'm using pmcstat to capture call graphs, however, these always seem
>> truncated to 8 stack frames. Anyone else hit this? Anyone know a fix
>> or workaround?
>
> On FreeBSD 11.0-CURRENT Im seeing these:
>
> kern.features.hwpmc_hooks: 1
> kern.hwpmc.softevents: 16
> kern.hwpmc.callchaindepth: 16
> kern.hwpmc.hashsize: 1024
> kern.hwpmc.nsamples: 1024
> kern.hwpmc.mtxpoolsize: 2048
> kern.hwpmc.logbuffersize: 4
> kern.hwpmc.nbuffers: 1024

Ah, thanks, I'm on 10.0-STABLE and I have:

kern.hwpmc.callchaindepth: 8

Glad it's something simple!

Brendan
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"


pmcstat -z32 -G truncates callgraph to 8

2014-10-27 Thread Brendan Gregg
G'Day,

I'm using pmcstat to capture call graphs, however, these always seem
truncated to 8 stack frames. Anyone else hit this? Anyone know a fix
or workaround?

Example:

pmcstat -S CPU_CLK_UNHALTED.THREAD_P -z 32 -O out.pmclog
pmstat -R out.pmclog -z 32 -G out.pmc

The problem is that out.pmc never goes deeper than 8 frames, despite
-z 32, and despite PMC_CALLCHAIN_DEPTH_MAX = 32.

I need deeper stacks to generate flame graphs
(https://github.com/brendangregg/FlameGraph), and was trying Ed
Maste's stackcollapse-pmc.pl to do it.

Using pmcstat -F, and bringing up the output in Kcachegrind, shows
that some stacks are indeed deeper than 8 as expected (although it
seems to only work for kernel stacks, and not user-level). I don't
know if Kcachegrind is doing its own workaround, of if the -F output
is deeper than -G (still studying the output formats)...

thanks,

Brendan
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"