The numbers you posted look exactly as I would expect. The first read hits
disk and takes 108ms, the second read hits the cache and takes 27ms.
On Thu, Jun 22, 2017 at 8:40 PM, Sumeet Shukla
wrote:
> Both the first run and subsequent run takes same amount of time.
>
> *First Run:*
>
> "Seq Scan
We've found pghero to be a good first line of defence. It doesn't have
alerting yet, but it's great for a quick high level healthcheck.
Also +1 for Datadog. Extremely flexible and elegant UI + powerful alerting
capabilities.
On Fri, May 26, 2017 at 10:32 AM, Sunkara, Amrutha
wrote:
> We have be
Thanks for the feedback guys. I'm looking forward to the day when we
upgrade to SSDs.
For future reference, the bonnie++ numbers I was referring to are:
Size: 63G
Sequential Output:
396505 K/sec
% CPU 21
Sequential Input:
401117 K/sec
% CPU 21
I'm pretty new to benchmarking hard disks and I'm looking for some advice
on interpreting the results of some basic tests.
The server is:
- Dell PowerEdge R430
- 1 x Intel Xeon E5-2620 2.4GHz
- 32 GB RAM
- 4 x 600GB 10k SAS Seagate ST600MM0088 in RAID 10
- PERC H730P Raid Controller with 2GB cache
me.
>
>
>
> Mike
>
>
>
> *From:* pgsql-performance-ow...@postgresql.org [mailto:
> pgsql-performance-ow...@postgresql.org] *On Behalf Of *Dave Stibrany
> *Sent:* Thursday, March 17, 2016 1:45 PM
> *To:* pgsql-performance@postgresql.org
> *Subject:* [PERFORM] Disk Benc
Thanks for the advice, Rick.
I have an 8 disk chassis, so possible extension paths down the line are
adding raid1 for WALs, adding another RAID10, or creating a 8 disk RAID10.
Would LVM make this type of addition easier?
On Wed, Feb 24, 2016 at 6:08 AM, Rick Otten
wrote:
>
> 1) I'd go with xfs
Thanks Ken, I'll give that a try.
On Thu, Sep 17, 2015 at 4:12 PM, k...@rice.edu wrote:
> On Thu, Sep 17, 2015 at 03:14:43PM -0400, Dave Stibrany wrote:
> > Hi all. I am occasionally seeing really slow update/inserts into a fairly
> > large table. By really slow I mean
.x.x.x(51168) INSERT
What I haven't tried
- more aggressive auto-vacuum
- trying gist table for full text search index instead of gin
- removing full text search altogether (are users don't use it very much)
- rebuilding the production table
- vacuum full
Any help on what the issue might be or how to debug further would be
amazing. I'd like to understand this issue better,
both for my business as well as for my own understanding of databases.
Dave Stibrany
