一部の人々（時には私たちでさえ）は、LogicMonitorを「ボックス内のシステム管理者」と呼ぶことが知られています。 これは完全に真実ではありません。SaaSサービスであるという理由だけでなく、ボックスはありません。 ただし、LogicMonitorを使用すると、監視を自動化し、事前定義されたベストプラクティスのアラートを提供することで、システム管理者の採用を延期したり、システム管理者が他の監視システムよりもはるかに多くのシステムを管理したりできますが、誰かがそれらのアラートを解釈して把握する必要があります。それらに対処するための最良の方法。
適切な例：
顧客は、MySQLデータベースのXNUMXつについて次のアラートを受け取りました。
クエリ_キャッシュ_スラッシング server1のクエリキャッシュから回答されたクエリの割合はわずか7.69％であり、クエリキャッシュには5秒あたり2011つを超えるプルーンがあります。 この状態は05-09-14：39：47 PDTに始まり、0時間12分続いています。 これは、クエリキャッシュのサイズが大幅に小さいか、アプリケーションがクエリキャッシュの恩恵を受けていないため、無効にする必要があることを示しています。 Query_cache_sizeは、DBに割り当てられたメモリの約1/16に設定する必要があります。 正しく有効になっていてヒット率が低い場合は、パフォーマンスに悪影響を与える可能性があるため、無効にする必要があります。
顧客は何をすべきかを知りたがっていました–アラートはキャッシュをはるかに大きくするかオフにするかのどちらかを示しています–それはどのようなアドバイスですか？ LogicMonitorは、アラートを評価するときにさまざまなメトリックを考慮するため、クエリキャッシュを増やすか無効にするかを（状況によっては）通知できますが、この場合のようにスラッシングする場合は、人間が評価する必要があります。
したがって、私が人間である場合、この状況を次のように評価します。
クエリキャッシュのパフォーマンスグラフを見ると、それから多くを得ていないことは明らかです。ヒットよりも多くの挿入とプルーン（メモリを解放するため）があります。
では、このデータベースはどのような操作を行っているのでしょうか? クエリ キャッシュは、… クエリ (選択) に対してのみ有効です。 しかし、この特定のデータベースはそれらの多くを実行していません。 以下に示すように、XNUMX 秒あたり数千回の更新と挿入を行っていますが、選択はごくわずかです。
更新が非常に多いため、キャッシュはクエリに対して効果的でないことがよくあります。
だから、それを考えると：
- キャッシュを継続的に無効にする更新と挿入がたくさんあります
- データベースには（他の操作と比較して）多くのクエリはありません
- したがって、キャッシュヒット率は低くなります
したい test クエリキャッシュを無効にします。 これにより、システムが他の目的で使用するためのメモリが増え、XNUMX秒あたり数千の更新と挿入を行うたびにクエリキャッシュの更新に時間を費やすのを防ぐことができます。
もちろん、クエリキャッシュによって正常に応答されている少数のクエリが非常に集中的なものである可能性があるため、テーブルスキャンと完全結合のグラフを見て、それらが大幅に増加するかどうかを確認します。
そして、これがこのブログエントリのもうXNUMXつのポイントです。あらゆる種類のデータの傾向を把握していないと、変更が有益かどうかを判断できません。 また、クエリキャッシュを無効にすることが有益であるかどうか、CPU負荷を軽減し、パフォーマンスを向上させるかどうかはわかりません。 この場合、どちらの方法でも大きな違いはない可能性がありますが、一部のアラートが停止した場合は、 リソース使用率が向上します。その効果は、データベースの拡張に伴って大きくなります。
そのため、LogicMonitorは、アラートと根本原因の分析のためにあらゆる種類の領域でより優れたヒューリスティックを積極的に研究していますが、テストする構成の変更の可能性を判断し、テストの結果を評価するために人間の脳が必要になる場合が多くあります。 。
したがって、これらのDBAを維持してください。 （ただし、LogicMonitorを入手して、より効果的に仕事を行えるようにしてください。）