Read more on PRWeb via Yahoo! News

Read more on PRWeb via Yahoo! News

Read more on PRWeb via Yahoo! News

Read more on TechWorld

To see how performance drops with decreasing free space, let’s run sysbench fileio random write benchmark with different file sizes.

For test I took FusionIO 320GB Duo MLC card, with software stripping between two cards, and there if graph how throughput depends on available free space ( the bigger file – the less free space)

The system specification and used scripts you can see on Benchmark Wiki

On graph you can see two line ( yes, there are two lines, even they are almost identical).
First line is result when FusionIO is formatted to use full capacity, and second line is for case when I use additional space reservation ( 25% in this case, that is 240GB available). There is no difference in this case, however additional over-provisioning protects you from overusing space, and keeps performance on corresponding level.

It is clear the maximal throughput strongly depends on available free space.
With 100GiB utilization we have 933.60 MiB/sec,
with 150GiB (half of capacity) 613.48 MiB/sec and
with 200GiB it drops to 354.37 MiB/sec, which is 2.6x times less comparing with 100GiB.

So returning to question how to run proper benchmark, the result significantly depends what percentage of space on card is used, the results for 100GiB file on 160 GB card, will be different from the results for 100GiB file on 320 GB card.

Beside free space, the performance also depends on garbage collector algorithm by itself, and the card from different manufactures will show different results. Some new coming cards make high performance in case with high space utilization as competitive advantage, and I am going to run the same analysis on different cards.

Entry posted by Vadim |
No comment

Add to: | | | |

View full post on MySQL Performance Blog

I still hear an awful lot of stories from owners whose databases are running two slow. In my experience, the three main places to look for problems are:

1. Faulty Database Design
2. Bad Queries
3. Server factors

Faulty Database Design

Proper database design is the single most important factor for the ensuring performance and maintainability of the database. Here is what you need to answer when designing a table: Can I reduce the size of data that each row will have? Here is what you can do:

1. Use unsigned numeric values when the application will not store negative numbers. Like the “quantity ordered” of an item in an ecommerce application is never going to be -$125.

2. Use Variable length values instead of fixed length value i.e. used varchar instead of char.

3. Do not use unnecessarily large field sizes. For most ecommerce application “unsigned smallint” is more than enough to store inventory count. A field described as “unsigned smallint” can store a max value of 65535.

4. Don’t ignore normalization; its helps prevent unnecessary repetition of data. The part B of this is, don’t overuse normalization. If the table will not grow in size significantly, there is no point in normalization. For example, if the user table has just 20 rows (i.e. 20 employees in a company), all attempts of normalization are wasted.

5. Use Keys. Don’t decide keys by “The customer id has to be indexed in the order table”. If the order table is being searched 90% of the times by “order date”, it makes more sense to index “order date”.

Remember, how a table will be used should determine how it is designed. Spending time here will save years of frustration.

Bad Queries

It sounds too good to be true but you wont believe the number of developers out there who completely suck at writing queries. There are two types of bad queries:

a) Unnecessary Queries: These are the queries that shouldn’t have been made in the first place. The only way to avoid this is asking, “Do I really need this data?”

b) Inefficient Queries: These are the queries that do not use the underlying table structure or MySQL functions in the correct way.

Here is a starting point to start looking at problem areas:

1. Unnecessary usage of “Select * “statements when the entire processing is being done on a single column. The more data is fetched from the server the more work MySQL has to do and more bandwidth it takes.

2. Using sub-query instead of a join. On a properly designed database, joins are incredibly fast. Using sub-queries just shows a lack of knowledge.

3. Improper use of Keys. This is especially valid for range checks. Remember to use the “Explain” statement to check the usage of keys and then use the “use key” statement in your “where” clauses to force key usage.

Server Factors

Everything done correctly, there still may be some server factors that may be causing the system to be slow. These are:

1. Hardware related
2. Server configuration related

Here is what you can do about the hardware:

1. The more RAM is on the system the better it is. MySQL frequently fetches data from the RAM and more the RAM is on the system, the better it is.

2. Buy the fastest possible RAM! A slower RAM is just irony.

3. Once you are settled with the RAM size and speed, look for processing speed. MySQL can use multiple processors.

Once you are satisfied with the hardware, there are a set of variables in “my.cnf” that you must look at:

a) key_buffer_size: This describes the memory available to store the index keys. The default is 8 MB but you can set it to 25% of the RAM.

b) query_cache_size: This value is by default 0. if you have a lot of repeating queries like in reporting applications etc, make sure you set this value high.

c) table_open_cache: This determines the number of table descriptors that MySQL will keep in the cache. The default value is 64. But, if you have 100 users accessing a table concurrently then this value should atleast be 100. You also have to take into considerations joins etc. Thus, this value should also be kept high.

I hope this article will take one step further in unlocking the mystery of slow servers and help solve some of the problems.

Read more on PRWeb via Yahoo! News