FD_SETSIZE with large #s of files/ports in use

--=_8e0051069f5bc30063eebc5dfbdf1fc4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



An interesting issue came up the other day. We are working with an
application that opens a considerable number of files and tcp/udp ports
(>3000). Unfortunately, that means that the odbc driver fails sometimes d=
ue
to a corrupted stack. We eventually figured out what was causing the
corrupted stack.=20

The SOCK_wait_for_ready(SocketClass *sock, BOOL output,
int retry_count) function inside socket.c calls select. Unfortunately, th=
e
socket file descriptor number can be quite large at this time. That means
that the fd_set fds variable can misused. The fd_set variable type only
allows 1024 file descriptors to be used by the calling program on many
Linux versions. This can be changed by setting FD_SETSIZE or __FD_SETSIZE
to a larger number. We have ran tests where we were able to change the
__FD_SETSIZE value in
/usr/src/...linuxversion../linux/include/linux/posix_types.h . The fix
worked well.

Unfortunately, this isn't a good solution because a software
update to another linux version will invalidate our fix. We've tried
various mechanisms to set FD_SETSIZE or __FD_SETSIZE in socket.c but with
no luck. Has anyone else had this problem and came up with a good fix? Or
is there a better solution?

Barry Nicholson
Niceng.com
--=_8e0051069f5bc30063eebc5dfbdf1fc4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

An interesting issue came up the other day.  We are working with an=
application that opens a considerable number of files and tcp/udp ports (&=
gt;3000).   Unfortunately, that means that the odbc driver fails =
sometimes due to a corrupted stack.  We eventually figured out what wa=
s causing the corrupted stack. 

The SOCK_wait_for_ready(=
SocketClass *sock, BOOL output, int retry_count) function inside socket.c c=
alls select.  Unfortunately, the socket file descriptor number can be =
quite large at this time.  That means that the fd_set fds variable can=
misused.   The fd_set variable type only allows 1024 file descri=
ptors to be used by the calling program on many Linux versions.  =
This can be changed by setting FD_SETSIZE or __FD_SETSIZE to a larger numb=
er.   We have ran tests where we were able to change the __FD_SET=
SIZE value in /usr/src/...linuxversion../linux/include/linux/posix_types.h =
   The fix worked well.

Unfortunately, this isn't=
a good solution because a software update to another linux version will in=
validate our fix.   We've tried various mechanisms to set FD_SETS=
IZE or __FD_SETSIZE in socket.c but with no luck.   Has anyone el=
se had this problem and came up with a good fix?   Or is there a =
better solution?

Barry Nicholson
Niceng.com

Re: FD_SETSIZE with large #s of files/ports in use

This is a multi-part message in MIME format.
--------------040403050003070207000607
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Could you please try the attached patch?

regards,
Hiroshi Inoue

Barry Nicholson wrote:
> An interesting issue came up the other day. We are working with an
> application that opens a considerable number of files and tcp/udp ports
> (>3000). Unfortunately, that means that the odbc driver fails
> sometimes due to a corrupted stack. We eventually figured out what was
> causing the corrupted stack.
>
> The SOCK_wait_for_ready(SocketClass *sock, BOOL output, int retry_count)
> function inside socket.c calls select. Unfortunately, the socket file
> descriptor number can be quite large at this time. That means that the
> fd_set fds variable can misused. The fd_set variable type only allows
> 1024 file descriptors to be used by the calling program on many Linux
> versions. This can be changed by setting FD_SETSIZE or __FD_SETSIZE to
> a larger number. We have ran tests where we were able to change the
> __FD_SETSIZE value in
> /usr/src/...linuxversion../linux/include/linux/posix_types.h . The fix
> worked well.
>
> Unfortunately, this isn't a good solution because a software update to
> another linux version will invalidate our fix. We've tried various
> mechanisms to set FD_SETSIZE or __FD_SETSIZE in socket.c but with no
> luck. Has anyone else had this problem and came up with a good fix?
> Or is there a better solution?
>
> Barry Nicholson
> Niceng.com

--------------040403050003070207000607
Content-Type: text/plain;
name="socket.diff"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="socket.diff"

KioqIHNvY2tldC5jLm9yaWcJMjAxMC0wMi0wNCAwMDo0MDo1NS42NDMwMDAw
MDAgKzA5MDAKLS0tIHNvY2tldC5jCTIwMTAtMDUtMTkgMDg6NTM6NTkuNDI5
MDAwMDAwICswOTAwCioqKioqKioqKioqKioqKgoqKiogMzg1LDM5MSAqKioq
CiAgCQkJRkRfWkVSTygmZXhjZXB0X2Zkcyk7CiAgCQkJRkRfU0VUKHNlbGYt
PnNvY2tldCwgJmZkcyk7CiAgCQkJRkRfU0VUKHNlbGYtPnNvY2tldCwgJmV4
Y2VwdF9mZHMpOwohIAkJCXJldCA9IHNlbGVjdCgoaW50KSBzZWxmLT5zb2Nr
ZXQgKyAxLCBOVUxMLCAmZmRzLCAmZXhjZXB0X2ZkcywgdGltZW91dCA+IDAg
PyAmdG0gOiBOVUxMKTsKICAJCQlnZXJybm8gPSBTT0NLX0VSUk5POwogIAkJ
CWlmICgwIDwgcmV0KQogIAkJCQlicmVhazsKLS0tIDM4NSwzOTEgLS0tLQog
IAkJCUZEX1pFUk8oJmV4Y2VwdF9mZHMpOwogIAkJCUZEX1NFVChzZWxmLT5z
b2NrZXQsICZmZHMpOwogIAkJCUZEX1NFVChzZWxmLT5zb2NrZXQsICZleGNl
cHRfZmRzKTsKISAJCQlyZXQgPSBzZWxlY3QoMSwgTlVMTCwgJmZkcywgJmV4
Y2VwdF9mZHMsIHRpbWVvdXQgPiAwID8gJnRtIDogTlVMTCk7CiAgCQkJZ2Vy
cm5vID0gU09DS19FUlJOTzsKICAJCQlpZiAoMCA8IHJldCkKICAJCQkJYnJl
YWs7CioqKioqKioqKioqKioqKgoqKiogNDk3LDUwMyAqKioqCiAgCQkJdG0u
dHZfc2VjID0gcmV0cnlfY291bnQ7CiAgCQkJdG0udHZfdXNlYyA9IDA7CiAg
CQl9CiEgCQlyZXQgPSBzZWxlY3QoKGludCkgc29jay0+c29ja2V0ICsgMSwg
b3V0cHV0ID8gTlVMTCA6ICZmZHMsIG91dHB1dCA/ICZmZHMgOiBOVUxMLCAm
ZXhjZXB0X2Zkcywgbm9fdGltZW91dCA/IE5VTEwgOiAmdG0pOwogIAkJZ2Vy
cm5vID0gU09DS19FUlJOTzsKICAJfSB3aGlsZSAocmV0IDwgMCAmJiBFSU5U
UiA9PSBnZXJybm8pOwogIAlpZiAocmV0cnlfY291bnQgPCAwKQotLS0gNDk3
LDUwMyAtLS0tCiAgCQkJdG0udHZfc2VjID0gcmV0cnlfY291bnQ7CiAgCQkJ
dG0udHZfdXNlYyA9IDA7CiAgCQl9CiEgCQlyZXQgPSBzZWxlY3QoMSwgb3V0
cHV0ID8gTlVMTCA6ICZmZHMsIG91dHB1dCA/ICZmZHMgOiBOVUxMLCAmZXhj
ZXB0X2Zkcywgbm9fdGltZW91dCA/IE5VTEwgOiAmdG0pOwogIAkJZ2Vycm5v
ID0gU09DS19FUlJOTzsKICAJfSB3aGlsZSAocmV0IDwgMCAmJiBFSU5UUiA9
PSBnZXJybm8pOwogIAlpZiAocmV0cnlfY291bnQgPCAwKQo=

--------------040403050003070207000607
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

--------------040403050003070207000607--

Re: FD_SETSIZE with large #s of files/ports in use

Hiroshi Inoue wrote:
> Hi,
>
> Could you please try the attached patch?

Oops it doesn't seem to work.
Another way is to use poll() instead of select().

regards,
Hiroshi Inoue

> regards,
> Hiroshi Inoue
>
> Barry Nicholson wrote:
>> An interesting issue came up the other day. We are working with an
>> application that opens a considerable number of files and tcp/udp
>> ports (>3000). Unfortunately, that means that the odbc driver fails
>> sometimes due to a corrupted stack. We eventually figured out what
>> was causing the corrupted stack.
>> The SOCK_wait_for_ready(SocketClass *sock, BOOL output, int
>> retry_count) function inside socket.c calls select. Unfortunately,
>> the socket file descriptor number can be quite large at this time.
>> That means that the fd_set fds variable can misused. The fd_set
>> variable type only allows 1024 file descriptors to be used by the
>> calling program on many Linux versions. This can be changed by
>> setting FD_SETSIZE or __FD_SETSIZE to a larger number. We have ran
>> tests where we were able to change the __FD_SETSIZE value in
>> /usr/src/...linuxversion../linux/include/linux/posix_types.h . The
>> fix worked well.
>>
>> Unfortunately, this isn't a good solution because a software update to
>> another linux version will invalidate our fix. We've tried various
>> mechanisms to set FD_SETSIZE or __FD_SETSIZE in socket.c but with no
>> luck. Has anyone else had this problem and came up with a good
>> fix? Or is there a better solution?
>>
>> Barry Nicholson
>> Niceng.com



--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: FD_SETSIZE with large #s of files/ports in use

Hiroshi Inoue writes:
> Another way is to use poll() instead of select().

You really need to go in that direction. Changing FD_SETSIZE is
completely unworkable --- it will break various libc ABI details.

regards, tom lane

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: FD_SETSIZE with large #s of files/ports in use

Tom Lane wrote:
> Hiroshi Inoue writes:
>> Another way is to use poll() instead of select().
>
> You really need to go in that direction. Changing FD_SETSIZE is
> completely unworkable --- it will break various libc ABI details.

Thanks.
I already made a patch to use poll() if the function is available.
I would post it later.

regards,
Hiroshi Inoue


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: FD_SETSIZE with large #s of files/ports in use

This is a multi-part message in MIME format.
--------------020207050907070506050806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
>> Hi,
>>
>> Could you please try the attached patch?
>
> Oops it doesn't seem to work.
> Another way is to use poll() instead of select().

OK I made a patch to use poll().
Please #define HAVE_POLL e.g. in config.h and try the attached patch.

regards,
Hiroshi Inoue

--------------020207050907070506050806
Content-Type: text/plain;
name="socket.diff"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="socket.diff"

ZGlmZiAtYyAuLi9wc3Fsb2RiYy9zb2NrZXQuYyAuL3NvY2tldC5jCioqKiAu
Li9wc3Fsb2RiYy9zb2NrZXQuYwkyMDEwLTAxLTExIDA5OjU2OjE4LjYwNTAw
MDAwMCArMDkwMAotLS0gLi9zb2NrZXQuYwkyMDEwLTA1LTE5IDE3OjAzOjEw
Ljg3NDAwMDAwMCArMDkwMAoqKioqKioqKioqKioqKioKKioqIDM1MCwzNTcg
KioqKgotLS0gMzUwLDM2MiAtLS0tCiAgCWlmIChjb25uZWN0KHNlbGYtPnNv
Y2tldCwgKHN0cnVjdCBzb2NrYWRkciAqKSAmKHNlbGYtPnNhZHJfYXJlYSks
IHNlbGYtPnNhZHJfbGVuKSA8IDApCiAgCXsKICAJCWludAlyZXQsIG9wdHZh
bDsKKyAJCWludAl3YWl0X3NlYyA9IDA7CisgI2lmZGVmCUhBVkVfUE9MTAor
IAkJc3RydWN0IHBvbGxmZCBmZHM7CisgI2Vsc2UKICAJCWZkX3NldAlmZHMs
IGV4Y2VwdF9mZHM7CiAgCQlzdHJ1Y3QJdGltZXZhbAl0bTsKKyAjZW5kaWYg
LyogSEFWRV9QT0xMICovCiAgCQlzb2NrbGVuX3QJb3B0bGVuID0gc2l6ZW9m
KG9wdHZhbCk7CiAgCQl0aW1lX3QJdF9ub3csIHRfZmluaXNoID0gMDsKICAJ
CUJPT0wJdG1fZXhwID0gRkFMU0U7CioqKioqKioqKioqKioqKgoqKiogMzc3
LDM5MSAqKioqCiAgCQl7CiAgCQkJdF9ub3cgPSB0aW1lKE5VTEwpOwogIAkJ
CXRfZmluaXNoID0gdF9ub3cgKyB0aW1lb3V0OwohIAkJCXRtLnR2X3NlYyA9
IHRpbWVvdXQ7CiEgCQkJdG0udHZfdXNlYyA9IDA7CiAgCQl9CiAgCQlkbyB7
CiAgCQkJRkRfWkVSTygmZmRzKTsKICAJCQlGRF9aRVJPKCZleGNlcHRfZmRz
KTsKICAJCQlGRF9TRVQoc2VsZi0+c29ja2V0LCAmZmRzKTsKICAJCQlGRF9T
RVQoc2VsZi0+c29ja2V0LCAmZXhjZXB0X2Zkcyk7CiAgCQkJcmV0ID0gc2Vs
ZWN0KChpbnQpIHNlbGYtPnNvY2tldCArIDEsIE5VTEwsICZmZHMsICZleGNl
cHRfZmRzLCB0aW1lb3V0ID4gMCA/ICZ0bSA6IE5VTEwpOwogIAkJCWdlcnJu
byA9IFNPQ0tfRVJSTk87CiAgCQkJaWYgKDAgPCByZXQpCiAgCQkJCWJyZWFr
OwotLS0gMzgyLDQwNCAtLS0tCiAgCQl7CiAgCQkJdF9ub3cgPSB0aW1lKE5V
TEwpOwogIAkJCXRfZmluaXNoID0gdF9ub3cgKyB0aW1lb3V0OwohIAkJCXdh
aXRfc2VjID0gdGltZW91dDsKICAJCX0KICAJCWRvIHsKKyAjaWZkZWYJSEFW
RV9QT0xMCisgCQkJZmRzLmZkID0gc2VsZi0+c29ja2V0OworIAkJCWZkcy5l
dmVudHMgPSBQT0xMT1VUOworIAkJCWZkcy5yZXZlbnRzID0gMDsKKyAJCQly
ZXQgPSBwb2xsKCZmZHMsIDEsIHRpbWVvdXQgPiAwID8gd2FpdF9zZWMgKiAx
MDAwIDogLTEpOyAKKyAjZWxzZQorIAkJCXRtLnR2X3NlYyA9IHdhaXRfc2Vj
OworIAkJCXRtLnR2X3VzZWMgPSAwOwogIAkJCUZEX1pFUk8oJmZkcyk7CiAg
CQkJRkRfWkVSTygmZXhjZXB0X2Zkcyk7CiAgCQkJRkRfU0VUKHNlbGYtPnNv
Y2tldCwgJmZkcyk7CiAgCQkJRkRfU0VUKHNlbGYtPnNvY2tldCwgJmV4Y2Vw
dF9mZHMpOwogIAkJCXJldCA9IHNlbGVjdCgoaW50KSBzZWxmLT5zb2NrZXQg
KyAxLCBOVUxMLCAmZmRzLCAmZXhjZXB0X2ZkcywgdGltZW91dCA+IDAgPyAm
dG0gOiBOVUxMKTsKKyAjZW5kaWYgLyogSEFWRV9QT0xMICovCiAgCQkJZ2Vy
cm5vID0gU09DS19FUlJOTzsKICAJCQlpZiAoMCA8IHJldCkKICAJCQkJYnJl
YWs7CioqKioqKioqKioqKioqKgoqKiogMzk4LDQwNyAqKioqCiAgCQkJCWlm
ICh0X25vdyA9IHRpbWUoTlVMTCksIHRfbm93ID49IHRfZmluaXNoKQogIAkJ
CQkJdG1fZXhwID0gVFJVRTsKICAJCQkJZWxzZQohIAkJCQl7CiEgCQkJCQl0
bS50dl9zZWMgPSAobG9uZykgKHRfZmluaXNoIC0gdF9ub3cpOwohIAkJCQkJ
dG0udHZfdXNlYyA9IDA7CiEgCQkJCX0KICAJCQl9CiAgCQl9IHdoaWxlICgh
dG1fZXhwKTsKICAJCWlmICh0bV9leHApCi0tLSA0MTEsNDE3IC0tLS0KICAJ
CQkJaWYgKHRfbm93ID0gdGltZShOVUxMKSwgdF9ub3cgPj0gdF9maW5pc2gp
CiAgCQkJCQl0bV9leHAgPSBUUlVFOwogIAkJCQllbHNlCiEgCQkJCQl3YWl0
X3NlYyA9IHRfZmluaXNoIC0gdF9ub3c7CiAgCQkJfQogIAkJfSB3aGlsZSAo
IXRtX2V4cCk7CiAgCQlpZiAodG1fZXhwKQoqKioqKioqKioqKioqKioKKioq
IDQ3NSw0ODIgKioqKgotLS0gNDg1LDQ5NiAtLS0tCiAgc3RhdGljIGludCBT
T0NLX3dhaXRfZm9yX3JlYWR5KFNvY2tldENsYXNzICpzb2NrLCBCT09MIG91
dHB1dCwgaW50IHJldHJ5X2NvdW50KQogIHsKICAJaW50CXJldCwgZ2Vycm5v
OworICNpZmRlZglIQVZFX1BPTEwKKyAJc3RydWN0IHBvbGxmZAlmZHM7Cisg
I2Vsc2UKICAJZmRfc2V0CWZkcywgZXhjZXB0X2ZkczsKICAJc3RydWN0CXRp
bWV2YWwJdG07CisgI2VuZGlmIC8qIEhBVkVfUE9MTCAqLwogIAlCT09MCW5v
X3RpbWVvdXQgPSBUUlVFOwogIAogIAlpZiAoMCA9PSByZXRyeV9jb3VudCkK
KioqKioqKioqKioqKioqCioqKiA0ODgsNDkzICoqKioKLS0tIDUwMiw1MTMg
LS0tLQogIAkJbm9fdGltZW91dCA9IFRSVUU7CiAgI2VuZGlmIC8qIFVTRV9T
U0wgKi8KICAJZG8geworICNpZmRlZglIQVZFX1BPTEwKKyAJCWZkcy5mZCA9
IHNvY2stPnNvY2tldDsKKyAJCWZkcy5ldmVudHMgPSBvdXRwdXQgPyBQT0xM
T1VUIDogUE9MTElOOworIAkJZmRzLnJldmVudHMgPSAwOworIAkJcmV0ID0g
cG9sbCgmZmRzLCAxLCBub190aW1lb3V0ID8gLTEgOiByZXRyeV9jb3VudCAq
IDEwMDApOyAKKyAjZWxzZQogIAkJRkRfWkVSTygmZmRzKTsKICAJCUZEX1pF
Uk8oJmV4Y2VwdF9mZHMpOwogIAkJRkRfU0VUKHNvY2stPnNvY2tldCwgJmZk
cyk7CioqKioqKioqKioqKioqKgoqKiogNDk4LDUwMyAqKioqCi0tLSA1MTgs
NTI0IC0tLS0KICAJCQl0bS50dl91c2VjID0gMDsKICAJCX0KICAJCXJldCA9
IHNlbGVjdCgoaW50KSBzb2NrLT5zb2NrZXQgKyAxLCBvdXRwdXQgPyBOVUxM
IDogJmZkcywgb3V0cHV0ID8gJmZkcyA6IE5VTEwsICZleGNlcHRfZmRzLCBu
b190aW1lb3V0ID8gTlVMTCA6ICZ0bSk7CisgI2VuZGlmIC8qIEhBVkVfUE9M
TCAqLwogIAkJZ2Vycm5vID0gU09DS19FUlJOTzsKICAJfSB3aGlsZSAocmV0
IDwgMCAmJiBFSU5UUiA9PSBnZXJybm8pOwogIAlpZiAocmV0cnlfY291bnQg
PCAwKQpkaWZmIC1jIC4uL3BzcWxvZGJjL3NvY2tldC5oIC4vc29ja2V0LmgK
KioqIC4uL3BzcWxvZGJjL3NvY2tldC5oCTIwMTAtMDEtMTEgMDk6NTY6MzEu
MzcxMDAwMDAwICswOTAwCi0tLSAuL3NvY2tldC5oCTIwMTAtMDUtMTkgMTM6
MTU6NTAuMTU3MDAwMDAwICswOTAwCioqKioqKioqKioqKioqKgoqKiogMjEs
MjYgKioqKgotLS0gMjEsMjkgLS0tLQogIAogICNpZm5kZWYgV0lOMzIKICAj
ZGVmaW5lCVdTQUFQSQorICNpZmRlZglIQVZFX1BPTEwKKyAjaW5jbHVkZSA8
cG9sbC5oPgorICNlbmRpZiAvKiBIQVZFX1BPTExfSCAqLwogICNpbmNsdWRl
IDxzeXMvdHlwZXMuaD4KICAjaW5jbHVkZSA8c3lzL3NvY2tldC5oPgogICNp
bmNsdWRlIDxzeXMvdW4uaD4K

