Hello
Is there a way to have an email when running bossocks fiber get too high?
Regards
Sylvain
it may be possible by a script or maybe by HNTM.. but I would not recommend it. you will be spammed if the script is not enought clever because you need to identify if
it is a peak : __/\___/\_____
________________________
or a "plateau": ____/ \___________
High bossock tasks is a consequence of something else (heavy load on disks or bad storage configuration, most of the time)... so you are not trying to solve the root cause.
and even if you are aware of a "bad" situation, what can you do? stop all or part of your production in order to give some breathe to the HNAS? not possible!..
migrate EVS to another node? if you don't fix the root cause, the situation will start again..
reboot the node? you will lost EVERY information that could help support to help you.
wait? ..
no, you really need to "understand" what is wrong:
another thing is: you can have some peak of Bossock.. it is not a problem if the system is well design.. the issue is more when you have a "plateau". this situation concludes , most of times, to say that the HNAS is not working.. but 97% (by my own experience, it is not a HDS number) of the times it may be an overload from your clients to the disks or misconfiguration.. but because the HNAS is in the middle of this "war" of IO.. you may think it is the root cause..
like every performance issue, it is hard to diagnose it.
in a close future, the HNAS should have "continuous pir" in order to collect enough statistics/details to help the support to help you to fix the issue.
the other 3% could be an issue in the HNAS mcode unable to manage something.. and bossock starvation arrives... but it may generate a reset of the node at the end.. and support could easily identify the issue with a simple diagnostic.
HTH
We are using NTP File Screening Software for our HNAS and we had the high Bossock Problem about once a week. It seemed that every time the NTP Server had some Problems it gets disconnected and caused the Bossocks to go to the Limit. That caused a stop to our central Filer for about 3000 Employees and a stop of a lot of intra Pages. Not really funny.
We had a lot of Cases and Investigations from NTP Site but no solution. I was also thinking about a Way to Monitor the Bossocks but with the new HNAS FW Version all the Problems seemed to be solved. Right now we have FW 12.3 installed and Bossocks Looks most of the time like a flat line. The Reason is, that for external Servers like Filescreening Servers or Antivirus Servers the Bossock usage is now limited. Maybe a FW Upgrade can solve some Bossock issues which are caused by external Servers.
Regards
Miran,
your case is part of the "3%" of non performance storage issue...
Yea... i am Born under a luck star..
it may be possible by a script or maybe by HNTM.. but I would not recommend it. you will be spammed if the script is not enought clever because you need to identify if
it is a peak : __/\___/\_____
________________________
or a "plateau": ____/ \___________
High bossock tasks is a consequence of something else (heavy load on disks or bad storage configuration, most of the time)... so you are not trying to solve the root cause.
and even if you are aware of a "bad" situation, what can you do? stop all or part of your production in order to give some breathe to the HNAS? not possible!..
migrate EVS to another node? if you don't fix the root cause, the situation will start again..
reboot the node? you will lost EVERY information that could help support to help you.
wait? ..
no, you really need to "understand" what is wrong:
another thing is: you can have some peak of Bossock.. it is not a problem if the system is well design.. the issue is more when you have a "plateau". this situation concludes , most of times, to say that the HNAS is not working.. but 97% (by my own experience, it is not a HDS number) of the times it may be an overload from your clients to the disks or misconfiguration.. but because the HNAS is in the middle of this "war" of IO.. you may think it is the root cause..
like every performance issue, it is hard to diagnose it.
in a close future, the HNAS should have "continuous pir" in order to collect enough statistics/details to help the support to help you to fix the issue.
the other 3% could be an issue in the HNAS mcode unable to manage something.. and bossock starvation arrives... but it may generate a reset of the node at the end.. and support could easily identify the issue with a simple diagnostic.
HTH