今回もちょっと蛇足から入りました。本当は大量にあるスパムのうち特定のIPアドレスからのスパムが多かったので、DBから直接削除しようと思ったのですが、その際に見つけたデーターベース「wordpress」内のテーブル「wp_blog_comments_fbseo」が気になった。DESCRIBEコマンドでテーブルの情報を得ようと思ったら参照ができなかったのでちょっとイジになって改修を試みた。その記録である。
心に火が付いたのは、上述のとおりWordPressに投稿されてくるスパムコメントを投稿元のIPアドレス情報を元に一括で削除しようとMySQLに接続してテーブルをあさっていた時に見つけた「wp_blog_comments_fbseo」だ。これはプレフィックス「wp_blog_」+プラグイン指定の名前「comments_fbseo」がついてこうなっている。どうやらWordPressのプラグイン「SEO Facebook Comment」が利用するテーブルのようだ。
MySQLサーバーに接続し、DBを選択し、pagerに「grep comm」を指定して、show tablesを実行。この状態で表示されるコマンド結果は「commを含むもの」のみが表示される。でもって、以下がその見つけたときの状況。
mysql> use wordpress; Database changed mysql> mysql> pagergrep comment PAGER set to 'grep comment' mysql> mysql> show tables; | wp_blog_commentmeta | | wp_blog_comments | | wp_blog_comments_fbseo | 43 rows in set (0.00 sec)
まずはDESCRIBEコマンドでテーブルのカラム情報の取得を行うべく「desc テーブル名」でコマンドを実施した。
すると以下のエラーが表示された。
mysql>
mysql> desc wp_blog_comments_fbseo;
ERROR 1286 (42000): Unknown storage engine 'InnoDB'
mysql>
ERROR 1286 (42000): Unknown storage engine ‘InnoDB’
どうやら、このテーブルのストレージエンジンが「InnoDB」である模様で中身の参照が行えなかった。
というのも以前にMySQLサーバーの利用メモリを抑えるために/etc/my.cnfに「skip-innodb」の記述を行っていたので、ストレージエンジンがInnoDBのテーブルは参照できなくなっている。
mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| MyISAM | DEFAULT | MyISAM storage engine | NO | NO | NO |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| InnoDB | NO | Supports transactions, row-level locking, and foreign keys | NULL | NULL | NULL |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)
mysql>
以前うまく動かないか何かの理由でアンインストールしていたSEO Facebook Commentだが、これを機に再度利用に挑戦したいと思う。
データーベースエンジンが「InnoDB」のテーブルを「MyISAM」に変更する
まずは、利用するMySQLサーバーがInnoDBを認識しなければいけないので、/etc/my.cnfの「skip-innodb」をコメントアウトしMySQLサーバーを再起動する。
# vi /etc/my.cnf ~省略 #skip-innodb ←コメントアウト ~省略 # # service mysqld restart Stopping mysqld: [ OK ] Starting mysqld: [ OK ] #
これでMySQLがInnoDBを認識するようになったのでMySQLサーバーにログインし、該当テーブルの詳細を確認してみる。
mysql> use wordpress Database changed mysql> mysql> show table status like 'wp_blog_comments_fbseo'; | wp_blog_comments_fbseo | InnoDB | 10 | Compact | 0 | 0 | 16384 | 0 | 0 | 11534336 | 1 | 2012-07-08 09:03:11 | NULL | NULL | utf8_general_ci | NULL | | | 1 row in set (0.08 sec)
「InnoDB」であることが確認できると思うので、これに対して変更を行う。
alter table wp_blog_comments_fbseo Engine=MyISAM;
そして変更後の確認を行う。
mysql> show table status like "wp_blog_comments_fbseo";
| wp_blog_comments_fbseo | MyISAM | 10 | Fixed | 0 | 0 | 0 | 9288674231451647 | 1024 | 0 | 1 | 2013-11-13 09:01:13 | 2013-11-13 09:01:13 | NULL | utf8_general_ci | NULL | | |
1 row in set (0.00 sec)
これですっきりしたので、再度/etc/my.cnfを編集して「skip-innodb」の記述を有効にMySQLサーバーを再起動する。
# vi /etc/my.cnf
~省略
skip-innodb ←コメントアウトを削除
~省略
#
# service mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
#
これで問題ないはずだ・・
まずは誰かからFacebookコメントが来ることを願う。いや、まずは自分で試してみようっと。
コメント
こんにちは
今回また更新ですね。
Mysql5.5のデフォルトのストレージエンジンMyisamからinnodbにかわってるんですよね。
muninでinnodb関連のグランが全然動いてる気配がなかったから調べてみたら、
skip-innodbが/etc/my.cnfにありました。mysqlを再起動して正常にグラフがうごくようになりました。
しかし、wordpressのプラグインによってストレージエンジンがちがうとかあるんですね。
製作にうごかねーとか文句いわれる前に会社のサーバーもskip-innodbをはずしておこ。
これはテストです!!
くりくりさん。。
結局どっちみちうまく動かなかったです。。 ページのロードがタイムアウトしてしまうというお始末。。
原因は/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php にあるようです。
詳細を追うまでもないので、今回「SEO Facebook Comments」はMyISAMではうまく動かないのでは?
という結論に至り、別のプラグインを利用しようとおもいます。 その前にスパムコメントの削除に関して記事書こうっと。
「skip-innodb」を解除した場合、MySQLのメモリ使用量がおかしなことになりませんか?
InnoDBへの運用切り替えは今のところ必要性を感じていませんので、今回はMyISAMで静かにしておきたいと思います。
>「skip-innodb」を解除した場合、MySQLのメモリ使用量がおかしなことになりませんか?
CentOS6,CentOS5もmrtgやmuninをみても
それほど増えた印象はありません。
ちなみにmysqlのバージョンはデフォルトのままです。
以前自宅サーバーはremiいれましたけど、バージョンあがるのが早すぎてめんどくさくなったんでもとに戻しました。
centos5.10で5.5がでてますけど、パフォーマンスがおちてる感じがしませんからそのまま使うつもりです。
>それほど増えた印象はありません。
そうなんですね。今利用しているVPSがメモリ4Gまで利用できるようなので利用してみようかなぁ
自分も一時期新しい物好きでremiから5.5を入れたんです。
CentOS5.10のMySQL5.5はちょっと設定ファイルの場所などが違うようで?まずは実験で違う環境で
インストールできたらと思っております。
私の所のVPS環境です。CPUは非公開です。
trippyboyさんの所はipv6がつかえますね。しかも安い。
色々なVPSをためしましたが、さくらほどの自由度がありある程度のスペックがかりられて安い。
GMOクラウドしかありませんでした。年一括払いで月2000円です。
[redadmin@www ~]$ cat /proc/cpuinfo
model name : QEMU Virtual CPU version 0.9.1
[redadmin@www ~]$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
[redadmin@www ~]$ free -m
total used free shared buffers cached
Mem: 3831 3538 292 0 205 2131
-/+ buffers/cache: 1201 2629
Swap: 7662 8 7654
[redadmin@www ~]$ df -h
Filesystem Size Used Avail Use% マウント位置
/dev/vda1 196G 9.5G 177G 6% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
くりくりさん
私の場合、DTIのキャンペーンでいつしか「3GB追加」という無料キャンペーンがありましたのでディスク容量が103になっています。
[root@vps1 ~]# grep “model name” /proc/cpuinfo | sort | uniq
model name : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
[root@vps1 ~]#
[root@vps1 ~]# grep processor /proc/cpuinfo
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
processor : 8
processor : 9
processor : 10
processor : 11
processor : 12
processor : 13
processor : 14
processor : 15
[root@vps1 ~]#
[root@vps1 ~]# free -m
total used free shared buffers cached
Mem: 4096 1578 2517 0 0 0
-/+ buffers/cache: 1578 2517
Swap: 0 0 0
[root@vps1 ~]#
[root@vps1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/simfs 103G 14G 90G 14% /
none 1.0G 4.0K 1.0G 1% /dev
[root@vps1 ~]#
コア多すぎじゃありませんか?
16ということはハイパースレッドでひとつのコアで2スレッドですか・・・。
メモリーもちゃんと4gある・・・。俺なんか4gにちかいのに4gといってるし・・。
うちの会社でかりている最新サーバーよりスペック高そう。
ちなみにwordpressで自分のVPSのnginx+fastcgiとp
lesk11でapache+fastcgiのサーバーですが、
abコマンドで負荷を試しましたら、
nginxは8秒で処理がおわりcpuの負荷はほとんどありません。
plesk11はcpu使用率がMAXとなり処理に80秒。
ロードアベレージも8近くとなりました。
純粋に比較できるわけではありませんが、一ヶ月の苦労はなんだったんでしょうかね?
朝試して大笑いです。
くりくりさん
nginxとApacheだけ比べても相当の処理のさがあると思います。
引越しされたサーバーですかね? なんか悔しいですね(涙 意地でもnginxでの運用に戻してやる!って火が付きそうです(笑
[root@vps1 ~]# cat /proc/cpuinfo | grep “core id” | sort | uniq -c
4 core id : 0
4 core id : 1
4 core id : 2
4 core id : 3
[root@vps1 ~]#
上記の結果から何かわかりますか? 4coreのCPUが4つあるってことですかね・・・ ハードは不得意なのですw
http://ark.intel.com/ja/products/40201/Intel-Xeon-Processor-L5520-8M-Cache-2_26-GHz-5_86-GTs-Intel-QPI
これみると4コア2CPUみたいです。
8コアだとおもっていました。
abコマンドの実行結果
http://www.superweibu.com/archives/3596.html
私のは2コアでしたw私のは8コアでしたw
Intel Xeon L5520 @ 2.27 GHz
2 processors, 8 cores, 16 threads
abコマンドの結果見ました。
これによると回線速度でしょうか、処理というよりもデーター転送速度の違いを見ると、接続元か接続先かの違いがあるようんも見えます。
Transfer rate: 4536.54 [Kbytes/sec] received
Transfer rate: 403.05 [Kbytes/sec] received
なるほど、そういえば回線についてはあんまりきにしてないな。
そこらへんも詳しくしらべてみましょう。
plesk11どこまでも仕事をふやしやがる。
plesk11…
これなしで全てができるようになりなさいという開発者からのいたずらかもしれませんね(^_^)