Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: httpd 2.4.25, mpm_event, ssl: segfaults
To: dev@httpd.apache.org
References: <alpine.GSO.2.20.1702011839170.17193@hatchepsut.acc.umu.se>
 <CAKQ1sVOMeQtb6=w3+FTzt2YE5OWOuzObbXWBUvfu73JLVkW6Bw@mail.gmail.com>
 <eb0b375f-6ad2-fbb0-cb2d-2a17a03c46ee@gmail.com>
 <CAKQ1sVMXRG2n2CuNiOWWW6oha+HEsTMC3bnOjNvR4WL4G_PvVw@mail.gmail.com>
 <0a787764-e1ac-88e4-9b26-92d91bdd5d72@gmail.com>
 <CAKQ1sVM=6mzFAZ+g1t-gFrfKo4PE1S0vGR8s=YQeapmBmcdQ2Q@mail.gmail.com>
 <75f8913a-d874-e2c8-d5f5-c917cf236c1e@gmail.com>
 <alpine.GSO.2.20.1702030900470.23400@hatchepsut.acc.umu.se>
 <alpine.GSO.2.20.1702030922530.23400@hatchepsut.acc.umu.se>
From: Jacob Champion <champion.p@gmail.com>
Message-ID: <8003d8ac-0451-8149-4560-3a0210fc1507@gmail.com>
Date: Mon, 6 Feb 2017 11:24:21 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.GSO.2.20.1702030922530.23400@hatchepsut.acc.umu.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Mon, 06 Feb 2017 19:24:34 -0000

On 02/03/2017 12:30 AM, Niklas Edmundsson wrote:
> Methinks this makes mmap+ssl a VERY bad combination if the thing
> SIGBUS:es due to a simple IO error, I'll proceed with disabling mmap and
> see if that is a viable way to go for our workload...

(Pulling from a parallel conversation, with permission)

The question has been raised: is our mmap() optimization really giving 
us the utility we want for the additional instability we pay? Stefan had 
this to say:

On 02/03/2017 08:32 AM, Stefan Eissing wrote:
> Experimented on my Ubuntu 14.04 image on Parallels on MacOS 10.12,
> MacBook Pro mid 2012. Loading a 10 MB file 1000 times over 8
> connections:
>
> h2load -c 8 -t 8 -n 1000 -m1 http://xxx/10mb.file
>
> using HTTP/1.1 and HTTP/2 (limit of 1 stream at a time per
> connection). Plain and with TLS1.2, transfer speeds in GByte/sec
> from  localhost:
>
>            H1Plain H1SSL  H2Plain H2SSL
> MMAP on    4.3     1.5    3.8     1.3
>      off   3.5     1.1    3.8     1.3
>
> HTTP/2 seems rather unaffected, while HTTP/1.1 experiences
> significant  differences. Hmm...

and I replied:

Am 03.02.2017 um 21:47 schrieb Jacob Champion <champion.p@gmail.com>:
> Weird. I can't see any difference for plain HTTP/1.1 when just
> toggling EnableMMAP, even with EnableSendfile off. I *do* see a
> significant difference for TLS+HTTP/1.1. That doesn't really make
> sense to me; is there some other optimization kicking in?
>
> sendfile blows the mmap optimization out of the water, but naturally
> it can't kick in for TLS. I would be interested to see if an
> O_DIRECT-aware file bucket could speed up the TLS side of things
> without exposing people to mmap instability.

I was also interested to see if there was some mmap() flag we were 
missing that could fix the problem for us. Turns out a few systems (used 
to?) have one called MAP_COPY. Linus had a few choice words about it:

     http://yarchive.net/comp/linux/map_copy.html

Linus-insult-rant aside, his point applies here too, I think. We're 
using mmap() as an optimized read(). We should be focusing on how to use 
read() in an optimized way. And surely read() for modern systems has 
come a long way since that thread in 2001?

Considering the massive amount of caching that's built into the entire 
HTTP ecosystem already, O_DIRECT *might* be an effective way to do that 
(in which we give up filesystem optimizations and caching in return for 
a DMA into userspace). I have a PoC about halfway done, but I need to 
split my time this week between this and the FCGI stuff I've been 
neglecting.

--Jacob