Rick James wrote:
>
>When writing a random block, RAID-5 does not need to touch all the
>drives, only the one with parity. Suitable XORs will update it
>correctly. So, a write hits 2 drives, whether you have RAID-5 or -10.
Only if the other blocks happen to be in the cache, otherwise a read is
2013/7/30 Rick James
> Elevator... If the RAID _controller_ does the Elevator stuff, any OS
> optimizations are wasted.
> And there have been benchmarks backing that up. (Sorry, don't have any
> links handy.)
>
> RAID 5/10 ... The testing I have done shows very little difference.
> However, y
On 30-07-2013 01:16, Rick James wrote:
Elevator... If the RAID _controller_ does the Elevator stuff, any OS
optimizations are wasted. And there have been benchmarks backing that
up. (Sorry, don't have any links handy.)
RAID 5/10 ... The testing I have done shows very little difference.
...r
Monday, July 29, 2013 3:38 PM
> To: Rick James; will...@techservsys.com; mysql@lists.mysql.com
> Subject: RE: hypothetical question about data storage
>
> Rick James wrote:
> >
> >For MySQL + RAID, a Linux elevator strategy of 'deadline' or 'noop' is
&g
Rick James wrote:
>
>For MySQL + RAID, a Linux elevator strategy of 'deadline' or 'noop' is
>optimal. (The default, 'cfq', is not as good.)
I should look into those again at some point. Do you have a brief word as to
why they're better?
>A RAID controller with multiple drives striped (and opt
64TB limit per PARTITION.
> -Original Message-
> From: william drescher [mailto:will...@techservsys.com]
> Sent: Saturday, July 27, 2013 4:32 AM
> To: mysql@lists.mysql.com
> Subject: Re: hypothetical question about data storage
>
> On 7/26/2013 6:58 PM, Chris Knipe wrote:
>
On 7/26/2013 6:58 PM, Chris Knipe wrote:
The issue that we have identified is caused by seek time - hundreds of
clients simultaneously searching for a single file. The only real way
to explain this is to run 100 concurrent instances of bonnie++ doing
random read/writes... Your disk utilization a
2013/07/27 00:58 +0200, Chris Knipe
I would definately consider the md5 checksum as a
PK (char(32) due to the hex nature),
Well, not that it greatly matters, but you could convert it to BINARY(16).
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
will have seeks.
>>
>>No, adding more RAM won't help much. Here's an argument:
>>Suppose your data is 20 times as big as the buffer pool and you are
>>doing random fetches (MD5, etc). Then 1/20 of fetches are cached; 95%
>>cache miss. Estimated time: 0.95
1/20 of fetches are cached; 95%
>cache miss. Estimated time: 0.95 * 100ms = 95ms.
>Now you double your RAM. 1/10 cached -> 90% cache miss -> 90ms average
>-> Not much improvement over 95.
>
>> -Original Message-----
>> From: ckn...@savage.za.org [mailto:ck
ilto:ckn...@savage.za.org] On Behalf Of
> Chris Knipe
> Sent: Friday, July 26, 2013 12:30 AM
> To: Johan De Meersman
> Cc: mysql
> Subject: Re: hypothetical question about data storage
>
> Hi All,
>
> Thanks for the responces, and I do concur. I was taking a stab in the
&
ge -
>> From: "Chris Knipe"
>> To: mysql@lists.mysql.com
>> Sent: Thursday, 25 July, 2013 11:53:53 PM
>> Subject: hypothetical question about data storage
>>
>> Hi all,
>>
>> We run an VERY io intensive file application service. Curren
mysql@lists.mysql.com
> Sent: Thursday, 25 July, 2013 11:53:53 PM
> Subject: hypothetical question about data storage
>
> Hi all,
>
> We run an VERY io intensive file application service. Currently, our
> problem is that our disk spindles are being completely killed due to
Hi,
Sorry but mysql is not the address of it , use riak instead of mysql
With riak which is key and value based , all keys are on memory and just
only one seek enough to handle it
Consider to use riak
VM
On 7/26/13 12:53 AM, "Chris Knipe" wrote:
>Hi all,
>
>We run an VERY io intensive file appli
Hi all,
We run an VERY io intensive file application service. Currently, our
problem is that our disk spindles are being completely killed due to
insufficient SEEK time on the hard drives (NOT physical read/write speeds).
We have an directory structure where the files are stored based on the MD5
Hi
I am using Disk Based MySql Cluster 6.2.15 . I would like to know one
important thing regarding MySQL cluster.
I am using two servers with 1.8 TB each. What will be the maximum space
available for Data Storage when both machines are in cluster?
Suppose if i add one more machine with
Are there any way to configure MySQL 4.1 to use more than one drive for
data files (for example, in a RAID 5 solution)? If so, could somebody
point me at the right information.
Regards,
-JF
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http:/
On Thu, Jul 12, 2001 at 01:51:29AM +0200, Werner Stuerenburg wrote:
>
> Im my understanding, you are storing images. AFAIK, images should
> not be stored in the db but in the filesystem.
There's nothing wrong with doing it, as long as you understand what
you're doing. After all, images are (from
Im my understanding, you are storing images. AFAIK, images should
not be stored in the db but in the filesystem. You store only the
filename and other data (time etc.) in the db. There are some
remarks on this at php.net and other places, as this question is
posed often.
Sie schrieben am Mittwoch
Hi,
I am trying to store fax images in mysql (they are about 1K per page), which
comes in as binary data. I am able to use mysql_escape_string(data, fax,
sizeof(fax)) to get the data into mysql, as well as only escaping ' and \
for the query string. I have tried both longblob and longtext mysql
"Dhirendra Pal Singh" <[EMAIL PROTECTED]> wrote:
> Some one told me that the upper limit of MySql data storage is 1 Gb of
data.
The limit depends on the operating system. On some operating systems it's 2
GB, on others it's much higher. Search the mailing list at
ht
Hi all,
Some one told me that the upper limit of MySql data storage is 1 Gb of data. As I am
new so I am not sure of this. If any gurus of MySql can please tell me about it, it
would be great.
Regards
Dp
Balcom Systems & Technologies, Inc.
(408)468-6608
22 matches
Mail list logo
