Re: Got no response last time on setsockopt post, so I thought I would reiterate.
От | Tom Lane |
---|---|
Тема | Re: Got no response last time on setsockopt post, so I thought I would reiterate. |
Дата | |
Msg-id | 27664.1181607129@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Got no response last time on setsockopt post, so I thought I would reiterate. ("Dann Corbit" <DCorbit@connx.com>) |
Ответы |
Re: Got no response last time on setsockopt post, so I thought I would reiterate.
|
Список | pgsql-hackers |
"Dann Corbit" <DCorbit@connx.com> writes: > May I suggest: > http://www-didc.lbl.gov/TCP-tuning/setsockopt.html > http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windows.html I poked around on those pages and almost immediately came across http://www.psc.edu/networking/projects/tcptune/ which appears more up-to-date than the other pages, and it specifically recommends *against* setting SO_SNDBUF or SO_RCVBUF on modern Linuxen. So that's one fairly large category where we probably do not want this. You have not even made it clear whether you were increasing the sizes in the server-to-client or client-to-server direction, and your handwaving about the test conditions makes it even harder to know what you are measuring. I would think for instance that local vs remote connections make a big difference and might need different tuning. BTW, if we look at this issue we ought to also look at whether the send/recv quantum in libpq and the backend should be changed. It's been 8K for about ten years now ... regards, tom lane
В списке pgsql-hackers по дате отправления: