New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I would leave my provider tout de suite with poor values like that. Pure crap! ;-)
I hope nick fix this asap
@earl said: Just wondering if I'm already getting a DD of 700MB/s on the cached SSD whats the benefit of getting pure SSD?
DD is largely worthless test. Data is pretty rarely stored in a completely contiguous manner on a disk.
Random I/O is what matters most of the time. If you have lots of random write I/O, SSD is going to be vastly superior to cached SSD and it will scale much, much better when I/O load on the node gets high.
Pure ssd will behave the same no matter if your data is hot or cold.
Let me explain:
Frequently accessed data stays in cache and is read very fast. This saves the main raid some reading operations which need seek time and keep the raid busy. Depending on how the customers on the node behave, this could be extremely beneficial, for example the typical small databases for hosting. Those would need a lot of queries on heavy scripts like drupal, for example, a lot of spinning on disk, but with ssd cache will read from cache.
While it is not the same as the data must be put there first for it to be available so, in fact, for a read operation you do 2 (one read from raid and one write in SSD), the fact that in time SSD becomes full with most accessed data (which doesnt go over 10% on a regular node) and the main raid is mostly idle, serving much more infrequent read requests and so, the write speed, even without being cached, is much better as it doesnt have to pause to read so much.
Writing is also done in batches.
The real advantage is SSD is actually the IOPS. If you manage to save most read IOPS from the main raid, then you can either use some 4 big SATA drives in raid 10 and offer a lot of space with acceptable performance, or you can still have a decent SAS2 raid for tremendous performance.
In the first case you can have E3 with fewer customers on it, in the second, dual E5 with 64+ GB ram and the performance will still be better. Unfortunately, space smaller.
Coming back to the difference between full ssd and ssd cached, the difference comes from cold data.
The larger the storage is, the smaller the SSD, the more customers on and the more cold storage they have, you can enter a cycle of doom, the SSD is not large enough, data is written on it and re-written all the time, you can end up with more IOPS than without the cache and the performance will degrade. Even without this situation, if a few people use large chunks of hot data, like torrenters, ppl serving big files, you dont need many to fill the SSD, then the advantage of caching will fade.
With pure SSD, no matter how large the hot data is, for example if you store only one big busy database, the performance will be consistent all the time, during dumps and syncs will not become sluggish accessing cold data, there are situations where SSD only has advantages.
If the host built a well balanced node for the average customer they have, a SSD cached node can behave better at times than a SSD only one, but that is rare and only for raid 1 SSD with 2 drives.
Besides, SSD arrays with 100k IOPS are not impossible to build, they will easily break the 1 GB/s dd barrier, a SSD cached node will never be much faster than the idle array, even if writes are cached (in my view not worth it as I am not sure there will be much saved and at times the array can write faster if has more than just raid 10 out of 4 disks, of course) while cached writing means two writes and takes space on SSD that would be better used for read cache.
If you need really good and consistent performance, you have a lot of hot data, you do often backups and archiving, regularly accessing all your data, if you need crazy IOPS with very busy databases, ram-like access speeds, then go with SSD only.
If you need a lot of storage space for data you dont access much, go with cached.
Mainly for storage-backups, go with regular sata raids.
Mostly write data will not do well with ssd either, if you need fast small writes, go for a raid with a lot of spinners 12-24 and a big ram cache with BBU.
A host will know how to build the nodes, it depends on users to understand what scenario is best for them.
If torrenters go for ssd cached nodes, this will be a problem for the host. It is likely they will since the other solutions are either too expensive or too small space (SSD) or the host will notice and kick them fast due to abuse (regular raid without cache).
Wow Ok thanks everyone for the input, it does make a lot of sense but in real world experience will the difference be really noticeable? I mean really how much quicker will your website load? anyone have one of each node care to give a comparison or opinion if it's worth the difference in drive space?
Actually mine fluctuates between 300MB/s -700MB/s I guess that's the cache working?
@earl DD is really not a good indication of much with regards to a cached node. According to LSI, CacheCade determines on its own what to cache and what to bypass the cache with. It's supposedly based on what is being accessed most frequently.
If you need to hit XXX MB/s all day, every day, then go with SSD. If you just need a VPS that has solid performance, there's no reason not to stick with cached.
Let me know if I didn't answer you fully.
Hopefully you're being facetious?
Short explanation of ssd vs cached, pick ssd if you get kicked from providers over your heavy MySQL usage
Thanks Nick that sums it up alright..
Ha, they go for cached though because they want 100GB databases.
Just kidding,
I get tickets like that sometimes though
I/O OCD
Ordo Carmelitarum Discalceatorum of the Holy I/O or some Obsessive-compulsive disorder?
Yes.
@Ishaq how's that I/O today?
Good.
If you don't mind me asking, how is this going?
@Nick_A
Works better
I have to say nLayer is very fast to respond to emails, but seems to be a bit slow on installing equipment. Perhaps it's their subcontractors or something. I was told last week that they had one more piece of equipment to install over the weekend and that I'd be online and ready to go "early next week" (which would be by today). Now I am being told that the port will be online today but with a temporary, "less-than-ideal" configuration. They'll have to schedule maintenance in a month or so to switch me over to the "permanent" design.
So in short, I should have it up and configured within 48 hours, but it won't be the final setup on their end. How much of a difference that will make is unknown at this point. I guess we'll find out soon.
@Nick_A Sounds great! Thank you!
Well, I've been made a liar once again...
Even with the "interim solution" they won't be able to turn the port on until Friday.
:sigh:
Any updates on nLayer?
The short answer is no. The long answer is they must have some kind of miscommunication between their network engineers and their project management. I keep being given what sound like confident ETAs, and they keep coming and going with no sign of my port being turned on. I've had my cross connect ready to go for the last two weeks, but their engineering department keeps running into further delays. I was told to expect it by the week before last. Then early last week. Then last Friday. Now I have no idea. I'm not going to give anyone another ETA because I don't like misleading people or being made into a liar. I'm sure they're working hard to get this done, but the communication has broken down somewhere along the line. I'm going to email them again tomorrow during business hours to get a better handle on what's going on.
@perennate:
"Please be advised that GTT has established a Firm Order Confirmation (FOC) date for the below referenced service of February 26th, 2013. Please review your order detail below[...]"
So they are giving me a firm date of tomorrow.
It's good. At least it's not February 29th ;-)
This is true
Hope it works out, would like to do some new tests when it's added.