Re: PSA: New intel MDS vulnerability mitigations cause measurableslowdown
От | Andres Freund |
---|---|
Тема | Re: PSA: New intel MDS vulnerability mitigations cause measurableslowdown |
Дата | |
Msg-id | 20190515010646.x7cd4imjc7jugbef@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: PSA: New intel MDS vulnerability mitigations cause measurable slowdown (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-hackers |
Hi, On 2019-05-15 12:52:47 +1200, Thomas Munro wrote: > On Wed, May 15, 2019 at 10:31 AM Andres Freund <andres@anarazel.de> wrote: > > *Without* disabling SMT, for readonly pgbench, I'm seeing regressions > > between 7-11%, depending on the size of shared_buffers (and some runtime > > variations). That's just on my laptop, with an i7-6820HQ / Haswell CPU. > > I'd be surprised if there weren't adversarial loads with bigger > > slowdowns - what gets more expensive with the mitigations is syscalls. > > Yikes. This all in warm shared buffers, right? Not initially, but it ought to warm up quite quickly. I ran something boiling down to pgbench -q -i -s 200; psql -c 'vacuum (freeze, analyze, verbose)'; pgbench -n -S -c 32 -j 32 -S -M prepared -T 100 -P1. As both pgbench -i's COPY and VACUUM use ringbuffers, initially s_b will effectively be empty. > So effectively this is the cost of recvfrom() and sendto() going up? Plus epoll_wait(). And read(), for the cases where s_b was smaller than the data. > Did you use -M prepared? Yes. > If not, there would also be a couple of lseek(SEEK_END) calls in > between for planning... I wonder how many more syscall-taxing > mitigations we need before relation size caching pays off. Yea, I suspect we're going to have to go there soon for a number of reasons. - Andres
В списке pgsql-hackers по дате отправления: