| От | Konstantin Knizhnik |
|---|---|
| Тема | Re: Built-in connection pooler |
| Дата | |
| Msg-id | fb171cef-95ad-af8b-e38d-e52eb84dae6b@postgrespro.ru обсуждение исходный текст |
| Ответ на | Re: Built-in connection pooler (Thomas Munro <thomas.munro@gmail.com>) |
| Ответы |
Re: Built-in connection pooler
Re: Built-in connection pooler |
| Список | pgsql-hackers |
On 14.07.2019 8:03, Thomas Munro wrote:
>
> On my FreeBSD box (which doesn't have epoll(), so it's latch.c's old
> school poll() for now), I see the connection proxy process eating a
> lot of CPU and the temperature rising. I see with truss that it's
> doing this as fast as it can:
>
> poll({ 13/POLLIN 17/POLLIN|POLLOUT },2,1000) = 1 (0x1)
>
> Ouch. I admit that I had the idea to test on FreeBSD because I
> noticed the patch introduces EPOLLET and I figured this might have
> been tested only on Linux. FWIW the same happens on a Mac.
>
I have committed patch which emulates epoll EPOLLET flag and so should
avoid busy loop with poll().
I will be pleased if you can check it at FreeBSD box.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера