Sign inTry Free

Important

Self-managed SingleStore will soon transition from version 9.1 RC to version 10. This new semantic versioning scheme will provide SingleStore with finer control over engine and feature releases that were not possible with the current versioning scheme.

In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10 prior to its general availability. Ahead of this transition, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 10.

8. Checking for System Changes and Log Hints

On this page

The last step in this guide is considering any system changes and/or log hints.

  1. Were there any operating system and/or application changes?

  2. Check the Studio EVENTS page and memsql.log for any information about recent log events at a high level. Sort by event_level to see those that are critical.

    • For more verbose logs, obtain the tracelog from the master aggregator data directory (the default for this is /var/lib/memsql/node-nodeHash/data/tracelogs).

    • Find the memsql.log file and run tail -f or cat and grep for error and/or warning.

      Events page shows changes and log hints.

Final Recommendations

If nothing unusual arose in the investigation across all of this guide, but your cluster is still having performance issues, consider the following recommendations:

  1. Did you properly capture the workload of interest in following the steps of this guide? It is possible an expensive query, queuing, or a resource problem was missed because the data was not examined at the right time. Make sure that the workload of interest is running during the time of investigation.

  2. Does your system have a recommended configuration? Check the sdb-report output again and consider any configuration optimization suggestions in the check output.

  3. Is the system’s hardware healthy overall? Check disk and network performance. It is possible that a hardware issue might be leading to performance bottlenecks.

  4. Refer to the Troubleshooting Reference to see if any of the reference topics included there are applicable to your cluster.

Last modified:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In