/build/static/layout/Breadcrumb_cap_w.png

K1000 WebUI Randomly Hangs

Our K1000 is a virtual appliance. We are running VersionĀ 5.5.90548. This has never been an issue until this version but I am sure it was not an issue for some time after this update. The webui will become unresponsive until we reboot. It does not seem to happen at any specific time and sometimes we can go a week or more without issue. I have contacted support a few times and all they will do is use webex and look at settings/pull logs. The only suggestions made by them has been to delete some unused patches and free more space. This did nothing. Logs have shown no problems. Patches,Scripts,Reports are not set or manually running at any of the times this has happened. I am only allowed by KACE to log into the console using netdiag. Doing this and running top shows what I think is the mysql process running as root and eating a ton of cpu. The console runs fine by the way. We have one external connection to the database that I know of and killing it while this happens does nothing. Running other console commands does not work because there is no scrollback. Is there a way I can ssh into this console as admin or root? Is there a command I can run to see where that process is being ran from? Is there anything else i can do to resolve this issue?


3 Comments   [ + ] Show comments
  • We had that problem and traced it down to when one tech would would go into assets and do a query. It took a few techs over a couple of years but finally got a hold of a very good tech at digging into the problem. I had to keep opening new tickets and bugging them since it was an intermittent problem

    Here was the last entry he made into the ticket.

    Changed ticket Title from "K1000 - When working in assets for one org it will take 30+ minutes to do searches and updates, other orgs assets are ok" to "in assets for K1000 - When working one org it will take 30+ minutes to do searches and updates, other orgs assets are ok".
    Changed ticket Status from "New" to "Waiting on Customer".

    Hello Steve,

    I checked the DB and everything looked fine, and via webex session we looked at the kbox settings and those look fine as well. I did notice a dashboard query taking a long time to run which may be causing the slowness ( Bug K1-15925 ), and made the necessary updates on the back-end as a workaround.

    Please let me know if you continue to experience slowness, and at what time.

    Thanks,
    Matt - SMal.tmcc 9 years ago
    • if it is really this one, upgrade to 6.0 will solve the issue - Nico_K 9 years ago
      • it did not for us they had to go in and make background changes. so it may have been something else causing the high sql. I think Matt also flushed the history data from sql also - SMal.tmcc 9 years ago
  • Thank you,
    I have been looking for more info on the bug K1-15925. Do you have a link to anything about it. - bender6681 9 years ago
  • Hi Bender6681, Mary from KACE Technical Support. I looked up this bug and it is indeed marked resolved in 6.0. Usually with a heavy TOP MySql is an indicator of a long report running, or possibly a report or asset query that has a large return. To trouble-shoot this I usually will kill all processes via trouble-shooting tools and re-boot the appliance. If you still experience high Mysql usage after this I recommend that you upgrade to 6.0 as indications are the particular bug issue is marked as resolved in 6.0 (If what you are experiencing is indeed the actual issue.) - KACE_Mary 9 years ago
    • Sorry for the late reply. We are not prepared to make the switch to 6.0. Is there no patch to the latest V5 to fix this? - bender6681 9 years ago

Answers (0)

Be the first to answer this question

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