Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Server performances and disk I/O

  1. #1
    Join Date
    Jun 2006
    Posts
    74

    Default Server performances and disk I/O

    Our administrators have been investigating the reduced server performance as a result of heavy disk I/O and have identified database use, in particular MySQL, as a major component.
    By default, MySQL is not optimized and thus each query requires a search through the database on the disk in order to provide a result. With multiple accounts doing this and multiple queries occurring simultaneously, the disk throughput deteriorates drastically. We are therefore asking that clients install some basic optimization that should not only improve I/O performance, but website responsiveness as well.
    Below are some basic options that you can install for MySQL 4.x and above:
    Code:
    max_connections=50
    table_cache=1000
    thread_cache_size=40
    thread_stack=100K
    wait_timeout=10
    join_buffer=2M
    myisam_sort_buffer_size=6M
    query_cache_size=6M
    read_rnd_buffer_size=2M
    You should also look into index all fields in your tables which are searched or frequently used as conditions. The reason for this is that the indexes are stored in memory and will direct MySQL to search for the necessary information in a more efficient manner.

    Our administrators will keep investigating this issue to learn of other contributing factors. While they are investigating, they will also monitor database usage and if they find accounts which are consistently causing problems, they will take the necessary steps to reduce the accounts impact.

  2. #2
    Join Date
    Aug 2006
    Posts
    1,019

    Default

    It would probably be wise for anyone who decides to make these changes to investigate each of the suggested values in some detail. While in many cases the above suggestions may help performance, nd there are others where it will make things no better and will consume more memory. As with anything, blindly applying changes without some prior investigation is generally a not so great idea.

  3. #3
    Join Date
    Jun 2006
    Location
    Guadalajara, Mexico
    Posts
    541

    Default

    mmm we got an issue here, this goes somewhat against the recommended mysql stripped down configuration, recommended on the wiki

    i hope you can warn us who is having problems and maybe howto measure how much is a dangerous mysql usage (maybe with mytop?) before taking any action on the accounts
    pablasso.com (spanish)

  4. #4
    Join Date
    Aug 2006
    Posts
    1,019

    Default

    Quote Originally Posted by pablasso
    mmm we got an issue here, this goes somewhat against the recommended mysql stripped down configuration, recommended on the wiki
    Well, that's to be expected. You either pay for database usage in CPU time or in memory. Unless you're lucky and have both available, that's when you get truly excellent performance.

  5. #5
    Join Date
    Jun 2006
    Location
    Labrador, Canada
    Posts
    266

    Default

    table_cache = 1000 seems very high and will probably consume a lot of memory. It's more that 15 times higher than the (MySQL 4.1) default of 64.
    D. Robbins
    vpsinfo : server status in your browser
    loadavg : lightweight load, memory & transfer monitoring

  6. #6
    Join Date
    Jun 2006
    Location
    Guadalajara, Mexico
    Posts
    541

    Default

    Quote Originally Posted by jasonaward
    Well, that's to be expected. You either pay for database usage in CPU time or in memory. Unless you're lucky and have both available, that's when you get truly excellent performance.
    yeah, finding a somewhat balanced config is what i'm looking for
    pablasso.com (spanish)

  7. #7
    Join Date
    Jun 2006
    Location
    Labrador, Canada
    Posts
    266

    Default

    Quote Originally Posted by pablasso
    yeah, finding a somewhat balanced config is what i'm looking for
    Use the mysqlreport perl script to get an idea of what your MySQL server is doing. Aim to do things like reduce slow queries and the creation of tmp disk tables (causing disk I/O) without comsuming all your RAM.

    http://hackmysql.com/mysqlreport
    D. Robbins
    vpsinfo : server status in your browser
    loadavg : lightweight load, memory & transfer monitoring

  8. #8
    Join Date
    Jun 2006
    Location
    Guadalajara, Mexico
    Posts
    541

    Default

    thanks for the link sled, i'll give it a try
    pablasso.com (spanish)

  9. #9
    Join Date
    Sep 2006
    Posts
    7

    Default

    Thanks, VPSLink, for keeping an eye on this. The I/O wait was really starting to get to me.

  10. #10
    Join Date
    Dec 2006
    Posts
    19

    Default Disk i/o still terrible - please a solution from the top!

    Is this all VPSLink has to offer us in way of a solution? Those configuations are way outside of normal perams and as someone else mentioned, should not be tampered with unless you are ready to see a reduction in memory or processor time.

    The i/o issue should be something that is fixed on VPSLink's side of life, look at the stats from the past 90 days on realmetrics (sorry cannot post link as I have not posted 15 times I guess)...

    This is not just a blip, this is horrible.

    As a vpslink4 person, i pay for a service and disk i/o is the last issue I would expect to have. The only reason I have not moved is that it is a pain in the arse to move machines and hosts...

    So yes, this is a rant, but i really like everything about VPSLink, just please sort out the disk i/o without asking us to fix it for you!

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •