しょうくん
Forum Replies Created
-
Posts
-
miz-rさん、こんにちは。
kusanagi init はタイムゾーンの設定や kusanagi ユーザーのパスワードの設定等、サーバーの基本になる設定を行う機能ですので、最初の段階であるならば、止めてしまっても問題は起こらないはずです。
ただし、パスワードの再設定等まで実施してしまうと、最初の設定と変わってしまった場合、何らかの不具合が発生する可能性もありますので、ご注意ください。tanapさん、こんにちは。
コンソール画面からとは、どこのクラウドのコンソール画面でしょうか。
通常クラウドの管理画面から起動を行えば復旧すると思われますが、環境を記載していただけないと判断できないですね。
よろしくお願いいたします。LEONさん、こんにちわ。
kusanagi provition は実行後すぐにそのプロファイルに切り替わっているはずです。
kusanagi status で現在のプロファイルを確認してみてください。keitoさん、こんにちわ。
まずWEXAL化したプロファイルを元に戻すにはコマンドが用意されています。その後、Premium Editionを yum でアンインストールすれば元のKUSANAGI状態に戻ると思いますが、当然WEXALの機能は使えなくなりますので、必要に応じてライセンスを購入しアップグレードすれば商用サイトでも使い続けることができます。
よろしくお願いいたします。
suzuki_takayukiさん、こんにちわ。
2つのWordPressを展開について、どのように展開することを考えているか分かりませんが、KUSANAGIは複数回Provisionを実行することで複数のWordPressを実行することが可能です。
アクセス数にもよりますが、ほとんどアクセスのない環境であれば数個以上Provisionしても安定して動作します。
ちなみに、DocumentRoot以下にさらにディレクトリを作成してWordPressをインストールする方法はKUSANAGIでは非推奨ですので、お勧めできません。keito さん、こんにちは。
WordPress内のKUSANAGIのメニューはKUSANAGIプラグインが表示しています。
muプラグインが上書きされて消されてしまったのだと思いますので、以下のスレッドを参考に復活させてみてください。
kusanagiのwordpressプラグインを削除してしまった場合の復元方法について移設の際には上書きに注意が必要です。気を付けましょう。
Uontyoo さん、こんにちは。
複数のWordPressはすべてkusanagiコマンドでプロビジョニングされたサイトでよろしかったでしょうか。
どこのサーバーであるのかなど、少し情報を頂けた方が返答も早いと思いますよ。よろしくお願いいたします。
byron222 さん、こんにちは。
ちなみに、状況はこの環境だけで発生していますか？
再現性の問題の切り分けが難しいかとは思いますが、どうようの状況が他でも発生しているのか、他では発生しなかったのかなどの情報があれば、是非お知らせください。よろしくお願いいたします。
mkon03さん、こんにちわ。
KUSANAGIの初回アクセスが遅くなるのは仕様です。
KUSANAGIはページキャッシュを使用せずに高速化する手法として、いかにオンメモリで動作が可能となるかを仕組みとして持っております。
具体的には、MySQLのクエリキャッシュとPHPの中間コードキャッシュをメモリ上にて保持し、展開することで、管理画面ですらも速くなるという事です。
これはそれぞれのページで初回アクセス時にMySQLのクエリキャッシュおよびPHPの中間コードキャッシュを作成するため、初回アクセス時のみある程度遅くなります。
つまり、一定数以上のアクセスがある限り、サイトを見に来てくれているユーザーに対しては速いレスポンスで返していることになりますので、偶然初回アクセスにあたらない限り遅いと感じることはありません。
ただし、残念ながらアクセス数の少ないサイト（ページ）では、初回アクセスに当たってしまう可能性が高くなってしまいますので、遅く感じてしまうかもしれません。その場合は、ページキャッシュ（fcacheもしくはbcache）を併用してみてはいかがでしょうか。KUSANAGIがどのように高速化されているのかは以下の連載で実際に試して頂くことも可能です。是非一度読んでみてください。
https://www.atmarkit.co.jp/ait/series/2117/kztmkzさん、こんにちわ。
Azure Marketplaceにて検索すると見つかりますが、どの手順で見つからないとなりますでしょうか。
https://azuremarketplace.microsoft.com/en-us/marketplace/apps/prime-strategy.kusanagi-77?tab=Overview少し情報が少なすぎて判断しずらいですね。
遅いというのは、どの程度遅いのでしょうか。
KUSANAGIですので、ツールバーにレスポンスタイムが表示されるかと思いますが、以下それぞれどの程度でしょうか。
・ダッシュボード
→ 初回アクセス時 2.775 sec
→ リロード時 0.054 sec
・外観
→ 初回アクセス時 0.063 sec
→ リロード時 0.055 sec
・プラグイン
→ 初回アクセス時 1.254 sec
→ リロード時 0.060 sec
上記はそれぞれ実際に運用中のサイトで上から順番にクリックしていった時のレスポンスです。
数値を見ても分かるかと思いますが、リロード時にはクエリキャッシュや中間コードキャッシュが働いて速く表示されています。
なお、インスタンスのスケールアップを実行した際には、configureコマンドを使用することをお勧めいたします。
https://kusanagi.tokyo/document/command/#configure
確認してみてください。strait.gateさん、こんにちは。
ステータスの表示で
*** Cache Status *** _http.conf: No such file or directoryとありますので、Nginxのconfファイルを探せていないようです。
Profile: abcとなっていますので、本来であれば /etc/nginx/conf.d/abc_http.conf を見ているはずですが、表示を編集しているのでなければプロファイルが読み込めていないと思われます。
Nginxのconfファイルを今一度確認してみてはいかがでしょうか。tomuuuuさん、こんにちは。
突然何らかの状況が変わることは考えづらいので、事象の発生したタイミングより前に、何か行われていないか確認して頂けると良いかと思われます。
例えば…
・新しいプラグインを導入した
・新しいテーマを導入した
・プラグインのアップデートがあった
・テーマのアップデートがあった
・プラグインの設定を変更した
・テーマの設定を変更した
・wp-config.phpを変更した
などが考えられます。
また、SSHにてログインして確認が可能なのであれば、プラグインディレクトリのユーザーやパーミッションを確認してみてはいかがでしょうか。TSUYOUSHIさん、こんにちは。
事象の件ですが、こちらは再現性がありますでしょうか。
例えば、新しくプロビジョンしたWordPressでも発生する、もしくは新しく作った別のインスタンスでも発生するなど、どこまで再現性があるか確認させて頂きたいと思います。なお、KUSANAGIはオンメモリにてどれだけ速くできるかという構成になっておりますので、MySQLのクエリキャッシュおよびPHPの中間コードキャッシュが生成されていない最初のアクセス、しばらくアクセスされていない状態でキャッシュがクリアされた状況でのアクセスは多少遅くなります。
また、上記仕様のため、極端にメモリの少ない環境（例えばメモリ1GB以下）での動作も遅くなる可能性があります。よろしくお願いいたします。
