古い環境なだけに面倒なことばっかり起きる

やたら、httpdが元旦に落ちているという謎な現象

そんなわけで、httpdも監視対象にする

[0回]

前回の記事の対応で、調べたことをメモとして

MySQLでは、テーブルにあるレコードの10%を超えるレコードに
変更を加えられた場合、該当のテーブルの統計情報（カーディナリティ）が再生成される。

構成オプション：innodb_stats_auto_recalcがONの場合。
デフォルトは、ON

Analyzeする場合、
analyze table テーブル名; 以外には、mysqlcheckを使う
（mysqlcheckは、MySQLのテーブルメンテナンス、修復を行なうことができる。 また、MySQLを稼働しているときに、実行することができる。）

全データベースを確認する場合

特定データベースのみを確認する場合

[0回]

めちゃくちゃハマったので、ここに記載

現行サーバのOSの期限が近付いたため、サーバの移行が行われました。
それにともない、DB（MySQL）も、地味にバージョンアップが実施された。

マイナーバージョンアップにより、SQLが厳密化され、型が違うカラムをJOINの条件にしていた部分をCONVERT()関数をつかって、キャストしたり。。。
CONVERT(数値カラム USING binary)=文字列カラム　みたいな。。。
型を意識しないで結合して作った奴出て来いよ！と思いつつ

それ以外は、プログラムの変更は行われていないのに、サーバ移行が行われ、パフォーマンスが大幅にダウン
その原因究明に、駆り出され、１週間

EXPLAINなどつけて、インデックス状況を確認し、SQLをチューニングしたり
でも、チューニングの結果が出ないの繰り返し。

幸いにも、旧サーバが残っていたので、新旧を比べることに。

新サーバのほうで、今まで使っていたインデックスが効いていない！
なんでだ？なんでだ？と試行錯誤。
（移管した奴が調べろよっと思いつつ、ストレスが溜まる１週間）

推測はインデックスが壊れているでは？、インデックスの統計情報がおかしいのでは？
と思いつつ、壊れているパターンから調査。
壊れてはいなそう。。。ということで、統計情報を確認。

差がありました。。。

確認したSQLとして、
SELECT database_name , table_name , last_update , stat_value , index_name ,
(stat_value * @@innodb_page_size) / 1024 / 1024 as size_mb
FROM mysql.innodb_index_stats
WHERE database_name='データベース名' AND table_name='テーブル名' AND stat_name='size';

結果：size_mbが全然違うじゃん！

ということで、

ANALYZE TABLE テーブル名　を実施

再度、サイズを確認し、更新されたことを確認
プログラムを動かしてみてくれ～とお願いしたら、１秒でレスポンスが返ってきた！と
苦労が報われるお返事がきました。

めちゃくちゃハマったというか、時間を使った。。。

[0回]

cakephp（cakephp3）で、
MySQLで作ったテーブルに、tinyint(1)のカラムを取得してみたところ、
tinyintではなく、booleanになっていた

cakephpの設定が足りないのか？と思いながら、
色々模索していた結果、
MySQLの内部的に、tinyint(1)をbooleanとして使っているとのこと。


JAVAでやっていたときって、こんなことあったっけかな？と思いつつ
んー。。。。って感じです。

つまらないことにハマったので、ここに残す。

[0回]

最近、使う機会が増えて、なんだっけ？と思うことが増えてきたので、
ここに残す

普段は使わないsarコマンドで、過去のCPU負荷やメモリ負荷を調べる

サーバにsarコマンドが入っていると、後々救われるということも痛感したので、
もしインストールされていなかったら、インストールしておいたほうがいい。

インストールされているか確認

[0回]