Mark Maybee wrote: > > The write_limit is independent of the memory size. Its based purely > on the IO bandwidth available to the pool. So a write_limit of 3GB > implies that we think that we can push 3GB of (inflated) data in 5 > seconds to the drives. If we take out the inflation, this means > we think we can push 100MB/s to the pools drives.
Ah, I see... 3GB / 5 secs = 600MB/s, de-inflate by dividing by 6 to get 100MB/s. Thank you. >> The intended result is to have a reliable means of monitoring (via a >> standard monitoring framework such as Nagios or Zabbix or something) ZFS >> health... and from my studies simply watching traditional values via >> iostat isn't the best method. If ZIL is either disabled or pushing to >> SLOG, then watching the breathing of TXG sync's should be all thats >> really important to me, at least on the write side... thats my theory >> anyway. Feel free to flog me. :) >> > Nope, that makes sense to me. Ideally, we should either be chugging > along at 5-to-30 second intervals between syncs with no delays (i.e. > a light IO load), or we should be doing consistent 5s syncs with a > few delays seen (max capacity). If you start seeing lots of delays, > you are probably trying to push too much data. > > Note that we are still tuning this code. Recently we discovered that > we may want to change the throughput calculation (we currently don't > include the dsl_dataset_sync() calls in the calc... we may want to > change that) to include more of the IO "setup" time. I'm certain that there is more than enough on everyones plate atm, but I would be very happy to see purpose build kstats for monitoring in the future. The more time I spend in the ZFS code the more I realize that iostat and even VFS calculations to be misleading at best. Standardizing on the "right numbers"(tm) to watch would be a great benefit to the user base. Comforting and consoling our customers who are reacting to numbers they don't understand is becoming ever more time consuming. :) Thank you for your help Mark, this clears up several things for me! benr.
