> Interesting. My Ultra 20 with 2GB get stuck, scratching the disk and freezing
> the overall system for more than 45 minutes before I shut it down (not very
> gracefully).
>
> Is the behavior of 'zdb -S' expected to be long to run, and to load (more
> than)
> significantly the system?
FYI, using b129 this seems a little better as this didn't freeze/crash the
system anymore. This is with managing two BE (b128a and b129), which
represents 21 datasets in the rpool ZFS pool, and with 197 snapshots.
$ /usr/bin/pfexec ptime zdb -S rpool
Simulated DDT histogram:
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 475K 16.9G 16.3G 16.3G 475K 16.9G 16.3G 16.3G
2 22.5K 847M 687M 687M 48.0K 1.69G 1.37G 1.37G
4 4.36K 44.6M 42.7M 42.7M 20.3K 206M 197M 197M
8 656 4.96M 3.78M 3.78M 6.63K 47.5M 37.1M 37.1M
16 144 565K 565K 565K 3.08K 12.4M 12.4M 12.4M
32 57 386K 386K 386K 2.27K 13.8M 13.8M 13.8M
64 28 303K 303K 303K 2.21K 28.0M 28.0M 28.0M
128 6 7K 7K 7K 1013 1.38M 1.38M 1.38M
256 3 132K 132K 132K 1005 34.5M 34.5M 34.5M
512 3 6K 6K 6K 2.03K 4.13M 4.13M 4.13M
8K 1 4K 4K 4K 10.3K 41.1M 41.1M 41.1M
32K 1 4K 4K 4K 36.0K 144M 144M 144M
Total 503K 17.8G 17.0G 17.0G 607K 19.2G 18.2G 18.2G
dedup = 1.07, compress = 1.05, copies = 1.00, dedup * compress / copies = 1.13
real 2:02.307641364
user 13.349946858
sys 2.988691247
Here is the memory consumption just after the completion of the 'zdb -S'
command:
$ echo ::memstat | /usr/bin/pfexec mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 151723 592 29%
ZFS File Data 51488 201 10%
Anon 255214 996 49%
Exec and libs 3947 15 1%
Page cache 26920 105 5%
Free (cachelist) 19144 74 4%
Free (freelist) 13410 52 3%
Total 521846 2038
Physical 521845 2038
--
julien.
http://blog.thilelli.net/
_______________________________________________
opensolaris-help mailing list
opensolaris-help@opensolaris.org
