Roman,
Can somebody look into this magic number and explain why
async_throttle_delay slowly grows over the time
and if might be related to the delays?
The number is not all that magic. Have you looking at the following
manual, and then specificlly at for the keyword
"async_throttle_delay"?
http://docs.sun.com/source/819-6148-10/chap5.html, search for
async_throttle_delay
I meant it's interesting why it's growing slowly over the time?
I thought this is an average value for given perion of observation.
Or is this a "total" delay for the whole period of replication time?
This is the total number of times SNDR had to delay replicating a
chunk of data, since a given replica was last enabled or resumed by
SNDR. An increment occurs during asynchronous replication with both
memory or disk queues, at the time when the total number of items, or
the total size of all items, exceeds what was previously configured as
the memory or disk queue size.
For memory queues this is:
sndradm [opts] -F <maxqfbas> [set] set maximum fbas to queue
sndradm [opts] -W <maxwrites> [set] set maximum writes to queue
For disk queues this is:
The summation of the number of items, and the number of blocks, based
on the physical size of the associated disk queue.
It is impossible to keep this number low, by increasing the memory
queue, disk queue, the number of asynchronous flusher threads
(sndradm -A ...), higher network bandwidth, lower network latency, a
faster SNDR secondary node, or some combination of these.
- Jim
--
Regards,
Roman Naumenko
--
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
