Re: pgbench: could not connect to server: Resource temporarily unavailable
От | Tom Lane |
---|---|
Тема | Re: pgbench: could not connect to server: Resource temporarily unavailable |
Дата | |
Msg-id | 68893.1661122531@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pgbench: could not connect to server: Resource temporarily unavailable (Kevin McKibbin <kevinmckibbin123@gmail.com>) |
Ответы |
Re: pgbench: could not connect to server: Resource temporarily unavailable
Re: pgbench: could not connect to server: Resource temporarily unavailable |
Список | pgsql-performance |
Thomas Munro <thomas.munro@gmail.com> writes: > If it's something like that, maybe increasing > /proc/sys/net/core/somaxconn would help? I think older kernels only > had 128 here. Bingo! I see $ cat /proc/sys/net/core/somaxconn 128 by default, which is right about where the problem starts. After $ sudo sh -c 'echo 1000 >/proc/sys/net/core/somaxconn' *and restarting the PG server*, I can do a lot more threads without a problem. Evidently, the server's socket's listen queue length is fixed at creation and adjusting the kernel limit won't immediately change it. So what we've got is that EAGAIN from connect() on a Unix socket can mean "listen queue overflow" and the kernel won't treat that as a nonblock-waitable condition. Still seems like a kernel bug perhaps, or at least a misfeature. Not sure what I think at this point about making libpq retry after EAGAIN. It would make sense for this particular undocumented use of EAGAIN, but I'm worried about others, especially the documented reason. On the whole I'm inclined to leave the code alone; but is there sufficient reason to add something about adjusting somaxconn to our documentation? regards, tom lane
В списке pgsql-performance по дате отправления: