128M程度までというアドバイスがありますが、一方で、ログファイルサイズを大きくすることで、高い性能を引き出そうというチューニング手法もあります。成長すると緩やかにディスクへのランダム書き込み(チェックポイント)が始まります。バランスが取れ、上がったり下がったりしつつアクセス量と同じようなグラフの形になります。一定の割合(バージョンによる。90%等)を超えると今度は強いチェックポイントが始まります。高止まりした波グラフ(下のグラフの青い部分)になります。全力でディスクを使っている状態です。上限に達すると、全てのトランザクションを停止してチェックポイントを行うようになります。下がりトランザクションが再開されますが、更新が多いのでまたすぐ上限に達します。下のグラフの様に上限値でほぼ水平線になります。このグラフの形でも全トランザクション停止時間が1秒未満など微視的であれば、上の例と同じく全力運転状態と言えます。〜GBというようにバッファプール並みに大きくしてると、全トランザクションをブロックして書き込む量も多くなりますので、停止時間が数分間にも達し大きな問題となる事があります。水平線になったらトランザクション全停止が発生していないかアプリのログなどで確認するようにしましょう。ドリコムさんで体験された「ちゅどる」もこの現象になります。この「ちゅどる」にならないようにチェックポイントの強さを自動的に調節する機構です。いっても過言ではないと思います。テーブルは作成していません。グラフが急上昇することがあります。システムも高負荷になっています。テーブルとして作成され使用されている為発生します。大きな値に変更してメモリから溢れない様にするクエリを見直してテンポラリテーブルの使用量を下げるなどの対応が必要です。パフォーマンスチューニングや監視で、もっとも有効なのがスローログです。理由は単純明快で、あらゆるDBの問題は「遅い」という症状につながるからです。そんな万能選手のスローログですが、完全無欠ではなく注意すべき点が2点あります。完了したクエリだけが記録される。デッドロックなどロールバックされたクエリは完了していないため記録されません。記録されているスローログは被害を受け遅延したクエリで、原因となった加害者のクエリが最終的にはロールバックされ記録されていないというケースもあります。完了したクエリなんだという前提で読みましょう。クエリが原因だと先入観を持たない。あるクエリの実行時間が想定以上に長い場合、ついそのクエリの書き方に注意が向きがちですが、先入観を持たずに調査しましょう。原因では無かった、というケースなどがあります。パフォーマンス監視のツボ(システム編)としてサーバー運用管理での経験を共有させて頂きました。»ブログ記事検索このブログについてこのブログは、札幌市・仙台市の「株式会社インフィニットループ」が運営する技術ブログです。開催されます!【1月25日放送】テレビ北海道(TVh)「けいナビ~応援!どさんこ経済~」に取材いただきました!【中途採用向け】1月21日(火)札幌本社で会社説明会を開催いたします!あけましておめでとうございます!2020年もよろしくお願いいたします。