•  

Announcement

Announcement Module
Collapse
No announcement yet.

Best way to utilize SSD

Page Title Module
Move Remove Collapse
Conversation Detail Module
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts

  • Best way to utilize SSD

    #1
    So we just bought some sweet new servers based on advice we received from some MySQL guys at Sun... Here are the server spec's:

    Sun Fire X4275
    • Xeon X5560 2.80Ghz, 1333Mhz FSB, 2x8Mb L2 (x2)
    • 300Gb 15k SAS HDD (x6)
    • 32Gb SSD (x2)
    • 72Gb Ram (4Gbx18 1333Mhz)

    These are set up using MMM behind a Coyote Point load balancer (basically just does round robin with the read IP's in MMM to distribute the reads).

    The main database which runs off these servers has around 256 million records (47Gb). It is 100% MyIsam and is read-only (although we do a batch import after hours once per month)

    The largest table space usage:
    Type Usage
    Data 16,194.2 MiB
    Index 7,689.8 MiB
    Total 23,884.0 MiB

    I'm wondering how we should utilize the solid state drives. Our data itself is eventually going to be to big to store on them and I tried moving the the *.MYI files to them and sym linking them from the data directory but didn't really perceive any sort of performance increase.

    The other disks are set up in RAID 1 and I'm using deadline scheduler. I'm not sure if deadline is the best for SSD disks though either, I've not found any suggestions online.

    Anyone have any suggestions?
    Tags: None

  • #2
    You can't say much without knowing the kind of queries you run with frequency etc, and the kind of data they need.

    Why so little SSD space?

    Comment


    • #3
      Your data is smaller than RAM, so disks are pretty much immaterial for MyISAM.

      Comment


      • #4
        xaprb wrote on Mon, 01 March 2010 18:36

        Your data is smaller than RAM, so disks are pretty much immaterial for MyISAM.



        This will eventually not be true.

        We didn't purchase more SSD space as it wasn't cost effective. It was recommended that we use them for index storage.

        Here are some performance metrics from one of those mysqltuner scripts for db1 (db2 is roughly the same)(I know the scripts aren't ideal but, should give some idea of load etc).

        -------- Performance Metrics -------------------------------------------------
        [--] Up for: 8d 19h 49m 12s (5M q [7.196 qps], 1M conn, TX: 2B, RX: 226M)
        [--] Reads / Writes: 99% / 1%
        [--] Total buffers: 32.0G global + 64.2M per thread (50 max threads)
        [OK] Maximum possible memory usage: 35.2G (49% of installed RAM)
        [OK] Slow queries: 0% (104/5M)
        [OK] Highest usage of available connections: 26% (13/50)
        [OK] Key buffer size / total MyISAM indexes: 32.0G/24.9G
        [OK] Key buffer hit rate: 99.0% (227M cached / 2M reads)
        [!!] Query cache efficiency: 0.0% (0 cached / 893K selects)
        [OK] Query cache prunes per day: 0
        [OK] Sorts requiring temporary tables: 0% (1 temp sorts / 65K sorts)
        [OK] Temporary tables created on disk: 0% (112 on disk / 1M total)
        [OK] Thread cache hit rate: 99% (13 created / 1M connections)
        [!!] Table cache hit rate: 10% (37 open / 362 opened)
        [OK] Open file limit used: 0% (65/8K)
        [OK] Table locks acquired immediately: 100% (301K immediate / 301K locks)
        [!!] InnoDB data size / buffer pool: 12.5M/8.0M

        Comment

        Working...
        X