Ok, we are 99% sure as for what is the reason for this situation. Let's say
we have a 1 GB of free memory. Any process (especially postgres, as it is
dedicated server) wants to allocate little more. Kernel has to look through
cached memory to determine which cache pages can be dropped and allocated
It has happened again. Twice today. We have one perf dump. But it is over
600 MB of bzip2-ed data (3.5 GB of plain binary perf data).
We'll go deeper into that, and if we don't come to any conclusions we will
upload it to our anonymous FTP.
Don't know if this perf dump is ok, as it was again trigg
On Fri, Jun 1, 2012 at 2:17 AM, Andrzej Krawiec
wrote:
> 2012/5/31 Robert Haas :
>> How long was strace -s run for to generate this?
>
> Strace - s was running for about 2 minutes.
Hmm, I'm sort of confused then. This only shows a total of 1.815816
seconds of system time, which is a lot less tha
Ok, we've managed to do strace -s during such a situation (see
attached file). I have no clue what can it mean. Only errors count is
quite strange.
Could this
http://postgresql.1045698.n5.nabble.com/high-CPU-usage-for-stats-collector-in-8-2-td1962590.html
affect our environment?
--
Andrzej Krawie
On Thu, May 31, 2012 at 3:29 AM, Andrzej Krawiec
wrote:
> Ok, we've managed to do strace -s during such a situation (see
> attached file). I have no clue what can it mean. Only errors count is
> quite strange.
How long was strace -s run for to generate this?
> Could this
> http://postgresql.104
On Wed, May 23, 2012 at 5:29 AM, Andrzej Krawiec
wrote:
> Cannot strace or gdb on a production system under heavy load (about 100
> transactions per second).
> It's in kernel space not user, so we are unable to anything at this
> particular moment (sometimes even the ssh connection seems to hang f
Cannot strace or gdb on a production system under heavy load (about 100
transactions per second).
It's in kernel space not user, so we are unable to anything at this
particular moment (sometimes even the ssh connection seems to hang for a
while).
We suspect neither autovacuum (although suspected pr
On Fri, May 18, 2012 at 5:09 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6650
> Logged by: Andrzej Krawiec
> Email address: a.kraw...@focustelecom.pl
> PostgreSQL version: 8.4.11
> Operating system: CentOS 6.0 - 2.6.32-220.13.1.el6.x86_64
The following bug has been logged on the website:
Bug reference: 6650
Logged by: Andrzej Krawiec
Email address: a.kraw...@focustelecom.pl
PostgreSQL version: 8.4.11
Operating system: CentOS 6.0 - 2.6.32-220.13.1.el6.x86_64
Description:
Primarily checked on PG 8.4.9 (s
