On Fri, May 24, 2013 at 3:44 PM, wrote:
> Total runtime: 1606.728 ms 1.6 seconds <- very good response time
> improvement
>
> (7 rows)
>
> Questions:
>
> Any concerns with setting these conf variables you recommended; work_mem,
> random_page_cost dbserver wide (in postgresql,conf)?
>
> Thanks so
1.) Server settingmemory: 32960116kB = 32GB2.) Current Postgresql configuration settings of note in my environment.enable_hashjoin=offwork_mem = 16MB #random_page_cost-4.0 <- defaultmaintenance_work_mem=256MBshared_buffers = 8GBserverdb=# explain analyze select count(*) as y0_ from SARS_ACTS this_
Thanks for reply.
>This could easily be caused by something outside of the test itself.
Background processes. A monitoring system kicking in to write some data to
disk will cause a drop like this.
>Three things you could look into to try and track down the issue:
>-Did you turn on log_checkpoin
On 5/23/13 7:39 AM, Sachin D. Bhosale-Kotwal wrote:
So i am not getting why spike occure at *12:09:14 *only*.*
This could easily be caused by something outside of the test itself.
Background processes. A monitoring system kicking in to write some data
to disk will cause a drop like this.
T
On 5/22/13 2:45 PM, Shaun Thomas wrote:
That read rate and that throughput suggest 8k reads. The queue size is
270+, which is pretty high for a single device, even when it's an SSD.
Some SSDs seem to break down on queue sizes over 4, and 15 sectors
spread across a read queue of 270 is pretty hash
