> On 19 Apr 2017, at 20:36, Tim Kane <tim.k...@gmail.com> 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 > populated in the new location. Except - there is one last file > (pgss_query_texts.stat) that continues to be updated in the old pg_stat_tmp > path.. Is that supposed to happen? > > > Fairly similar to this guy (but not quite the same). > https://www.postgresql.org/message-id/d6e71befad7beb4fbcd8ae74fadb1265011bb40fc...@win-8-eml-ex1.eml.local > > I can see the packets arriving and being consumed by the collector.. and, > the collector is indeed updating in the new stats_temp_directory.. just not > for that one file. > > > It also failed to resolve the buffer drops.. At this point, I'm not sure I > expected it to. They tend to occur semi-regularly (every 8-13 minutes) but I > can't correlate them with any kind of activity (and if I'm honest, it's > possibly starting to drive me a little bit mad).
This rings a bell for me. I recently had a similar issue in an MMO (Windows) where every 15 minutes I would get a number of consecutive freezes in-game. You could set your alarm by it, so regular. That suddenly went away after I rearranged my home-network (for unrelated reasons), which incidentally moved several connections from the switch the game-system was connected to to another switch. I never pinpointed it to UDP, but then again, TCP would correct for the lost transfers (probably at the cost of UDP traffic). Perhaps you have a switch somewhere that's overburdened? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
