DBサーバーのハードウェア換装(Debian7.4,MySQL5.5.35) Xeon E3110

この記事は約4分で読めます。
スポンサーリンク

試験データベースサーバー(DBサーバー)を入れ替えた。

Debian7.4(64bit) MySQL5.5.35

Debian7.4(64bit)

CPU:2.4GHz→3.0GHz
MEM:4GB→8GB (2GB×4枚)

(それでも当然、)SQLで重い処理をすると、CPU占有率が100%に達する。

CPU占有率100%
CPU占有率100%

以下のように100%以上を示すのは異常ではなく、複数コアがある場合。

CPU占有率189%
CPU占有率189%

今回はXeon E3110への換装なので、Dualコアである。

Intel Xeon E3110 3.0 Ghz 6M L2 Cache 1333MHz FSB LGA775 Dual-Core Processor by Intel [並行輸入品]

CPU占有率が100%に達する時間が長い場合は、過去に書いてきたMySQLの設定や、SQL文、データベースの設計、index等を見直す必要があるだろう。

ただ、多少見直したところで「遅いものは遅い」処理は、必ず存在する(後述)。

DBサーバーの処理で(ハード的な)ネックになるのは、主に

CPU、メモリー、固定ディスク、NIC

の四つ。

NICは、100BASEよりもGbEの方が当然よい。

NIC
NIC

1Gbpsは125MB/sであるが、固定ディスクが高速であっても、実際にはそこまでは出ない。

NICを経ずに(サーバー内で)重い処理を実行し、それでも重い場合はNICは関係ない。

固定ディスクは、主にハードディスクが用いられるが、速度面から、最近はSSDを採用することもあろう。

ハードディスクとSSD
ハードディスクとSSD

が、SSDは寿命があるのでその点が心配、といっても、HDDも故障はするので、冗長化は必要。

SSDはハードディスクに比べ単位容量あたりの価格が高いが、それをクリアできるなら導入してもよいだろう。

メモリーは、固定ディスクに比べ非常に高速であるが、高価であり、データを一時的にしか保持できない。

メモリー
メモリー

昔に比べると安価であり、多く積みたいが、メインボードのスロット数や搭載上限に注意する必要がある。

また、サーバー系のメインボードの場合、ECC付でないと

さらに、MySQLの調整(key_buffer_size等)でメモリーを有効に使うよう設定をしないと、無駄になる。

最後はCPU。

CPU(Xeon)
CPU(Xeon)

冒頭でも書いたように、上位のCPUに換装しても重いものは重く、CPU占有率が100%に達する。

100%に達している時間が短くなるという効果はあるが、数百MHz上げたところで、大きな効果は見込めない。

重い処理の中には「データを読み出すのに時間がかかる」処理がある。

数万件のデータを全てSELECTするとか、そんな処理。

これは、データが大きいので、時間がかかるのは当然。

CPUよりは、固定ディスクを見直すべきだろう。

当然、数万件のデータが必要になるのか、という検討は必要。

無駄にデータをSELECTしても、最終的にその一部しか必要でないのなら、そもそもSELECTする必要があるのか。

indexが適切に付けられているのか、利用されているのか(EXPLAIN)、等。

JOINやUNIONも処理コストのかかる処理である。

また、DB設計の正規化、非正規化という問題がある。

・正規化:更新のパフォーマンスは向上するが、検索のパフォーマンスは低下。
・非正規化:検索のパフォーマンスは向上するが、更新のパフォーマンスは低下。

正規化は、簡単にいうとテーブルを分けるということ。

テーブルを分ける(正規化)と更新時は一部のテーブルのみの更新で済むが、
検索時に結合する必要が生じるので、検索のパフォーマンスは低下する。

読み出しが多い場合は、あえて非正規化するのも手だろう。

重要なのは使用者にとって快適なシステムか?である。

使用者が開発者と異なる場合、使用者にとって、正規化や非正規化等、どうでもよいこと。

「正規化原理主義者」のような設計者がいるが、使用者の立場に立つと、正規化が常に正しいわけではないことが分かろう。

当然、正規化と非正規化を理解した上で設計するか、そうでないかは、重要であり、知らない人間と共に開発しても、話が合わない(笑)

重い処理で、ブラウザ落とせルヨ!

ページ応答なし
ページ応答なし

タイトルとURLをコピーしました