I've been assisting Mark with the benchmarking of these new servers.
The drop off in both throughput and CPU utilisation that we've been
observing as the client count increases has let me to investigate which
lwlocks are dominant at different client counts.
I've recompiled postgres with Andres L
On 31/07/14 00:47, Tomas Vondra wrote:
On 30 Červenec 2014, 14:39, Tom Lane wrote:
"Tomas Vondra" writes:
On 30 ??ervenec 2014, 3:44, Mark Kirkwood wrote:
While these numbers look great in the middle range (12-96 clients),
then
benefit looks to be tailing off as client numbers increase. Also
Hi Tomas,
Unfortunately I think you are mistaken - disabling the stats collector
(i.e. track_counts = off) means that autovacuum has no idea about
when/if it needs to start a worker (as it uses those counts to decide),
and hence you lose all automatic vacuum and analyze as a result.
With res
On Wed, Jul 30, 2014 at 4:01 AM, Tomas Vondra wrote:
> On 30 Červenec 2014, 5:12, Josh Berkus wrote:
>> Explained here:
>> https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf
>>
>> 13 out of 15 tested SSD's had various kinds of corruption on a power-out.
>>
>> (thanks, Neil!)
Greetings,
Any help regarding a sporadic and mysterious issue would be much appreciated.
A pgsql function for loading in data is occasionally taking 12+ hours
to complete versus its normal 1-2 hours, due to a slow down at the
CREATE TEMP TABLE step. During slow runs of the function, the temp
tabl
On 30 Červenec 2014, 14:39, Tom Lane wrote:
> "Tomas Vondra" writes:
>> On 30 ??ervenec 2014, 3:44, Mark Kirkwood wrote:
>>> While these numbers look great in the middle range (12-96 clients),
>>> then
>>> benefit looks to be tailing off as client numbers increase. Also
>>> running
>>> with no sta
"Tomas Vondra" writes:
> On 30 Äervenec 2014, 3:44, Mark Kirkwood wrote:
>> While these numbers look great in the middle range (12-96 clients), then
>> benefit looks to be tailing off as client numbers increase. Also running
>> with no stats (and hence no auto vacuum or analyze) is way too scary!
I think I understand what happened now. I have another monitor script
runs periodically and calls pg_cancel_backend and pg_terminate_backend
for those hanging update sqls. However for some unkown reason the cancle
and termiante command doesn't work at pgsql side for those update sqls.
But I th
On 30 Červenec 2014, 5:12, Josh Berkus wrote:
> Explained here:
> https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf
>
> 13 out of 15 tested SSD's had various kinds of corruption on a power-out.
>
> (thanks, Neil!)
Well, only four of the devices supposedly had a power-loss pr
On 30 Červenec 2014, 3:44, Mark Kirkwood wrote:
>
> While these numbers look great in the middle range (12-96 clients), then
> benefit looks to be tailing off as client numbers increase. Also running
> with no stats (and hence no auto vacuum or analyze) is way too scary!
I assume you've disabled s
10 matches
Mail list logo
