[ClusterLabs] Antw: Re: Q: status section of CIB: "last_0" IDs and "queue-time"
Ken Gaillot
kgaillot at redhat.com
Thu Jun 2 14:45:56 UTC 2016
On 06/02/2016 01:07 AM, Ulrich Windl wrote:
>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 01.06.2016 um 16:14 in Nachricht
> <574EEDE2.1090307 at redhat.com>:
>> On 06/01/2016 06:14 AM, Ulrich Windl wrote:
>>> Hello!
>>>
>>> I have a question:
>>> Inspecting the XML of our cluster, I noticed that there are several IDs
>> ending with "last_0". So I wondered:
>>> It seems those IDs are generated for start and stop operations, and I
>> discovered one case where an ID is duplicate (the status is for different
>> nodes, and one is a start operation, while the other is a stop
>> operationhowever).
>>
>> The "*_last_*" IDs simply refer to the last (= most recently executed)
>> operation :)
>>
>> Those IDs are not directly used by the cluster; they're just used to
>> store the most recent operation in the CIB.
>>
>>> Background: I wrote some program that extarcts the runtimes of operations
>> from the CIB, like this:
>>> prm_r00_fs_last_0 13464 stop
>>> prm_r00_fs_last_0 61 start
>>> prm_r00_fs_monitor_300000 34 monitor
>>> prm_r00_fs_monitor_300000 43 monitor
>>>
>>> The first word is the "id" attribute, the second is the "exec-time"
>> attribute, and the last one (added to help myself out of confusion) is the
>> "operation" attribute. Values are converted to milliseconds.
>>>
>>> Is the name of the id intentional, or is it some mistake?
>>>
>>> And another question: For an operation with "start-delay" it seems the start
>> delay is simple added to the queue time (as if the operation was waiting that
>> long). Is that intentional?
>>
>> Yes. The operation is queued when it is received, and if it has a start
>> delay, a timer is set to execute it at a later time. So the delay
>> happens while the operation is queued.
>
> Ken,
>
> thanks for the answers. Is there a way to distinguish "intentional" from "non intentional" queueing? One would look deeper into non-intentional queueing.
No, from the cluster's point of view, it's always intentional, just
different lengths of time. You'd just have to subtract any start delay
if you're not interested in that.
> Regards,
> Ulrich
>
>>
>>> Another program tried to extract queue and execution times for operations,
>> and the sorted result looks like this then:
>>>
>>> 1 27 prm_nfs_home_exp_last_0 monitor
>>> 1 39 prm_q10_ip_2_monitor_60000 monitor
>>> 1 42 prm_e10_ip_2_monitor_60000 monitor
>>> 1 58 prm_s01_ip_last_0 stop
>>> 1 74 prm_nfs_cbw_trans_exp_last_0 start
>>> 30001 1180 prm_stonith_sbd_monitor_180000 monitor
>>> 30001 178 prm_c11_ascs_ers_monitor_60000 monitor
>>> 30002 165 prm_c11_ascs_ers_monitor_45000 monitor
>>>
>>> Regards,
>>> Ulrich
More information about the Users
mailing list