explanation below...
On Feb 26, 2010, at 10:11 AM, Ronny Egner wrote:
> Hi,
>
> please find below the requested information:
>
> r...@openstorage:~# mdb -k
> Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp
> rootnex scsi_vhci zfs sockfs ip hook neti sctp arp usba uhci fctl stmf md
> lofs idm random mpt sd nfs crypto fcp fcip cpc smbsrv ufs logindmux ptm sppp
> nsmb ii nsctl rdc sv sdbc ]
>
>> ::zfs_params
> arc_reduce_dnlc_percent = 0x3
> zfs_arc_max = 0x0
> zfs_arc_min = 0x0
> arc_shrink_shift = 0x5
> zfs_mdcomp_disable = 0x0
> zfs_prefetch_disable = 0x0
> zfetch_max_streams = 0x8
> zfetch_min_sec_reap = 0x2
> zfetch_block_cap = 0x100
> zfetch_array_rd_sz = 0x100000
> zfs_default_bs = 0x9
> zfs_default_ibs = 0xe
> metaslab_aliquot = 0x80000
> mdb: variable reference_tracking_enable not found: unknown symbol name
> mdb: variable reference_history not found: unknown symbol name
> spa_max_replication_override = 0x3
> spa_mode_global = 0x3
> zfs_flags = 0x0
> mdb: variable zfs_txg_synctime not found: unknown symbol name
> zfs_txg_timeout = 0x1e
> zfs_write_limit_min = 0x2000000
> zfs_write_limit_max = 0x23fde5800
> zfs_write_limit_shift = 0x3
> zfs_write_limit_override = 0x0
> zfs_no_write_throttle = 0x0
>
Note: "kstat -n arcstats" allows you to see these variables without
the need to be root or use mdb.
>> ::arc
> hits = 682809234
> misses = 41519142
> demand_data_hits = 26047450
> demand_data_misses = 17440267
> demand_metadata_hits = 636130758
> demand_metadata_misses = 15436051
> prefetch_data_hits = 10328015
> prefetch_data_misses = 8549656
> prefetch_metadata_hits = 10303011
> prefetch_metadata_misses = 93168
> mru_hits = 15961928
> mru_ghost_hits = 287507
> mfu_hits = 655313464
> mfu_ghost_hits = 14603118
> deleted = 43957777
> recycle_miss = 448696
> mutex_miss = 572393
> evict_skip = 99942
> evict_l2_cached = 0
> evict_l2_eligible = 421991499264
> evict_l2_ineligible = 30080494080
> hash_elements = 5756890
> hash_elements_max = 10234471
> hash_collisions = 51949950
> hash_chains = 1583031
> hash_chain_max = 19
> p = 32573 MB
> c = 42754 MB
target ARC size
> c_min = 9085 MB
> c_max = 72687 MB
upper limit to the target ARC size
> size = 42754 MB
current size
So you can see that the ARC will allow itself to grow to 72GB - 1GB.
However, the current size is the same as the target size and far
less than target max, which can indicate...
> hdr_size = 1105922976
> data_size = 43097086464
> other_size = 627925600
> l2_hits = 0
> l2_misses = 0
> l2_feeds = 0
> l2_rw_clash = 0
> l2_read_bytes = 0
> l2_write_bytes = 0
> l2_writes_sent = 0
> l2_writes_done = 0
> l2_writes_error = 0
> l2_writes_hdr_miss = 0
> l2_evict_lock_retry = 0
> l2_evict_reading = 0
> l2_free_on_write = 0
> l2_abort_lowmem = 0
> l2_cksum_bad = 0
> l2_io_error = 0
> l2_size = 0
> l2_hdr_size = 0
> memory_throttle_count = 0
> arc_no_grow = 1
flag to indicate whether the ARC will try to grow.
When it is set to 1, the ARC won't try to grow for another 60
seconds. This indicates that the ARC was recently asked to
reclaim space. Three conditions can cause this for x86:
1. pageout scanner is running (a small margin applies here)
2. swapfs does not have enough space so that anonymous
reservations can succeed. This is calculated from as:
swapfs_minfree + swapfs_reserv + desfree
on one of my machines with 2 GBytes of RAM, this limit is
73,437 pages (300,797,952 bytes).
hint: "echo swapfs_minfree/D" | mdb -k
3. [x86 only] kernel heap space is more than 75% allocated.
IIRC, this is more of a problem for 32-bit systems. Unless I'm
mistaken, you can see the kernel heap arena size use ratio
by looking at the "mem_inuse" to "mem_total" ratio via
"kstat -n heap"
-- richard
> arc_tempreserve = 0 MB
> arc_meta_used = 9977 MB
> arc_meta_limit = 18171 MB
> arc_meta_max = 16326 MB
>
>
>> ::memstat
> Page Summary Pages MB %Tot
> ------------ ---------------- ---------------- ----
> Kernel 7676041 29984 41%
> ZFS File Data 8150818 31839 43%
> Anon 31940 124 0%
> Exec and libs 1605 6 0%
> Page cache 5726 22 0%
> Free (cachelist) 429684 1678 2%
> Free (freelist) 2574246 10055 14%
>
> Total 18870060 73711
> Physical 18870059 73711
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
ZFS storage and performance consulting at http://www.RichardElling.com
ZFS training on deduplication, NexentaStor, and NAS performance
http://nexenta-atlanta.eventbrite.com (March 16-18, 2010)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
