GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

Fiber Channel or SAS

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

  • Fiber Channel or SAS

    We are running a MySQL server right now that sits at about 35% iowait due to the load on the server. Currently we are using it primarily for network monitoring so there is a large percentage of db writes, heavily used databases are MyISAM.

    Our current server is a hyperthreaded Supermicro that just isn't cutting it, onboard ICH6R raid 1, but lagging.

    The server averages about 135 queries/s, but these spike at the five minute polling interval to around 500/600 q/s, with spikes as high as 2000 q/s. This totals around 12 million/day.

    Wondering if anyone has experience and make any recommendations on whether a solid onboard array of SAS drives would be faster, than a SAN type solution using fiber channel or iSCSI? In both cases I am planning on striping the drives and running master-slave replication.

    Links to some good whitepapers or other comparisons would also work for me.

  • #2
    The answer to IO problems is usually not disk but memory. How much memory do you have and what is database size ?

    Disks are also important for writes and for databases which are too large to well fit in memory. In this case I think SAS is best solution. If you need more than like 6 disks you easily get directly attached you may think about having data partitioned into multiple servers as MySQL may not be able to load a lot of drives efficiently.

    Comment


    • #3
      The databases are not large, under 1GB. A large portion of the traffic is consumed by Cacti poller output on a five minute interval. This data is dumped in, then pulled out to generate rrd files actually used by cacti. I have considered migrating this MyISAM table to a memory table as I believe this would help greatly, however I have been leary of doing so as it includes a text column that I would have to migrate to some other type to do so and I need to ensure that I will not be truncating or otherwise mangling the data in that field.

      Also this is not a dedicated server so I have to be careful how much RAM I am consuming with MySQL.

      Also, I am running replication so there are the binary log writes to consider as well.

      I am trying to size and choose appropriate hardware for a new dedicated MySQL server to handle this current load (with a projected double to triple current levels) and hopefully have the capacity to handle Alvaristar (Alvarion NMS system - recommened to run on Solaris w/ Oracle) at least initially. We will continue to use replication.

      Capacity isn't the greatest concern as I don't foresee this growing beyond 30-50GB at any point in the near future, however HA and io performance are.

      Comment


      • #4
        Well. For your current load you do not really need much of the IO bandwidth.

        Regarding 30-50GB database size It surely depends on the load but generally I'd be looking at server with 16GB of memory and some 6 hard drives as a good one from price/performance standpoint these days.

        Comment

        Working...
        X