Reply to post:

Keep up with the fast-moving world of all-flash array storage

Guus Leeuw

Dear Chris,

"existing disk array suffer from latency". Really? Sure, if the cache is full and no intelligent pre-fetching is implemented. Ie not very often...

"Virtualising servers and threading application software makes the servers much better at keeping their cores busy processing application code than the old inefficient multi-tasking operating systems such as Windows NT and Unix." The same old inefficient multi-tasking algorithms that live nowadays within the same old operating systems such as Unix are now performing far better, due (in large) to the way modern CPUs are designed and implemented. Virtualising a server does nothing towards making that server run faster. In fact, virtualising a server vs putting that server on the same physical hardware as the hypervisor would logically dictate that the latter will outperform the former!

"Effectively, a two-socket, 12-core server has 24 cores running in parallel" - How is it that a two-socket 12-core server has 24 cores running in parallel? The fact that there is a socket doesn't mean that there is a CPU which may have 12 cores... Be precise, and you will see that in your own head things all of a sudden actually make sense... It has been said before: Don't use one word to mean something else than its very definition. Socket != CPU...

"and imposing a storage array access burden that is roughly 24 times greater overall." In the past we had 24 single CPU single core servers running those applications. Inefficiently, but still the workload was there. The fact that this workload is now centralised on one server that has 24 cores doesn't make a difference in terms of workload for the storage array... The workload may come to the array more densely, but just saying that a 24-times more powerful machine will request 24 times more data is cutting the corner a bit too finely, Chris!

"CPUs access data from main memory in nanoseconds" CPU access data from a storage array in nanoseconds as well, Chris. What you mean to say is that internal memory is accessed far faster than external memory. Accessing external memory that sits on mechanical drives and is accessed directly (by by-passing caches on the way) is slower still.

"In the time it takes for a disk array access, say 7 milliseconds, a waiting CPU core could execute 7 million instructions." 7 milliseconds = 7000 microseconds = 7000000 nanoseconds. Gigaherz stands for the number of cycles in billions per second. so 3 Ghz executes 3 billion parts of instructions per second. Therefore in one millisecond, 3 thousand parts of instructions are executed. Thusly, in 7 milliseconds, 21 thousand parts of instructions are executed. Why "parts of instructions": not every assembler instruction takes just one cycle to complete. 1 nano = 10^-9, 1 milli = 10^-3, one GHz = 10^9, one Mhz = 10^6... just dropping or adding 10^3 is a bit of a leap, IMHO.

quoting Flash array supporters: "and that means your servers can do more"... No, it actually means that your servers do less waiting for data than when compared to traditional storage arrays. Why would one want to put the word "can" in there? "Can" is a statement of uncertainty: they can, but they also cannot... "coulda woulda shoulda; didn't"...

"as you move up the list" - you mean, as you move down the list?!!

"applications such as financial trading and mass online sales" - Please clarify, what are mass online sales? amazon-mass, where a billion people by one product each? resulting in tiny storage transactions, but a whole lot of them, and where each transaction is "old" after 1 month? How is financial trading stacking up against flash-only? Is it jusitified?

What you see a lot of the time, and flash unfortunately helps in this regard, is that people write bad software, that uses a badly designed (and sometimes worse implemented) database, all of which sit on a number of servers not designed for the job at hand, all of which want storage.

Keeping all your data in live tablespaces, and not having appropriate indices, and not managing existing *and* minimising the impact of slow queries, not appropriately paging answer sets, etc etc all make it look as though faster storage is the solution. But let's not forget that faster storage in 80% of the cases will only ever give a 20% better performance for the end-user (if that...)! And for the 20% where faster storage actually makes a big impact: well, that's very often to do with over-saturation at the storage end, so badly managed capacity and system usage...

Flash helps, but let's not just throw flash at a badly written application and make it run faster... It's better to get a good team of people to write and operate good software/databases/servers, than to just chuck millions at a randomly generated problem because some dope forgot to put an index on a textual column somewhere...

I don't quite agree with your conclusion. Flash arrays are good, for sure, but should be implemented where justified, and just across the board because somebody doesn't want to actually fix the software...

Just my two cents,

Guus

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon