On Wed, Aug 24, 2011 at 10:23 AM, Andy wrote:
> According to the specs for database storage:
> "Random 4KB arites: Up to 600 IOPS"
> Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not much
> faster than mechanical disks.
Keep in mind that the 600 IOPS is over the entire disk. p
On Wed, 24 Aug 2011, Tomas Vondra wrote:
On 24 Srpen 2011, 21:42, gnuo...@rcn.com wrote:
My point. The firmware and MS have been faster to support TRIM than *nix,
linux in particular. Those that won't/can't move to a recent kernel don't
get TRIM.
Faster? Windows 7 was released on October
On 08/24/2011 01:42 PM, David Boreham wrote:
On 8/24/2011 11:41 AM, Greg Smith wrote:
I've measured the performance of this drive from a couple of
directions now, and it always comes out the same. For PostgreSQL,
reading or writing 8K blocks, I'm seeing completely random workloads
hit a wo
On 24 Srpen 2011, 21:42, gnuo...@rcn.com wrote:
>
>
> Original message
>>Date: Wed, 24 Aug 2011 21:32:16 +0200
>>From: pgsql-performance-ow...@postgresql.org (on behalf of "Tomas Vondra"
>> )
>>Subject: Re: [PERFORM] Reports from SSD purgatory
>>To: gnuo...@rcn.com
>>Cc: pgsql-performance
On 24 Srpen 2011, 21:41, Merlin Moncure wrote:
> On Wed, Aug 24, 2011 at 2:32 PM, Tomas Vondra wrote:
>> On 24 Srpen 2011, 20:48, gnuo...@rcn.com wrote:
>>> Also, given that PG is *nix centric and support for TRIM is win
>>> centric,
>>> having that makes a big difference in performance.
>>
>> Win
On 8/24/2011 1:32 PM, Tomas Vondra wrote:
Why is that important? It's simply a failure of electronics and it has
nothing to do with the wear limits. It simply fails without prior
warning from the SMART.
In the cited article (actually in all articles I've read on this
subject), the failures we
Original message
>Date: Wed, 24 Aug 2011 21:32:16 +0200
>From: pgsql-performance-ow...@postgresql.org (on behalf of "Tomas Vondra"
>)
>Subject: Re: [PERFORM] Reports from SSD purgatory
>To: gnuo...@rcn.com
>Cc: pgsql-performance@postgresql.org
>
>On 24 Srpen 2011, 20:48, gnuo...@rcn.
On Wed, Aug 24, 2011 at 2:32 PM, Tomas Vondra wrote:
> On 24 Srpen 2011, 20:48, gnuo...@rcn.com wrote:
>
>> It's worth knowing exactly what that means. Turns out that NAND quality
>> is price specific. There's gooduns and baduns. Is this a failure in the
>> controller(s) or the NAND?
>
> Why is
On 24 Srpen 2011, 20:48, gnuo...@rcn.com wrote:
> It's worth knowing exactly what that means. Turns out that NAND quality
> is price specific. There's gooduns and baduns. Is this a failure in the
> controller(s) or the NAND?
Why is that important? It's simply a failure of electronics and it ha
On Wed, 24 Aug 2011, Merlin Moncure wrote:
On Wed, Aug 24, 2011 at 1:48 PM, wrote:
Also, given that PG is *nix centric and support for TRIM is win
centric, having that makes a big difference in performance.
one point about TRIM -- no raid controller that I know of supports
trim, which s
On Wed, Aug 24, 2011 at 1:48 PM, wrote:
>
>
> Original message
>>Date: Mon, 15 Aug 2011 19:49:52 -0400
>>From: pgsql-performance-ow...@postgresql.org (on behalf of Greg Smith
>>)
>>Subject: [PERFORM] Reports from SSD purgatory
>>To: "pgsql-performance@postgresql.org"
>>
>>News update
Original message
>Date: Mon, 15 Aug 2011 19:49:52 -0400
>From: pgsql-performance-ow...@postgresql.org (on behalf of Greg Smith
>)
>Subject: [PERFORM] Reports from SSD purgatory
>To: "pgsql-performance@postgresql.org"
>
>News update for anyone else who's trapped like me, waiting for
On Wed, Aug 24, 2011 at 12:23 PM, Andy wrote:
> According to the specs for database storage:
> "Random 4KB arites: Up to 600 IOPS"
> Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not much
> faster than mechanical disks.
> Has anyone done any performance benchmark of 320 used as
On Wed, Aug 24, 2011 at 5:21 AM, Venkat Balaji wrote:
> But, the information vanishes if the application logs off.
> I am looking for an alternative to track the total amount of the connections
> with the host IPs through a Cron job.
> What could be the frequency of cron ?
> I know the best is usi
Original message
>Date: Wed, 24 Aug 2011 11:25:27 -0600
>From: pgsql-performance-ow...@postgresql.org (on behalf of David Boreham
>)
>Subject: Re: [PERFORM] Intel 320 SSD info
>To: pgsql-performance@postgresql.org
>
> On 8/24/2011 11:23 AM, Andy wrote:
>
> According to the spec
On 8/24/2011 11:41 AM, Greg Smith wrote:
I've measured the performance of this drive from a couple of
directions now, and it always comes out the same. For PostgreSQL,
reading or writing 8K blocks, I'm seeing completely random workloads
hit a worst-case of 20MB/s; that's just over 2500 IOPS
On 08/24/2011 01:23 PM, Andy wrote:
According to the specs for database storage:
"Random 4KB arites: Up to 600 IOPS"
Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not
much faster than mechanical disks.
Has anyone done any performance benchmark of 320 used as a DB storage?
On 8/24/2011 11:23 AM, Andy wrote:
According to the specs for database storage:
"Random 4KB arites: Up to 600 IOPS"
Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not
much faster than mechanical disks.
The underlying (Flash block) write rate really is terrible (and slower
On 8/24/2011 11:17 AM, Merlin Moncure wrote:
hm, I think they need to reconcile those numbers with the ones on this
page:
http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-320-series.html
600 write ips vs 3.7k/23k.
They do provide an explanation (and what I find
According to the specs for database storage:
"Random 4KB arites: Up to 600 IOPS"
Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not much
faster than mechanical disks.
Has anyone done any performance benchmark of 320 used as a DB storage? Is it
really that slow?
On Wed, Aug 24, 2011 at 11:58 AM, David Boreham wrote:
>
> Apologies if this has already been posted here (I hadn't seen it before
> today, and
> can't find a previous post).
> This will be of interest to anyone looking at using SSDs for database
> storage :
> http://www.intel.com/content/www/us/e
> I suppose you could use tcpdump on a separate system with a mirrored switch
> port and have it log TCP SYN and FIN packets on port 5432 to your database
> server only. Keeps all I/O off your database server.
> tcpdump -w port5423.log -n "tcp and port 5432 and tcp[tcpflags] &
> (tcp-syn|tcp-f
Apologies if this has already been posted here (I hadn't seen it before
today, and
can't find a previous post).
This will be of interest to anyone looking at using SSDs for database
storage :
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-enterprise-server-storage-applicati
On Wed, Aug 24, 2011 at 9:33 AM, Greg Smith wrote:
> On 08/24/2011 07:07 AM, Venkat Balaji wrote:
>
>> But, if put log_connections to on and log_disconnections to on wouldn't
>> the Postgres be logging in lot of data ?
>> Will this not be IO intensive ? I understand that this is the best way,
>>
On 08/24/2011 07:07 AM, Venkat Balaji wrote:
But, if put log_connections to on and log_disconnections to on
wouldn't the Postgres be logging in lot of data ?
Will this not be IO intensive ? I understand that this is the best
way, but, would want to know if there is an other way to reduce IO (
m
On Wed, 2011-08-24 at 16:51 +0530, Venkat Balaji wrote:
> But, the information vanishes if the application logs off.
>
That's why you need a tool to track this.
> I am looking for an alternative to track the total amount of the connections
> with the host IPs through a Cron job.
>
If you only
But, the information vanishes if the application logs off.
I am looking for an alternative to track the total amount of the connections
with the host IPs through a Cron job.
What could be the frequency of cron ?
I know the best is using log_connections and log_disconnections parameters,
but, inf
pg_stat_activity keeps track of all this information.
select * from pg_stat_activity where datname='databasename';
Venkat Balaji wrote:
Thanks Guillaume !!
But, if put log_connections to on and log_disconnections to on
wouldn't the Postgres be logging in lot of data ?
Will this not be IO
Thanks Guillaume !!
But, if put log_connections to on and log_disconnections to on wouldn't the
Postgres be logging in lot of data ?
Will this not be IO intensive ? I understand that this is the best way, but,
would want to know if there is an other way to reduce IO ( may be through
queries to ca
On Wed, 2011-08-24 at 13:05 +0530, Venkat Balaji wrote:
> Hello Everyone,
>
> I am working on an alert script to track the number of connections with the
> host IPs to the Postgres cluster.
>
> 1. I need all the host IPs making a connection to Postgres Cluster (even for
> a fraction of second).
Hello Everyone,
I am working on an alert script to track the number of connections with the
host IPs to the Postgres cluster.
1. I need all the host IPs making a connection to Postgres Cluster (even for
a fraction of second).
2. I would also want to track number of IDLE connections, IDLE IN
TRANS
31 matches
Mail list logo
