試験データベースサーバー(DBサーバー)を入れ替えた。
Debian7.4(64bit) MySQL5.5.35
CPU：2.4GHz→3.0GHz
MEM：4GB→8GB (2GB×4枚)
(それでも当然、)SQLで重い処理をすると、CPU占有率が100%に達する。
CPU占有率100%
以下のように100%以上を示すのは異常ではなく、複数コアがある場合。
CPU占有率189%
今回はXeon E3110への換装なので、Dualコアである。
![Intel Xeon E3110 3.0 Ghz 6M L2 Cache 1333MHz FSB LGA775 Dual-Core Processor by Intel [並行輸入品]](https://images-fe.ssl-images-amazon.com/images/I/51JWksH3zsL.jpg)
CPU占有率が100%に達する時間が長い場合は、過去に書いてきたMySQLの設定や、SQL文、データベースの設計、index等を見直す必要があるだろう。
ただ、多少見直したところで「遅いものは遅い」処理は、必ず存在する(後述)。
DBサーバーの処理で(ハード的な)ネックになるのは、主に
CPU、メモリー、固定ディスク、NIC
の四つ。
NICは、100BASEよりもGbEの方が当然よい。
NIC
1Gbpsは125MB/sであるが、固定ディスクが高速であっても、実際にはそこまでは出ない。
NICを経ずに(サーバー内で)重い処理を実行し、それでも重い場合はNICは関係ない。
固定ディスクは、主にハードディスクが用いられるが、速度面から、最近はSSDを採用することもあろう。
ハードディスクとSSD
が、SSDは寿命があるのでその点が心配、といっても、HDDも故障はするので、冗長化は必要。
SSDはハードディスクに比べ単位容量あたりの価格が高いが、それをクリアできるなら導入してもよいだろう。
メモリーは、固定ディスクに比べ非常に高速であるが、高価であり、データを一時的にしか保持できない。
メモリー
昔に比べると安価であり、多く積みたいが、メインボードのスロット数や搭載上限に注意する必要がある。
また、サーバー系のメインボードの場合、ECC付でないと
さらに、MySQLの調整(key_buffer_size等)でメモリーを有効に使うよう設定をしないと、無駄になる。
最後はCPU。
CPU(Xeon)
冒頭でも書いたように、上位のCPUに換装しても重いものは重く、CPU占有率が100%に達する。
100%に達している時間が短くなるという効果はあるが、数百MHz上げたところで、大きな効果は見込めない。
重い処理の中には「データを読み出すのに時間がかかる」処理がある。
数万件のデータを全てSELECTするとか、そんな処理。
これは、データが大きいので、時間がかかるのは当然。
CPUよりは、固定ディスクを見直すべきだろう。
当然、数万件のデータが必要になるのか、という検討は必要。
無駄にデータをSELECTしても、最終的にその一部しか必要でないのなら、そもそもSELECTする必要があるのか。
indexが適切に付けられているのか、利用されているのか(EXPLAIN)、等。
JOINやUNIONも処理コストのかかる処理である。
また、DB設計の正規化、非正規化という問題がある。
・正規化：更新のパフォーマンスは向上するが、検索のパフォーマンスは低下。
・非正規化：検索のパフォーマンスは向上するが、更新のパフォーマンスは低下。
正規化は、簡単にいうとテーブルを分けるということ。
テーブルを分ける(正規化)と更新時は一部のテーブルのみの更新で済むが、
検索時に結合する必要が生じるので、検索のパフォーマンスは低下する。
読み出しが多い場合は、あえて非正規化するのも手だろう。
重要なのは使用者にとって快適なシステムか？である。
使用者が開発者と異なる場合、使用者にとって、正規化や非正規化等、どうでもよいこと。
「正規化原理主義者」のような設計者がいるが、使用者の立場に立つと、正規化が常に正しいわけではないことが分かろう。
当然、正規化と非正規化を理解した上で設計するか、そうでないかは、重要であり、知らない人間と共に開発しても、話が合わない(笑)
重い処理で、ブラウザ落とせルヨ！
ページ応答なし
![Intel Xeon E3110 3.0 Ghz 6M L2 Cache 1333MHz FSB LGA775 Dual-Core Processor by Intel [並行輸入品]](https://images-fe.ssl-images-amazon.com/images/I/51JWksH3zsL._SL160_.jpg)
