On Tue, Feb 14, 2017 at 7:03 AM, Nikolai Zhubr wrote:
> 13.02.2017 23:58, Rader, David:
>>
>> How about using pg_isready?
>> https://www.postgresql.org/docs/current/static/app-pg-isready.html
>
> But it doesn't actually communicate with the server AFAIK, just checks if a
>
13.02.2017 23:58, Rader, David:
How about using pg_isready?
https://www.postgresql.org/docs/current/static/app-pg-isready.html
But it doesn't actually communicate with the server AFAIK, just checks
if a connection could be established?
Maybe I should have been more specific.
What I need is
How about using pg_isready?
https://www.postgresql.org/docs/current/static/app-pg-isready.html
--
David Rader
dav...@openscg.com
On Sun, Feb 12, 2017 at 12:23 PM, Nikolai Zhubr wrote:
> Hello all,
>
> In order to locate the problem more precisely, I'd like to prepare a
Hello all,
In order to locate the problem more precisely, I'd like to prepare a
test, involving some ping-like communication between the server and a
test client. That is, I'd like to repeatedly send something valid to the
server and get some valid replies from it, but without any kind of
05.02.2017 22:05, I wrote:
[...]
And yes, running Process Explorer gave some new and unexpected input.
During the period of this strange high load it claims 40% CPU is used by
interrupts (normally 0.01%) and 3% used by backend postgres.exe
(normally approx 0%). I'd guess this means some problem
05.02.2017 17:10, I wrote:
[...]
And yes, running Process Explorer gave some new and unexpected input.
During the period of this strange high load it claims 40% CPU is used by
interrupts (normally 0.01%) and 3% used by backend postgres.exe
(normally approx 0%). I'd guess this means some problem
03.02.2017 22:16, Andres Freund:
[...]
Well, profiling postgres.exe is still beyond my capability at this time
anyway. Instead, I'll try to prepare a most simple client application
example for testing the behaviour in question so that anyone could run it
easily. (And while working on such an
On 2017-02-03 22:17:55 +0300, Nikolai Zhubr wrote:
> 03.02.2017 20:29, Andres Freund:
> [...]
> > > > Could you use process monitor or such to see what the process is doing
> > > > while using a lot of CPU?
> > >
> > > I'm not sure how to do this, especially considering that the process in
> > >
03.02.2017 20:29, Andres Freund:
[...]
Could you use process monitor or such to see what the process is doing
while using a lot of CPU?
I'm not sure how to do this, especially considering that the process in
question is running as a service?
I don't think that stops you, if you have admin
On 2017-02-01 01:02:11 +0300, Nikolai Zhubr wrote:
> 31.01.2017 19:51, Andres Freund:
> [...]
> > > Exactly same trouble with 9.4 (Specifically EDB 9.4.10-1 win32)
> >
> > That's good to know, less because of 519b0757, more because of the latch
> > changes - but they also went in in 9.5...
> >
>
03.02.2017 13:52, I wrote:
[...]
Adding this "Sleep(15)" before "goto retry" into secure_read() has
apparently eliminated the effect at our production server too. That is,
my load-bug-detector has been quiet for > 24hr or more.
Now by adding more debigging stuff into secure_read() and
02.02.2017 2:14, I wrote:
01.02.2017 1:02, I wrote:
[...]
Could you use process monitor or such to see what the process is doing
while using a lot of CPU?
I'm not sure how to do this, especially considering that the process in
question is running as a service?
Now, some more input:
* 9.5.2
01.02.2017 1:02, I wrote:
[...]
Could you use process monitor or such to see what the process is doing
while using a lot of CPU?
I'm not sure how to do this, especially considering that the process in
question is running as a service?
Now, some more input:
* 9.5.2 server running on linux
31.01.2017 19:51, Andres Freund:
[...]
Exactly same trouble with 9.4 (Specifically EDB 9.4.10-1 win32)
That's good to know, less because of 519b0757, more because of the latch
changes - but they also went in in 9.5...
Would it make sense to check some even older ones?
Could you use process
On 2017-01-31 11:45:33 +0300, Nikolai Zhubr wrote:
> 31.01.2017 10:37, I wrote:
> > [...]
> > > > 1. "select localtimestamp" 40 times (As separate requests, one by
> > > > one, but
> > > > no delay inserted in between)
> > > > 2. wait 1/2 second.
> > > > 3. goto 1
> > >
> > > Craig, could this be
31.01.2017 10:37, I wrote:
[...]
1. "select localtimestamp" 40 times (As separate requests, one by
one, but
no delay inserted in between)
2. wait 1/2 second.
3. goto 1
Craig, could this be a side-effect of 519b0757? That's new in 9.5, and
that's directly related to the code paths discussed
31.01.2017 6:43, Michael Paquier wrote:
On Mon, Jan 30, 2017 at 6:16 PM, Nikolai Zhubr wrote:
I'm observing some strange inexplicable effect in 9.5.5 server running on
x86 windows (32-bit windows xp sp3).
Oh, well... You are aware that this is out of support by
On Mon, Jan 30, 2017 at 6:16 PM, Nikolai Zhubr wrote:
> I'm observing some strange inexplicable effect in 9.5.5 server running on
> x86 windows (32-bit windows xp sp3).
Oh, well... You are aware that this is out of support by Microsoft, right?
> That is, CPU usage in
Hello all,
(Hopefully this is right place to post on the subject, otherwise please
let me know.)
I'm observing some strange inexplicable effect in 9.5.5 server running
on x86 windows (32-bit windows xp sp3). That is, CPU usage in backend
process for the session in question starts to grow,
19 matches
Mail list logo