» レンタルサーバーのブログ記事


さて、またまたサーバーのお引っ越し。

今度はcore miniからcore aへ!

今回の引っ越しの理由は、オンラインデータベースを使ったアプリ開発に伴い、将来にわたるデータ容量がcore mini(10GB)では心許なかったのと、負荷率やメールの配信上限にも不安が…

そんなわけで、core Aへ

引っ越し対象は、メインのドメインとブログドメインとアプリケーション用のドメインだ。
ここで問題となるのが、ブログのデータベース。
前回の引越では、引越先にWordPressを再インストールし、WPの機能を使ってデータの保存と復元を行ったように記憶しているが、これだとうまくいかなかったので、今回は違う方法にした。
作業手順は以下のとおり。

(1)引越直前の作業

 Coreserverのアクセスログを取得
 引越対象のメールを受信

(2)DNS設定を変更

 当該ドメインを一時的に使えなくする(引越先には設定しない)。
 引越元のCoreserverのドメインウェブの設定を削除

(3)DBの保存

 引越前のCoreserverのDB管理画面からDBのデータを保存し、Coreserverのファイルマネージャを使って保存したファイルを自PCにダウンロードする

(4)サーバー間のデータコピー

 引越先のCoreserverのサーバー間コピーから、各ドメイン(サブドメイン)のデータを引越元からコピーする。
 WEB用データのみで、メールのデータはあきらめる。(← やってみたが動かなかった)

 ※引越元のFTPのアカウント情報が必要

 サーバー間コピーを使用すると、パーミッションもそのまま引き継がれるようだ。

 コピーの進捗はわからないので、同時に色々やらない方がよい。
 コピー中は、おとなしく待ち、時折、ファイルマネージャでどの程度コピーされたか確認するのが無難。
 

(5)DBの復元

 引越先Coreserverで、引越前と同じ文字コードのDBを作成(名前は異なってもよい)
 引越先Coreserverのファイルマネージャで、自PCに保存したDBのファイルをアップロード
 引越先Coreserverのデータベースで、復元先のDBを選択し、「復元」ボタンでデータを復元する。

(6)DNSを引越先サーバーに変更

(7)引越先Coreserverで、ドメインウェブの設定

おしまい。


m7.coreserver.jpからm22.coreserver.jpにサーバーを変更しました。

m7は、負荷率が高く、このブログでも画面の切り替えに1~3秒くらいかかっていました。
さすがに耐えられなくなり、サーバーを引っ越しました。

引っ越しの手順は次のとおり

(1)m22.coreserve.jpにアカウントを作成
 (1.1)必要なデータベースファイルを事前に準備しておく

(2)m7.coreserver.jpのデータをバックアップ
 (2.1)Webサイト(macroya.jp)のデータをバックアップ
 (2.2)Blogデータ(blog.macroya.jp)のデータをバックアップ
    ・WordPressのエクスポートツールを使用し、XML形式で保存
    ・テーマをバックアップ
    ・WordPressの設定やPlugInのインストール状況をメモ

(3)m22にデータをアップロード
 (3.1)WebサイトのデータをFTPでアップロード

(4)ValueDomainでDNSの設定m7からm22に変更

(5)m22でドメイン,メールの設定

(6)WordPressの再インストールと環境の復元
 ・テーマのインストール
 ・PlugInのインストール
 ・設定変更
 ・以前のBlogデータをインポート
  ※インポートツールは、ver.0.2を使用(ver.0.4は、メモリ不足エラーで動かない!)
  ※インポートすると、投稿に設定していたタグやカテゴリーは復元されない(カテゴリーの項目は復元される)

(7)m7のデータ削除・閉鎖

おしまい。
快適です。


昨日のつづき
Xreaのサーバー毎の負荷を調べてみた。
各サーバーの週毎の負荷率をグラフにしたものを次に示す(Fig.1~4)。
ピックアップしているのは最近登録可能なサーバーのみとした。

Fig.1 直近第1週のサーバー負荷率(週間平均値)

Fig.2 直近第2週のサーバー負荷率(週間平均値)

Fig.3 直近第3週のサーバー負荷率(週間平均値)


Xreaは、s368が定常的に20%前後の負荷率を示すが、全体的にはさほど、負荷は高くない状態にあると言える。
Coreserverに比べると、ハードウェアのスペックも低く、アカウント数も非公表であるだけに、高負荷状態にあることも考えられたが実際はそうでもない。
これはには、次の理由が考えられる。

  • (1)テストサーバーとして使用する人が多い。
  • (2)無料ユーザーの存在
  • (3)制限がある

上記(1)は、言葉の通りであるから説明は不要であろう。
上記(2)は、登録はしたけれども実際は使っていないというユーザーの存在。
上記(3)は、例えばデータベースの場合、無料ユーザーは、DBを1個しか使用できない。一方、有償(XreaPlus)の場合でもDBを5個までしか使用できない。
それに対し、Coreserverでは、CORE-MINIで10個使用でき、CORE-A以上なら無制限に使える。
最近は、WordPressやEC-CUBE、XOOPSなどCMSでDBを多用することもあり、CPUの負荷の多くは、DB制御によるものと考えられる。
加えて、DBの多用はCPU負荷よりもディスクアクセスの方で負荷がかかるため、サイトのレスポンスが悪く感じるのは、CPUの負荷というよりは、ディスクアクセスによるものと推察される。
昨日は、CORE-MINIのサーバー負荷を取り上げたが、CORE-Aは、もっと負荷が多いものがある。
Coreserverを選ぶときは、次の点に気をつけた方がよいだろう。
 契約可能な残りのアカウント数が少なく、現時点でサーバーの負荷が少ないもの!
やっぱり引っ越そうなかな…

負荷率について

負荷率は、次のように算出しています。
http://server.x24hr.com/にて得られる負荷は、一番負荷が低い状態が100、一番負荷が高い状態が0で表されます。
今回はxrea.com Free/Plus s300~から得られる負荷値を100から引いた値を負荷率(%)として表示しています。
なお、第1週の値は、1日~7日の平均値、第2週の値は、8~14日の平均値、第3週、第4週は、それぞれの値を使用しています。

Fig.4 直近第4週のサーバー負荷率(週間平均値)

参考にしたサイト




http://server.x24hr.com/

昨日のつづき
Coreserver(mini)のサーバー毎の負荷を調べてみた。
各サーバーの週毎の負荷率をグラフにしたものを次に示す(Fig.1~4)。
m7は、慢性的にサーバーの負荷が高い状態にあると言える。
ちなみに、このブログはm7を使用しています。
引っ越そうなかな…

Fig.1 直近第1週のサーバー負荷率(週間平均値)

Fig.2 直近第2週のサーバー負荷率(週間平均値)

Fig.3 直近第3週のサーバー負荷率(週間平均値)

負荷率について

負荷率は、次のように算出しています。
http://server.x24hr.com/にて得られる負荷は、一番負荷が低い状態が100、一番負荷が高い状態が0で表されます。
今回はcoreserver.jp (CORE-MINI)から得られる負荷値を100から引いた値を負荷率(%)として表示しています。
なお、第1週の値は、1日~7日の平均値、第2週の値は、8~14日の平均値、第3週、第4週は、それぞれの値を使用しています。
データ取得日は、2011/06/11です。

参考にしたサイト




http://server.x24hr.com/

先日、Xrea+からCoreserver miniにお引っ越ししました。
最近WordPressを使っていると、やたらと反応が悪いな~と思い、サーバーの負荷がどの程度か調べてみた。

http://server.x24hr.com/

XreaとCoreserverの負荷を調べられます。

結論から言うと、Core miniよりはXreaの方が負荷が少ないようです。
Xreaは、テストサーバーで使っている人が多いみたいなので、一時的に負荷が増えることはあっても、慢性的な高負荷状態にはないようです。
Coreserver系は、miniは全体的に負荷が高く、Core Aだとminiよりはマシです。
まだ引っ越したばかりだから、来年にCoreAにでも引っ越そうかと思います。

ブログ検索

ブログカレンダー

2024年11月
« 10月    
 12
3456789
10111213141516
17181920212223
24252627282930

Yahoo!ショッピング

アクセスカウンタ

  • 本日(回): 15
  • 週間(回): 295
  • 合計(回): 453829

Since 2011/07/01