Tag Info

Hot answers tagged

11

I know this is probably a hypothetical question... But the IT world really doesn't work that way. There are realistic constraints to consider, plus other things that can influence IOPS... 50GB and 100GB disks don't really exist anymore. Think more: 72, 146, 300, 450, 600, 900, 1200GB in enterprise disks and 500, 1000, 2000, 3000, 4000, 6000GB in ...


10

I'm a big fan of iozone myself


7

Use RAID6 over RAID10. For mainly read based I/O loads the throughput should be similar when the array is not degraded, you get better redundancy (any two drives can fail at the same time with R6, R10 can not survice if both failed drives are on the same leg (so can only survive four of the six two drive failure combinations in a 4-drive array, I'm not sure ...


7

FC and 10GE use different bit encoding mechanisms, which dictates the maximum theoretical throughput for either. FC uses 8b/10b encoding while 10GE uses 64b/66b. What this means is that within the 8 Gbps for FC, 10 bits are sent for each byte of actual data. On the 8.5 Gbps (full underlying line rate of 8G FC) this comes out to 8.5 * 0.8 = 6.8 Gigabits ...


7

Each drive can do 180 random IOPs. Is your workload totally random? I bet what you're seeing is sequential reads/writes.


7

To answer your question directly - all other things being equal = no change whatsoever when GB changes. You don't measure IOPS with GB. You use the seek time and the latency. I could re-write it all here but these examples below do all that already and I would simply be repeating it: http://www.ryanfrantz.com/posts/calculating-disk-iops/ ...


7

One place where there is a direct relationship between disk size and IOPS is in the Amazon AWS Cloud and other "cloudy services". Two types of AWS services (Elastic Block Store and Relational Database Service ) provide higher IOPS for larger disk sizes. Note that this is an artificial restriction placed by Amazon on their services. There is no ...


6

I think this is doing exactly what you're asking it to. You're throttling the I/O capabilities and profile of your VMs, causing them to perform poorly. Don't do this. Micromanaging resources at the individual VM level can have unintended consequences and will complicate future troubleshooting. My recommendation is to NOT try to outsmart the VMware ...


6

I would consider a hybrid solution which could be achieved with OpenSolaris, SolarisExp 11, OpenIndiana, or Nexenta. Hybrid pool would be a lot less costly, and with a few thousand bucks worth of RAM, you will have your 150k+ IOPS with mostly normal spinning disks. At Nexenta we have many, many customers who do just exactly this. ZFS is a robust filesystem, ...


6

The exact number, or even a reasonable estimate, would be impossible to guess based on this information. Many server grade disks have published number; but the RAID system may or may not take full advantage of the disks. The RAID HBAs generally also have some published benchmarks. Extrapolating from these is the best guess you'll get without testing an ...


6

Generally you will want to use a benchmark utility like fio. When measuring the amount of IOPs keep in mind that you need to think about things such as: Block size If these are writes, reads, or a mixture If the activity is sequential or random The number of outstanding requests These will all effect the amount of IOPs you get. You want to make sure ...


5

"Disk Transfers/sec" is the metric you're looking for. It counts discrete I/O operations, rather than throughput.


5

You would need to rewrite your data to the expanded zpool in order to rebalance it. Otherwise, as time passes, your writes will be distributed across the entire pool.


5

That you are missing is the context. IOPS is FULLY RANDOM. A copy is not random but sequential. Hard discs get slow when the head is moved - the IOPS basically assumes, properly measured, IO that is randomly distributed over the complete disc platter (or at least a large part of it). Yes, you are a lot faster when copying a disc. SADLY that is totally ...


5

It really depends on what you'll be doing with the system. And this is generic advice; the same for a Windows Storage Spaces solution, versus ZFS, versus traditional filesystems. Think about it like this: You're using a bunch of capacity-optimized disks, so whatever you're doing seems like it involves a large amount of data. When people talk about large ...


5

The short answer is that harddrives optimizes retrieval of data if there are more than one IO request outstanding, which usually increases throughput at the expense of latency. NCQ does this, reorders IO requests to optimize throughput. SSD:s work differently from mechanical drives since they have parallell flash chips to store data on. Ie if you issue one ...


4

Different tools display this information in different ways. The terminology isn't consistent. I don't think you should use bonnie++ alone to determine IOPS. Or if you do choose to use it (or another tool like iozone), you can meter the activity with any number of utilities to capture I/O operations-per-second. So I may run bonnie++ -d /data -u root -n ...


4

I should point out that IOPS are not a great measurement of speed on sequential writes, but lets just go with it. I suspect the seek and write times of disk heads is pretty consistent despite the size of the disks. 20 years ago we we're all using 60GB disks with (roughly - certainly not linearly) the same read/write speeds. I am making an educated guess ...


4

You're throwing terms together that do not belong. The 8Gb HBA is only meant for talking to a storage device. You would either run fiber directly from the server into a storage controller, or into a fiberchannel switch which can distribute those connections. Your server would then use the onboard 1Gb or 10Gb ethernet ports for data connections only. The ...


4

I would assume it is caching. You said write cache is disabled, but I see the "Array accelerator cache", I'm not familiar with that - but memory caching would explain bursts of high throughput.


4

iostat is the right way to get IO count over time. If you want totals since boot, you can read those from /proc/disktats. Description of the file format is in your kernel's Documentation/iostats.txt (or here). This information is also available per-device or per-partition in /sys/block/${DEVICE}/stat and /sys/block/${DEVICE}/${DEVPART}/stat (substitute ...


4

Just buy two FusionIO Octal cards and mirror them - far simpler, far faster (might be a bit more expensive however).


4

It's strange that there doesn't seem to be a standard for IOPS measurement in Linux. These questions come up often when people are asked to provide an estimate of IOPS for capacity planning or storage sizing. I end up using multiple tools to gain this info. First, you'll need to generate a load using the method of your choice; either a representative ...


4

Answering your key questions: RAID 6 vs. RAID 10: You almost certainly do not need to worry about IOPS if you are using SSDs as primary storage. SLC vs. MLC: There are subtler differences. If you are going to use MLC, I would suggest buying Intel. The Intel 320 series has a SMART counter that you can use to track the wear level percentage and replace the ...


3

150k IOPS with 4k blocks is 585 Mb/s throughput. Make sure your controller and backplane can handle that. As for raid, remember that protection against SSD failures is all it'll buy you. A controller failure (or memory fault, processor outage, or failure of any other single point of failure on the server) will render your data unusable. Keeping another ...


3

Without more details this is tough to answer. 2 things that come to mind are: the 3par is rebalancing the lun someone else is using the san 2 is the most likely scenario. Remember that the 3par, by default, shares all disks across all luns (much like the HP EVA). This means that one application or server could bring your performance thru the floor.


3

I would not ignore best practices in terms of different spindles. Here are my reasons. For the OS, having the OS on a different spindle has benefits in terms of backups, restorals and upgrades that have nothing to do with I/O performance. In terms of logs, there are two reasons for putting Exchange stores and logs on different spindles. The first is ...


3

Would gluster help me with I/O limits of harddrives, if I chained a lot of machines together? If it would, it would replace that with.... network limits. I mean, seriously - if you distrivute IO over 50 machines, your network needs to handle that. If you run inti IO limits, not just storage area limits (i.e. terabyte) the proper solution is rather to ...


3

Looks to me that you haven't aligned the test volume on Win2K3. By default Win2K3 doesn't align partitions so the MBR causes an offset that results in a penalty on writes that cross stripe boundaries. Win2K8 automatically aligns on 1Meg which generally matches most RAID stripe boundaries. Recent Ubuntu builds also automatically align partitions starting at a ...


3

There is no reason for the zvol to be stored on the initial devices only. If you enlarge the pool, ZFS will span the updated data on all of the available underlying devices. There is no fixed partitioning with ZFS.



Only top voted, non community-wiki answers of a minimum length are eligible