Why bother creating a good problem report? The better the problem report is, the fasterRead More
Providing good problem reports
Why bother creating a good problem report?
The better the problem report is, the faster your problem is likely to be solved.
In the absence of a good report, whoever is trying to resolve your problem will probably come back to you and ask for more information. The more iterations there are of this nature, the more time will elapse before the problem is understood, and can be resolved.
Where to create problem reports
All users of Kognitio software can report problems by posting on the community forums at http://kognitio.com/forums – remember these are visible to everyone, so don’t post confidential information.
Alternatively, customers paying for support can:
- create a case on the support portal
- email the appropriate helpdesk alias at Kognitio
- phone the Kognitio helpdesk for critical problems – this is the best method outside normal working hours, as other methods are not monitored in these times. Note that customers need to have a 24×7 support package to call outside normal working hours
How to create good problem reports
There are many articles on the internet about how to create good bug reports, such as:
The same general rules apply for reporting issues to Kognitio.
So what are the basic rules for a problem report?
- Specify details of the Kognitio system concerned:
- the system_id if you are a paying customer
- the specs of the system otherwise
- Clarify when the problem started
- this allows us to review logs for changes that have occurred leading up to that point in time
- Explain which queries are affected
- is it all queries, or just some queries
- if just some queries, what do that have in common – are they all by a particular user, or do they all try to put images into RAM, or do they all reference a common object?
- If possible, provide evidence of when things were last OK, and information on any changes between then and when the problem started. For example:
- Kognitio software was upgraded
- Some/all nodes were rebooted
- OS patches were applied
- Data feed changes occurred
- Scheduling of jobs was changed
- Provide any other useful information available.
- For performance issues, this could be timings before and after the problem occurred.
- Query plans for problem queries, if available (precede the query with the keyword DIAGNOSE to capture this)
- Any extra information you have captured during your own investigation
Once the above rules have been followed, generic advice from the earlier references on bug reporting comes into play:
- provide a good title/subject
- if you have precise steps to reproduce the problem, please include them
- provide any relevant additional information, such as DIAGNOSE output, log files, screen shots, …
- if it isn’t clear from the above, provide details of the expected behaviour, and how that differs from the behaviour you are seeing.
- file a separate report for each issue – do not be tempted to put a big list of issues in one ticket, things work better with one issue per ticket
Note that users of the support portal can use the “FAQ: Kognitio troubleshooting” solution which appears on the portal home page, and click through the decision tree to get assistance with a variety of problems.
Finally, let’s look at a bad problem report, followed by a good version of that same report:
BAD PROBLEM REPORT
Our system is giving errors. Please help. This is critical.
GOOD PROBLEM REPORT
Our production system, bigkog01, is giving “PM0007: PMA out of memory” errors when we run our imaging script.
We are running 8.1.0rel160921 software, and have been for over a month.
The errors started when we ran our usual imaging process on Friday night – it ran successfully on the previous Friday, and the script is unchanged.
We’ve attached the script, which basically drops existing images for our key objects, then recreates them – it works like this so user’s see a consistent view of the data throughout the week, so they can rerun analysis without being confused by updates to the underlying data during the week.
We have noticed RAM usage creeping up throughout the week as users instantiate more objects, and we have a separate case open at the moment about how we should tidy up those user objects rather than just let them keep consuming more and more of our system RAM.
We’ve run the $f7 query from submit to show RAM usage by object, and attached the output, along with the output from $f2 which shows RAM usage is very high!
We’ve searched for “kognitio pm0007” (without the quotes) and found the following two community forum articles, but neither of them seem to address our situation: