- This topic has 8 replies, 5 voices, and was last updated 13 years, 5 months ago by
.
-
Topic
-
Does anyone know of any bad things that could happen if you run..
Code:hcimsiutil -zt
… on an actively running thread/process/site?I tried it in my development test site and it appears that the threads go into an “Initializing” state until they receive the next interface message … that’s all.
I’m writing a script to colllect thread statistics.
-
Replies
-
-
No problems.
The ‘initializing’ Status is temporary. A lot of activity will cause it to revert to the actual connection status.
There are two schools regarding clearing stats after collection.
If you do clear after each collection then you have no continuum.
If you collect periodically throughout the day and then clear only once per day you have a daily continuum – but – the analysis process (that thing receiving the stats) needs to be able to do delta reporting.
Having had a past life in the perfomance/capacity analysis/planning arena, the generally accepted data collection method was to clear on a periodic basis and collect in between (the continuum concept). You will note that is the way msi works – it just keeps collecting until it is cleared. This allows for a more usable set of metrics for performance, capacity, etc. – however it requires heftier capability of the reporting medium.
I have seen some success for management reporting doing the clear after collection method, but it presents some performance/capacity analysis issues.
So it really depends on your intent.
If your intent is to support both (that is often a stated goal) then the continuum philosophy has more merit.
An additional note if your intent is to do performance/capacity analysis/planning – it is important you establish and periodically evaluate your peak demand period.
That is different for different workloads (batch versus real-time for example) in that the time period for a peak will differ between batch and real-time. Real-time for example might look at no more than 15 minute periods to determine peak demand. Batch on the other hand might look at periods of one hour or more.
Also understand a peak demand period is NOT the peak usage period. They frequently do not even coincide.
Rather the peak demand period is based on arrival rates.
Once the peak demand period is established (ideally for no more than one or two periods on one day of the week), simply monitoring that period can provide the information needed to track performance/capacity and provide one basis for capacity/performance forecasting. This then reduces the effort ot analyze perfromance/capacity.
There is a lot more to this. Usually folks don’t realize the scope until after they begin collecting the data – but this efffort is like Pandora’s box – once opened it seems to keep growing.
Good luck!
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
We have been zeroing out thread counts via
hcimsiutil -zt $thread
near midnight from the very beginning.
After being woke up repeatedly with false alerts I eventually figured out the initializing status on the thread was triggering the false alerts.
We solved our problem by cycling the process log file via
hcicmd -p $proc -c ‘. output_cycle’ > /dev/null 2>&1
shortly after zeroing out the thread counts which causes the initializing status to disappear and eliminates the false alerts.
Russ Ross
RussRoss318@gmail.com -
-
Okay, I have a script in place that is getting message/byte/queue/error/activity information from threads.
However, we have another cron that cycles SMAT and log files, then archives them.
So, I don’t want my script to cycle the process logs. Anyone know of another command/activity that I can issue to the thread to get the “initializing” status to go away?
Thanks,
Troy
-
-
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
