On Thursday, April 20, 2017 3:38:42 AM EDT Tim Kane wrote:
> The pgss_query_texts.stat still wants to live in the default *pg_stat_tmp*
> directory, wether by design or not.. but that's a non-issue for me now.
A 30 second investigation of the source seems to indicate that that directory
is hardc
Ok, fixed it! :D
Posting here for future me (others like me).
It would seem (having not read kernel source) that increasing the kernel
buffer sizes (rmin_default / rmin_max) does *not* take effect for any
processes that are *already* bound or listening to a port/socket. I had
previously assumed t
> On 19 Apr 2017, at 20:36, Tim Kane wrote:
>
> Well, this is frustrating..
> The buffer drops are still occurring - so I thought it worth trying use a
> ramdisk and set stats_temp_directory accordingly.
>
> I've reloaded the instance, and can see that the stats directory is now being
> popul
Well, this is frustrating..
The buffer drops are still occurring - so I thought it worth trying use a
ramdisk and set *stats_temp_directory* accordingly.
I've reloaded the instance, and can see that the stats directory is now
being populated in the new location. *Except* - there is one last file
Okay, so I've run an strace on the collector process during a buffer drop
event.
I can see evidence of a recvfrom loop pulling in a *maximum* of 142kb.
While I've had already increased rmem_max, it would appear this is not
being observed by the kernel.
rmem_default is set to 124kb, which would exp
Hi all,
I'm seeing sporadic (but frequent) UDP buffer drops on a host that so far
I've not been able to resolve.
The drops are originating from postgres processes, and from what I know -
the only UDP traffic generated by postgres should be consumed by the
statistics collector - but for whatever r
