Will Fusion cache a mysql db installation & other Java tools ?

[esoda]

Hi,

I have bought a 128gb samsung 840 for my 500GB hd/ 8GB ram mac book pro. I do a lot of java development and have such things on it as the following which causes some labor for it:

JBoss Application server
Mysql database server & client
Intellij java development tool (IDE)
xcode

I havent installed the ssd yet but am wondering whether I should use fusion or not.

If I dont use Fusion I guess I would manually put these tools on the SSD. But if I knew fusion would handle them then this would be far easier for me as Im not much of a hardware geek.

Ive read that fusion figures out the most used apps. But not sure how it would deal with a fully fledged database server ?

Anyone any ideas suggestions ?

thanks

 

[Mal]

All Fusion is going to do is look at which files are accessed, and move them. It doesn't know or care what type of files they are, or even if they're data files or an application. Should work fine with the database program.

jW

 

[b0fh666]

not sure if it is a good idea to put database files on SSD... those tend to be big and are written to A LOT, wearing the ssd out pretty fast I suppose.

cheers

 

[leman]

All Fusion is going to do is look at which files are accessed, and move them.

Correction: Fusion works not per-file, but per-block. That is, only frequently accessed parts of files will reside on the SSD, effectively giving you more 'fast' storage space. Besides, it always writes to SSD first and then moves the less frequently accessed blocks to the HDD, not the other way around.

not sure if it is a good idea to put database files on SSD... those tend to be big and are written to A LOT, wearing the ssd out pretty fast I suppose.

There is no difference between a database file he uses for development or any other system database file of which OS X has plenty. I have been writing on average gigabytes of data per day on my old Vertex 2 and it was still in perfect shape after 2 years of abuse.

 

[Mal]

Correction: Fusion works not per-file, but per-block. That is, only frequently accessed parts of files will reside on the SSD, effectively giving you more 'fast' storage space. Besides, it always writes to SSD first and then moves the less frequently accessed blocks to the HDD, not the other way around.

Fair enough. Doesn't affect the usage as discussed, but separates it even further from what type of files are in use.

jW

 

[throAU]

All Fusion is going to do is look at which files are accessed, and move them. It doesn't know or care what type of files they are, or even if they're data files or an application. Should work fine with the database program.

jW

Better than that, Fusion is BLOCK based.

It doesn't know or care what the data is, just whether or not it is "hot".

Hence, it should "work" for any application.

 

[esoda]

As most of the db queries and results are unique wouldnt it mean that fusion would cache tiny parts of the db that would probably not be used again ?

What I really want is the whole db to reside on the ssd so that all queries are faster

Correction: Fusion works not per-file, but per-block. That is, only frequently accessed parts of files will reside on the SSD, effectively giving you more 'fast' storage space. Besides, it always writes to SSD first and then moves the less frequently accessed blocks to the HDD, not the other way around.



There is no difference between a database file he uses for development or any other system database file of which OS X has plenty. I have been writing on average gigabytes of data per day on my old Vertex 2 and it was still in perfect shape after 2 years of abuse.

 

[throAU]

As most of the db queries and results are unique wouldnt it mean that fusion would cache tiny parts of the db that would probably not be used again ?

What I really want is the whole db to reside on the ssd so that all queries are faster

The "unique" queries will still be trawling through many of (or most of) the same records in the database to find the data.

So they will likely be running from cache.

Swap (if needed) will also be cached by the SSD.

But... YMMV.


Caching/tiered storage is generally effective for MOST situations, but it is possible your case is special. I'd test it and find out.

 

[leman]

As most of the db queries and results are unique wouldnt it mean that fusion would cache tiny parts of the db that would probably not be used again ?

The database indexes/locks and frequently accessed blocks will be probably stored on the SSD, that should be good enough. And if each record in your database has the same probability of being accessed, either all the database or none of it will be stored on the SSD Of course, the details of Apple's tiered storage algorithms are pretty much unknown at this point. Usually, such algorithms should do similar or better than manual storage management, because they are based on real stochastic usage patterns (and I bet that its less than 10% of your total data that you actually access on a regular base); but there may be times where you have special needs and the algorithm will have hard time predicting this. A good thing would be to add some sort of priority flag for the files, but than the problem would be communicating this to the underlaying, file-system agnostic Core Storage...

 

[esoda]

ok great, so it seems Fusion is sounding more and more like the way to go.

I am also wondering about the software that I am writing. I work on a big java project where binary files get deleted and rebuilt pretty often. Although the binary files get deleted and created after every compile/build I assume fusion will handle all of this too.

I also run a jboss app server, would Fusion just load all this into the ssd transparently to me ?

The database indexes/locks and frequently accessed blocks will be probably stored on the SSD, that should be good enough. And if each record in your database has the same probability of being accessed, either all the database or none of it will be stored on the SSD Of course, the details of Apple's tiered storage algorithms are pretty much unknown at this point. Usually, such algorithms should do similar or better than manual storage management, because they are based on real stochastic usage patterns (and I bet that its less than 10% of your total data that you actually access on a regular base); but there may be times where you have special needs and the algorithm will have hard time predicting this. A good thing would be to add some sort of priority flag for the files, but than the problem would be communicating this to the underlaying, file-system agnostic Core Storage...