--------------020207050907070506050806
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

--------------020207050907070506050806--

Re: FD_SETSIZE with large #s of files/ports in use

This is a multi-part message in MIME format.
--------------060903060803040209000806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Yes, we'll try the patch in the morning.

Tom, what libc details will be broken by setting FD_SETSIZE to a larger
number? I'm curious for my own knowledge base. I can see where it
might cause 'data' sizes to grow which might break thinks. Anything else?

Barry Nicholson

On 05/19/2010 06:44 PM, Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
>> Hiroshi Inoue wrote:
>>> Hi,
>>>
>>> Could you please try the attached patch?
>>
>> Oops it doesn't seem to work.
>> Another way is to use poll() instead of select().
>
> OK I made a patch to use poll().
> Please #define HAVE_POLL e.g. in config.h and try the attached patch.
>
> regards,
> Hiroshi Inoue
>
>
>
>


--------------060903060803040209000806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




">


Yes, we'll try the patch in the morning.



Tom, what libc details will be broken by setting FD_SETSIZE to a larger
number?   I'm curious for my own knowledge base.   I =
can see where it
might cause 'data' sizes to grow which might break thinks.  Anything
else?



Barry Nicholson



On 05/19/2010 06:44 PM, Hiroshi Inoue wrote:

Hiroshi
Inoue wrote:

Hiroshi Inoue wrote:

Hi,




Could you please try the attached patch?

Oops it doesn't seem to work.


Another way is to use poll() instead of select().

OK I made a patch to use poll().


Please #define HAVE_POLL e.g. in config.h and try the attached patch.




regards,


Hiroshi Inoue

Re: FD_SETSIZE with large #s of files/ports in use

"B. Nicholson" writes:
> Tom, what libc details will be broken by setting FD_SETSIZE to a larger
> number? I'm curious for my own knowledge base. I can see where it
> might cause 'data' sizes to grow which might break thinks. Anything else?

I'm not too sure, honestly. I can tell you that this exact point came up
recently on a Red Hat internal mailing list, and no less an authority
than Ulrich Drepper said "you can't do that, it'll break things". He
didn't say exactly what though. It's possible that on non-glibc-based
platforms, you could get away with it.

regards, tom lane

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: FD_SETSIZE with large #s of files/ports in use

Tom Lane wrote:

> "B. Nicholson" writes:
> > Tom, what libc details will be broken by setting FD_SETSIZE to a larger
> > number? I'm curious for my own knowledge base. I can see where it
> > might cause 'data' sizes to grow which might break thinks. Anything else?
>
> I'm not too sure, honestly. I can tell you that this exact point came up
> recently on a Red Hat internal mailing list, and no less an authority
> than Ulrich Drepper said "you can't do that, it'll break things". He
> didn't say exactly what though. It's possible that on non-glibc-based
> platforms, you could get away with it.

I'd guess that as FD_SETSIZE is a macro used at compile time
(including compile time of libc) and that without jumping
through hoops in the implementation changing it later will
cause inconsistencies between the size of structures or arrays
passed between the application and libc.

At the risk of topic drift and providing more information than
people want to know (but think of the archives! :-), here is
some additional information.

Summary:

a) you can't rely on changing FD_SETSIZE for select(2)
b) poll(2) is preferable to select(2) for performance
c) interfaces that should perform better than either select(2)
and poll(2) are:

i. /dev/poll (Solaris, HP-UX)
ii. epoll (Linux)
iii. pollset (AIX)
iv. kqueue (*BSDs)

There is some hope of maintaining portability across this
newer, non-standardised set of interfaces with libevent.

PostgreSQL seems to use poll() if it's available in some
places, and select() in others. (And I don't know about the
Windows code.)

For small numbers of file descriptors especially on non-hot
code paths, it's not going to matter. In general it would be
IMHO nice to use poll() consistently when it's available
and not emulated via select().

Whether there is a performance gain to be had by using the
non-portable solutions I don't know: it would be interesting
to see some measurements, but I wouldn't necessarily expect
so: the newer interfaces (certainly /dev/poll) were driven by
the needs of high performance web servers with high numbers of
connections which may be a too-different use case to
PostgreSQL to see a notable benefit.

Based on some micro benchmarks I did some years back (on now
non-current OS releases which I shall not name) I would not
assume that the relative performance of these interfaces (that
is, select v. poll v. whatever alternative local enhancement
has been created) would be consistent: you may find systems
with relatively well performing select(2) implementations.

Re point (a):

For POSIX, FD_SETSIZE is not documented as being changeable by
the application, implying that it shouldn't be altered by
portable applications:

http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/s elect.h.html

That's from POSIX a.k.a. IEEE Std 1003.1, 2004 Edition, a.k.a. the
"Single Unix Specification Version 3".

I'm no Linux guru, so I'll take Tom's and Ulrich Drepper's
word for the behaviour there.

Some operating systems _do_ allow applications to alter
FD_SETSIZE, including at least HP-UX:

http://docs.hp.com/en/B2355-60130/select.2.html

Re point(b):

It is "well known" that poll(2) is more efficient than
select(2) as the sets of file descriptors don't have to be
reset before each call as they are in select(2).

(Sorry, no good reference to hand, and I'm sure someone's had
an exception somewhere, at least when poll() was emulated via
select()!).

Re point(c):

i. /dev/poll was introduced in Solaris 7, and added some time
later to HP-UX:

http://developers.sun.com/solaris/articles/polling_efficient .html
http://docs.hp.com/en/B2355-60130/poll.7.html

ii. Linux preferred to introduce epoll(7):

http://www.kernel.org/doc/man-pages/online/pages/man4/epoll. 4.html

iii. IBM preferred pollset for AIX:

http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com. ibm.aix.basetechref/doc/basetrf1/pollset.htm

iv. The *BSDs have developed kqueue; originally in FreeBSD but
adopted by NetBSD and OpenBSD:

http://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2
http://netbsd.gw.com/cgi-bin/man-cgi?kqueue++NetBSD-5.0
http://www.openbsd.org/cgi-bin/man.cgi?query=kqueue&sektion= 2

v. libevent:

http://www.monkey.org/~provos/libevent/

Regards,

Giles

P.S. No, this isn't the nightmare. I just woke _up_ from the
nightmare. :-) Now, back to sleep ...

--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: FD_SETSIZE with large #s of files/ports in use

This is a multi-part message in MIME format.
--------------070303040909070902000106
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hiroshi:

Works great! We've ran thousands of tests through the system with your
poll change. No problems.
We're going to run some more tests (just to make sure) in the morning.
Our goal with the tests in the morning are to really load test the
system (5000+ connections all doing selects randomly). Nice job.

Barry Nicholson

On 05/19/2010 06:44 PM, Hiroshi Inoue wrote:
> Hiroshi Inoue wrote:
>> Hiroshi Inoue wrote:
>>> Hi,
>>>
>>> Could you please try the attached patch?
>>
>> Oops it doesn't seem to work.
>> Another way is to use poll() instead of select().
>
> OK I made a patch to use poll().
> Please #define HAVE_POLL e.g. in config.h and try the attached patch.
>
> regards,
> Hiroshi Inoue
>
>
>
>

--------------070303040909070902000106
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




">


Hiroshi:



Works great!  We've ran thousands of tests through the system with y=
our
poll change.  No problems.

We're going to run some more tests (just to make sure) in the
morning.   Our goal with the tests in the morning are to really=
load
test the system (5000+ connections all doing selects randomly).   Ni=
ce
job.



Barry Nicholson  



On 05/19/2010 06:44 PM, Hiroshi Inoue wrote:

Hiroshi
Inoue wrote:

Hiroshi Inoue wrote:

Hi,




Could you please try the attached patch?

Oops it doesn't seem to work.


Another way is to use poll() instead of select().

OK I made a patch to use poll().


Please #define HAVE_POLL e.g. in config.h and try the attached patch.




regards,


Hiroshi Inoue