You could setup a hot and cold based allocation system, put your highly accessed (hot) indexes on the SSDs and then the rest on the spinning disk.
Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: [email protected] web: www.campaignmonitor.com On 11 July 2014 23:35, John Smith <[email protected]> wrote: > Right now I have 4 boxes... > > 2x 32 cores 200GB RAM with RAID10 SATA1 + the Fusion IO > > 2x 24 cores 96GB RAM with RAID10 SAS but regular mechanical drives. > > I only test them as pairs. So it's clusters of 2 > > On the surface all searches seem to perform quite close to each other. > Only when looking at the stats in HQ and Marvel the true story is told. For > instance most warnings with Fusion IO are yellow at best. While with the > SAS Raid 10 (Regular SATA Drives) they reach red. > > I'm hopping I can get some regular SSDs to put on the SAS boxes and see if > it's better. > > > > > On Thursday, 10 July 2014 18:00:11 UTC-4, Jörg Prante wrote: >> >> Did you consider SSD with RAID0 (Linux, ext4, noatime) and SAS2 (6g/s) >> or SAS3 (12g/s) controller? >> >> I have for personal use at home LSI SAS 2008 of 4x128g SSD RAID0 with >> sustained 800 MB/s write and 950 MB/s read, on a commodity dual AMD C32 >> socket server mainboard. I do not test with JMeter but on this single node >> hardware alone I observe 15k bulk index operations per second, and >> scan/scroll over 45m docs takes less than 70 min. >> >> I'm waiting until SAS3 is affordable for me. For the future I have on my >> list: LSI SAS 3008 HBA and SAS3 SSDs. For personal home use, Fusion IO is >> too heavy for my wallet. Even for commercial purpose I do not consider it >> as a cost effective solution. >> >> Just a note: if you want spend your money to accelerate ES, buy RAM. You >> will get more performance than from drives. Reason is the lower latency. >> Low latency will speed up applications like ES more than the fastest I/O >> drive is able to. That reminds me that I'm waiting since ages for DDR4 >> RAM... >> >> Jörg >> >> >> On Thu, Jul 10, 2014 at 10:13 PM, John Smith <[email protected]> wrote: >> >>> Using 1.2.1 >>> >>> I know each system and functionality is different but just curious when >>> people say buy SSDs for ES, what types of SSDs are they buying? >>> >>> Fortunately for me I had some Fusion IO cards to test with, but just >>> wondering if it's worth the price and if I should look into off the shelf >>> SSDs like Samsung EVOs using SAS instead of pure SATA. >>> >>> So far from my testing it seems that all search operation regardless of >>> the drive type seem to return in the same amount of time. So I suppose >>> caching is playing a huge part here. >>> >>> Though when looking at the HQ indexing stats like query time, fetch >>> time, refresh time etc... The Fusion IO fares a bit better then regular >>> SSDs using SATA. >>> >>> For instance refresh time for Fusion IO is 250ms while for regular SSDs >>> (SATA NOT SAS, will test SAS when I get a chance) it's just above 1 second. >>> Even with fusion IO I do see some warnings on the index stats, but >>> slightly better then regular SSDs >>> >>> Some strategies I picked for my indexes... >>> - New index per day, plus routing by "user" >>> - New index per day for monster users. >>> >>> Using JMeter to test... >>> - Achieved 3,500 index operations per second (Not bulk) avg document >>> size 2,500 bytes (Fusion IO seemed to perform a bit better) >>> - Created a total of 25 indexes totaling over 100,000,000 documents >>> anywhere between 3,000,000 to 5,000,000 documents per index. >>> - Scroll query to retrieve 15,000,000 documents out of the 100,000,000 >>> (all indexes) took 25 minutes regardless of drive type. >>> >>> P.s: I want to index 2,000,000,000 documents per year so about 4,000,000 >>> per day. So you can see why Fusion IO could be expensive :) >>> >>> Thanks >>> >>> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elasticsearch" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/elasticsearch/24928d08-6354-4661-8164-9ff665709285% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/elasticsearch/24928d08-6354-4661-8164-9ff665709285%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/13e20470-a38e-4d89-be98-5d6e26b0f0aa%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/13e20470-a38e-4d89-be98-5d6e26b0f0aa%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624ZGLqqPhK85TEvVtq%3DbO4g1VLrwuD%3DZphp2tdi71bFoog%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
