On May 9, 2014, at 10:32 AM, Len Weincier via smartos-discuss <[email protected]> wrote:
>> > I see from the manufacturing docs that you have a single 50GB device >> > (270-022 usually). From reading around it seems to be recommend that >> > the slog be mirrored as it is taking the writes and if one fails there >> > is a spare. Do you find having only the one slog device is ok ? >> >> Yes. The slog is not "taking the writes"; it's being used to store the >> ZIL. If it fails on a running system, the ZIL will be written to the >> main pool; correctness will not be compromised. Of course, there are >> lots of ways for a device to fail. If you imagine the possibility that >> a device fails by taking 50x longer than normal to complete writes, your >> mirror looks a lot less useful (read: not at all). The only certainty >> is that buying 2 devices will cost you twice as much. > Now that makes sense, the ZIL is the in memory intent log and the slog is the > fast device that can store the intent log. If the slog goes away the ZIL is > still in memory and will be committed to the pool. The fast slog allows ZFS > to confirm writes to the client much faster. You're close, but it is not the ZIL in memory. Wikipedia does a reasonable job explaining intent logs at: http://en.wikipedia.org/wiki/Intent_log > >> The likelihood of the specific multiple-failure sequences that can lead >> to data loss here is extremely low. I personally have never seen it >> happen and consider it borderline contrived, much like the meteor strike >> and nuclear war scenarios. Given enough machines and enough time, I'm >> sure it will eventually happen (and when it does, it will be caused by >> operator error), but in the meantime I still have to think about cost. >> If your pool is being used to track the beneficial owners of trillions >> of dollars of Treasury debt, go ahead and spend the extra money. > Agreed now that I have the right mental model for whats happening. > >> >> >> > Also what sort of performance change / increase could one expect from >> > using and slog device, we have the DCS3700’s ? I am trying to >> > understand the way the slog works and how much improvement I can >> > predictably expect from an SSD slog ? >> >> Any reasonable slog vs. no slog will provide a significant improvement >> (order of magnitude reduction in latency or more) for any workload doing >> synchronous writes. I have never attempted to come up with a model that >> can map the numbers in a particular slog's marketing brochure to >> delivered performance; instead, I get evaluation units and typically use >> a dozen or so filebench profiles along with DTrace to get a rough >> estimate of what delivered (i.e., filesystem) performance will look like >> and how the slog itself is behaving. That test is conducted on a pool >> with that particular slog and the exact pool layout we would use. > Thanks for that pointer to filebench, was messing around with tools and > wondering how to get decent load profiles going for testing. So far the SSD > slog difference is significant, hard to quantify as you say. filebench was originally intended to get around the problem with almost every other benchmark at the time: the load generated is too simple to model real workloads. For example, it is not possible to use iozone to model the complex interaction of a database, its log, and indexing because they are three different workloads all interacting with each other. In filebench you can create rather complex state machines and expose the workload interactions. Hence you can use filebench to test how a slog can affect a complex application -- see the oltp or /var/mail workloads. > > I have setup 2 systems with the disklayout tool one using defaults and one > with raidz2 pools both with a single SSD slog, so far the raidz2 pool looks > to be doing the best. cool. Find what works and go with it. -- richard > >> This >> is not as good as observing a production workload, but given the breadth >> of what our customers do, it's all that's practical. If you have just a >> single machine, and know what your workload is, you can do better. As >> always, watch for things you can't explain and make sure you understand >> them before accepting the results. > > Thanks for the thoughtful replies, always valuable > > smartos-discuss | Archives | Modify Your Subscription ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
