Heihachiro
フォーラムへの返信
-
フォーラム: その他
返信が含まれるトピック: サーバースペックの決め方WPにとってCPUの性能があまり大きく関わりはしないというのはショックでした。
表現がわかりにくかったですかね。WEBサーバやDBサーバなどを介して間接的には大きく影響します。コア数だけに限定して話をすると多いと一度にさばける処理が増えますから、アクセスの多いサイトの場合、アクセスピーク時には大きな違いがでるでしょう。逆にアイドル状態だと体感的には違いが感じられないかも知れません。
例えるならスーパーのレジのようなものを想像していただければイメージが掴みやすいかと思います。混雑時にはたくさん必要ですが、お客さんが少ない時にはあまり意味がありません。またコンビニのような小さな店にもたくさんのレジは必要ありません。
DB Cache Reloaded Fix というプラグインですが、ちょっと仕組みを調べてみるとDBクエリのキャッシュファイルをサーバ上に作成するみたいですね。するとキャッシュの作成や読み込みの度にそのファイルにアクセスするわけですから、DBサーバの負荷は減らせますがサーバ全体の負荷はあまり変わらないのでは無いかと思います。まったく効果が無いとまでは言いませんが、これはWEBサーバとDBサーバが別々になっている共有サーバなどで特に効果を発揮するプラグインではないでしょうか。
一般論になってしまいますが、アクセスがそれなりにあるなら、CPU性能は高い方が、メモリ量は多い方が良いです。ただ費用対効果を考えてスペックをどの辺に設定するかは結構難しい問題ですから、その辺はご自分で判断していただきたいと思います。
フォーラム: その他
返信が含まれるトピック: サーバースペックの決め方サーバのメモリは多ければ多いほど良いと思います。ただマネージドプランだとせっかくのメモリを上手く使えないかも知れませんね。
CPUに関してはアクセスピーク時を除いてほぼアイドル状態というのも珍しくないですが、逆にある程度の余裕がないとピーク時にアクセスをさばけません。CPUのコア数はWPとは直接の関係はないですが、コア数が多いとWEBサーバなどのソフトウェアが一度にさばける処理が増えます。
あとDBを使用するCMSの場合は、ストレージ(ハードディスク)の読み書きがボトルネックになる事も多いです。その場合は一つの解決策としてMySQLのキャッシュサイズを増やすのですが、こういう時にサーバのメモリが多いと有利になるのです。ただこういうソフトウェア毎の細かい設定がさくらのマネージドプランで可能かどうかは解りません。
Core i5 と QuadCore Xeon のどちらかで悩まれているという事ですが、試用期間が無い上に高額な初期費用があるというのでは悩まれるお気持ちはよく解ります。ただそれだけにこちらも迂闊なアドバイスはできません。
試用期間のある他社のサービスを利用するとか、スケールアップ&ダウンが容易なクラウドを利用するという選択肢もあるかと思いますが、まずはご利用中の coreserver のサーバスペックを確認してみるのも良いかも知れません。
フォーラム: マルチサイト
返信が含まれるトピック: 50を超えるマルチサイトの運用データベースだけを考えた場合、
共有サーバだとテーブル数よりはDB同時接続数が先に問題になるかと思います。そして同時接続数の問題を解決するために複数のDBに分散させるプラグインがそのSharDBというプラグインなのですね。私は利用した事がないですが、heteml.jp はDBを100個まで作成できるみたいですから、スペック上は50サイト程度なら問題なく運用できるでしょうね。
転送量については1日20GBが目安という事らしいので、メディアファイルやアクセスのあまり多くない50サイト程度であれば上限に達することもないでしょう。WordPress本体のPHP処理に伴う負荷もこれまたあまりアクセスが多くなければなんとかなるかも知れません。
ただスペック上可能という事とそれを選択するかは別の問題で、個人の趣味サイトならともかく人様のサイトを管理するとなれば、自分で十分な検証を行った後で、ある程度スペックに余裕を持てるようでないと本番環境を運用するのはおすすめできません。複数のDBのメンテナンスをどうするかという問題もあります。
VPSやクラウドもそれはそれでまた別の知識や経験を必要としますから、ただちに選択肢とならないかも知れませんが、情報も得やすいですし長い目でみればこっちの方が管理が楽かも知れませんね。
本日XREAより一時ディレクトリのパーミッションを修正したとの連絡があり、当方の検証用アカウントにてエラーが修正されているのを確認いたしました。
なので今回のエラーの原因はサーバの設定で確定で良いと思います。
ただ「パーミッションが書き換わる原因を特定出来ておりませんので、引き続き調査させていただきたく存じます」との事なので、今後また同様のエラーが発生する可能性が残ってしまいました。
フォーラム: 使い方全般
返信が含まれるトピック: 新規投稿画面が崩れるみなさんのお邪魔をしないようにずっと黙って経過を見ていようと思っていたのですが、意見をいわないと逆に不実であるように思えてきたのでお目汚しながら私見を申し上げます。
私は以前hpb17を試用した事がありますので、再び試用版をインストールしてそちらから問題を検証しております。
今のところ今回のトラブルの原因と思われそうな部分は以下の通りです。少々難しいので s_sharksさんはとりあえず無視してください。
hpbダッシュボードという管理画面をカスタマイズするプラグインが同梱されており、このプラグインは wp-optionsテーブルに設定データを格納しています。
問題となっているテーマですが、私は試用版のため[ベーシック0001]というテーマしか利用できませんが、浅薄な私の知識だとfunctions.phpにカスタム投稿タイプの設定が書かれているだけの普通のテーマのように思えます。ただテーマはGPLライセンスみたいなので、WEBにアップロードすればもっと詳しい方に検証していただく事も可能かと思います。
「固定ページ作成」はhpbのUI上と、WordPressの管理画面の両方から作成・編集でき、hpb上から作成したページはその後wordPress上で「同期」する必要があります。これは未検証なのですが wp-postや wp-postmetaのデータに異常があれば新規投稿や編集ができなくなる可能性もあるんじゃないでしょうか。
検証が中途半端で申し訳ありませんがとりあえず以上です。
フォーラム: 使い方全般
返信が含まれるトピック: 新規投稿画面が崩れるgatespaceさん
私としてはs_sharksさんを一方的に批判しているつもりはありませんでしたが、ホームページビルダー17の新機能に関する予備知識がありましたので、そのせいで先入観に囚われていたようです。フォーラムの他の皆さんにも重ねてお詫び申し上げます。今後発言は慎重に致します。
フォーラム: 使い方全般
返信が含まれるトピック: 新規投稿画面が崩れるshokun0803さん、gatespaceさん、フォローありがとうございます。今お二人のレスを見て少々恥ずかしい思いをしております。
私としては原因を特定するためにも可能性の高いものから順にトラブルシューティングすべきと言いたかったのですが、表現がキツくなってしまった点については反省しております。s_sharksさんがお気を悪くされたならどうかお許し下さい。
フォーラム: 使い方全般
返信が含まれるトピック: 新規投稿画面が崩れる今回のトラブルの原因となりそうな操作の心当たりが、ホームページビルダー17によるアップロードなのですよね? ならばまずホームページビルダー側の不具合を疑い、その可能性が消えた後にWordPress側の原因を疑うというのが順当な流れではないでしょうか。
どうも、ページがちゃんと読み込まれていないようなんですが…
アップロードに失敗していたりすればファイルがちゃんと読み込まれないのも不思議ではありませんし、ホームページビルダーの機能によってはバグを発生させている可能性も否定できません。
アップロードによる不具合だけを解決するならWordPressファイルをホームページビルダーを使わずに全て再アップロードし、今後ホームページビルダーを使わないという手もあるかも知れませんが、ホームページビルダーに起因する問題についてはホームページビルダー側で対処していただく他ないと思います。
P.S. また今後同様のトラブルを避けるためにも、サーバ上のファイルに変更を加える前には必ずバックアップを取るようにした方が良いでしょう。
フォーラム: 使い方全般
返信が含まれるトピック: 新規投稿画面が崩れる失礼ながら状況を見る限り、そういう問題はまずメーカーのサポートに相談なされるべきだと思います。
ホームページビルダー17が一方的にWordPress対応を機能としてうたっているだけですらから、その機能に不備があるならばメーカー側が対応すべきでしょう。
ただホームページビルダー17が今後普及するとすれば、情報共有という意味では有益だと思いますので、なんらかの解決がなされましたら詳細を報告いただけると他の方の助けとなるかも知れません。
フォーラム: 使い方全般
返信が含まれるトピック: サーバー移転に伴いURLを変更する場合のお知らせ方法ああ、記載内容に一部書き加えようとしたら二重投稿してしまいました。
お目汚ししてすいません。
フォーラム: 使い方全般
返信が含まれるトピック: サーバー移転に伴いURLを変更する場合のお知らせ方法少々誤解があるようなので横レス失礼しますね。私の勘違いだったらごめんなさい。
.htaccessによるリダイレクトは WordPress とは関係の無いWEBサーバの機能ですから、.htaccessをきちんと記述して置いておけば WordPress は削除してもリダイレクトは機能します。もちろん移転元のサーバで .htaccess によるリダイレクト機能が使えるというのが前提条件ですが。
質問者さまは「通常のホームページの移転と同様」を前提とされていますが、popupさんがおっしゃる通り「WPの場合も同じ」です。
popupさんが紹介されているプラグインは .htaccessが使えないサーバなどで、PHPによるリダイレクトを簡易に実現するためのものですね。必要がなければあえて使う事はありません。
フォーラム: 使い方全般
返信が含まれるトピック: サーバー移転に伴いURLを変更する場合のお知らせ方法少々誤解があるようなので横レス失礼しますね。私の勘違いだったらごめんなさい。
.htaccessによるリダイレクトは WordPress とは関係の無いWEBサーバの機能ですから、.htaccessをきちんと記述して置いておけば WordPress は削除してもリダイレクトは機能します。もちろん移転元のサーバで .htaccess によるリダイレクト機能が使えるというのが前提条件ですが。
popupさんが紹介されているプラグインは .htaccessが使えないサーバなどで、PHPによるリダイレクトを簡易に実現するためのものですね。必要がなければあえて使う事はありません。
トピックは解決済みとなりましたが、その後の経過報告を致します。
本日XREA側にサーバの不具合の可能性を報告し、現在対応・返信待ちです。トラブルが改善するか、サポートより返信がありましたら詳細と併せてまた報告させていただきます。
gatespaceさん
WordPress特有のバグではなさそうなんですね？
その後色々と調べていたら、Codex のトラブルシューティングに同様のエラー(Errcode: 13)に関する項目があるのを見つけました。英文が未訳ですが、要するに一時ディレクトリを書きこみできるようにしなさい云々という事が書いてあります。つまり WordPress環境でよく起こるトラブルではあるが、WordPressに起因した問題ではないという事ではないですかね。
http://wpdocs.sourceforge.jp/FAQ/%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0#SQL.2FDB_Error_errcode_13_Can.27t_create.2Fwrite_to_file_.E3.81.A8.E3.81.84.E3.81.86.E3.82.A8.E3.83.A9.E3.83.BC.E3.82.92.E8.A7.A3.E6.B1.BA.E3.81.99.E3.82.8B.E3.81.AB.E3.81.AF.EF.BC.9Fまた同じ s501サーバにて、WordPressではない別のCMSのインストール時に同様のエラーが発生してインストールができない云々という報告も見つけました。
http://concrete5-japan.org/community/forums/hosting/post-403/post-5557/という事で十中八九はサーバ側の問題と思っていますが、原因を確定とするのはXREAからの返信を待ちたいと思います。
上記の件が気になったので追跡調査を行い、不具合が再現されましたので報告します。
サーバーはXreaのレンタルサーバーで
PHPは5.4.7
MySQLは5.5.28XREAのサーバでPHPが5.4.7でMySQLが5.5.28というのは、最近新しく追加された s501.xrea.com というサーバの事と思われます。そこでこの s501サーバのアカウントを新たに取得し、WordPressをインストールしてみたら同じ現象が再現されました。
PHPinfoを確認すると、この s501サーバはPHPやMySQLのバージョンだけでなく、PHPの設定などもこれまでのサーバとは若干違うようです。例えばXREAのこれまでのサーバだとPHPはデフォルトでモジュール版だったのでセーフモードによる制限がありましたが、s501サーバはデフォルトでCGI版のPHPが動作しています。
話は不具合に戻りますが、s501サーバ上のWordPressの管理画面よりカテゴリーを新たに追加しても、画面を更新すると管理画面上にて作成したカテゴリーが表示されないばかりか、本来あるはずの「未分類」カテゴリーも表示されません。タグの追加も同様です。そこでphpMyAdmin経由でデータベースを確認すると、データベース上にはちゃんとカテゴリーが追加されていました。
次に wp-config.php ファイルの、define(‘WP_DEBUG’, false); を true にしてデバッグを行なってみたところ、カテゴリーページやタグページ、投稿一覧ページなどで以下の様なエラーメッセージが表示されました。
WordPress database error: [Can’t create/write to file ‘/mnt/ram/#sql_236c_0.MYI’ (Errcode: 13)]
SELECT t.*, tt.*, tr.object_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN (‘category’, ‘post_tag’, ‘post_format’) AND tr.object_id IN (1) ORDER BY t.name ASCこれはおそらくデータベースの wp_termsテーブル から読みだしたデータを一時領域に展開できていないという意味だと思われます。Errcode: 13 というエラーコードは MySQL にアクセス権限が無い(permission denied)という意味になります。
http://dev.mysql.com/doc/refman/5.1/ja/operating-system-error-codes.html同じようなエラーの報告が英語版フォーラムにもありました。
http://wordpress.org/support/topic/wordpress-database-error-cant-createwrite-to-file-tmpsql_3a2a_0myi以上の検証により今回の不具合は、WordPressの問題というよりはサーバ側の設定の問題である可能性が高いと私は考えます。XREA側にはもう少し情報を整理してから不具合を報告するつもりでおりますが、mk.tknさんは差し当たり s501 以外のサーバに移られた方が良いと思います。
XREAやCORESERVERをいくつか利用しています。私の所でも同じような問題は起きていません。
症状から推測するに .htaccess (今回の場合はPHPのセーフモード)に起因する問題では無いように見受けられます。セーフモードはサーバ上の実ファイルの操作に関する設定ですから、カテゴリの登録などのDBの操作には影響を与えません。
そしてこれもまた推測なのですが、サーバ上のファイルに欠損あるいは破損しているものがある様に私には思えます。要するにFTPでのアップロードやファイルの展開に失敗しているのですね。
あとはサーバ側の不具合でしょうか。いずれにせよWordPress側の問題とするには情報が少ないように思えます。
少し前に同じ環境で同じような質問をされていた方がいたのが少々気にはなりますが…