Thanks for the tip. I'll also check in the lock, it's a customer setup and we
don't get access to the box very frequently.
Also
The code was something like this.
loop
inserting data into the tmptbl
analyze tmptbl
end loop
if I replace this with
loop
inserting data
The potential breakthrough here with the 320 is consumer grade SSD
performance and price paired with high reliability.
On Mon, Mar 28, 2011 at 7:54 PM, Andy angelf...@yahoo.com wrote:
This might be a bit too little too late though. As you mentioned there really
isn't any real performance
Hello Greg, list,
On 2011-03-28 22:21, Greg Smith wrote:
Today is the launch of Intel's 3rd generation SSD line, the 320
series. And they've finally produced a cheap consumer product that
may be useful for databases, too! They've put 6 small capacitors onto
the board and added logic to
On Mar 29, 2011, at 12:13 AM, Merlin Moncure wrote:
My own experience with MLC drives is that write cycle expectations are
more or less as advertised. They do go down (hard), and have to be
monitored. If you are writing a lot of data this can get pretty
expensive although the cost dynamics
2011/3/29 Jeff thres...@torgo.978.org:
On Mar 29, 2011, at 12:13 AM, Merlin Moncure wrote:
My own experience with MLC drives is that write cycle expectations are
more or less as advertised. They do go down (hard), and have to be
monitored. If you are writing a lot of data this can get
On Mar 29, 2011, at 10:16 AM, Jeff wrote:
Now that all sounds awful and horrible until you get to overall
performance, especially with reads - you are looking at 20k random
reads per second with a few disks. Adding in writes does kick it
down a noch, but you're still looking at 10k+
Dear list,
we have got a web application and when people log in some information is
written to the user tables. We have around 500 active users, but at the
most 5 people are logged in at the same time. From times to times people
log in and then the application is not responsive any more.
This can be resolved by partitioning the disk with a larger write spare area so
that the cells don't have to by recycled so often. There is a lot of
misinformation about SSD's, there are some great articles on anandtech that
really explain how the technology works and some of the differences
On 2011-03-29 16:16, Jeff wrote:
halt for 0.5-2 seconds, then resume. The fix we're going to do is
replace each drive in order with the rebuild occuring between each.
Then we do a security erase to reset the drive back to completely
empty (including the spare blocks kept around for writes).
On Mar 29, 2011, at 12:12 PM, Jesper Krogh wrote:
Are you replacing the drives with new once, or just secure-erase and
back in?
What kind of numbers are you drawing out of smartmontools in usage
figures?
(Also seeing some write-stalls here, on 24 Raid50 volumes of x25m's,
and
have been
Both the X25-M and the parts that AnandTech reviews (and a pretty thorough one
they do) are, on a good day, prosumer. Getting review material for truly
Enterprise parts, the kind that STEC, Violin, and Texas Memory will spend a
year to get qualified at HP or IBM or Oracle is really hard to
On 03/29/2011 06:34 AM, Yeb Havinga wrote:
While I appreciate the heads up about these new drives, your posting
suggests (though you formulated in a way that you do not actually say
it) that OCZ products do not have a long term reliability. No factual
data. If you have knowledge of sandforce
Lars Feistner feist...@uni-heidelberg.de wrote:
The log tells me that certain update statements take sometimes
about 3-10 minutes. But we are talking about updates on tables
with 1000 to 1 rows and updates that are supposed to update 1
row.
The top possibilities that come to my mind
On 2011-03-29 18:50, Jeff wrote:
we have some new drives that we are going to use initially, but
eventually it'll be a secure-erase'd one we replace it with (which
should perform identical to a new one)
What enclosure controller are you using on the 24 disk beast?
LSI ELP and a HP
I've got some functionality that necessarily must scan a relatively large
table. Even worse, the total workload is actually 3 similar, but different
queries, each of which requires a table scan. They all have a resultset
that has the same structure, and all get inserted into a temp table. Is
On Tue, Mar 29, 2011 at 7:16 PM, Samuel Gendler
sgend...@ideasculptor.com wrote:
Is there any performance benefit to revamping the workload such that it issues
a single:
insert into (...) select ... UNION select ... UNION select
as opposed to 3 separate insert into () select ... statements.
I
On Wed, Mar 30, 2011 at 01:16, Samuel Gendler sgend...@ideasculptor.com wrote:
I've got some functionality that necessarily must scan a relatively large
table
Is there any performance benefit to revamping the workload such that it issues
a single:
insert into (...) select ... UNION select
On Tue, Mar 29, 2011 at 5:05 PM, Marti Raudsepp ma...@juffo.org wrote:
On Wed, Mar 30, 2011 at 01:16, Samuel Gendler sgend...@ideasculptor.com
wrote:
You can trick Postgres (8.3.x and newer) into doing it in parallel
anyway: open 3 separate database connections and issue each of these
On 3/29/11 3:16 PM, Samuel Gendler wrote:
I've got some functionality that necessarily must scan a relatively large
table. Even worse, the total workload is actually 3 similar, but different
queries, each of which requires a table scan. They all have a resultset that
has the same structure,
19 matches
Mail list logo
