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
> connection could be esta
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 d
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 test,
> involving some p
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 real
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 h
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 h
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 exam
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
> > > q
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 pri
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 secure_wri
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 s
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 x86_
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 her
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 Microsoft, right?
Sure. The b
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 backend process
> for the se
18 matches
Mail list logo
