新規記事の投稿を行うことで、非表示にすることが可能です。
HTMLを更新後、表示が変更前のままです。コレで直ります【エックスサーバー】
データベースや、テキストファイルのデータを表示するPHPのオリジナルサイト、フレームワークを使ってサイトは、データベースやテキストファイルを最新の内容に書き換えても修正内容が反映されないことが起きやすいです。ワードプレスのサイトはこれには該当しないので安心して利用できます。PHPオリジナルサイトの話です。
エックスサーバーは、PHPの初回実行時に、PHPの内容を最適化した状態でキャッシュしておき、次回以降、 同じPHPにアクセスがあった際にキャッシュしたPHPで高速になる機能が標準装備されています。(APC / OPcache）
コンパイル済みPHPプログラムをメモリに格納して、メモリ上のプログラムを再利用しています。
PHPプログラムから読むテキストファイルに変更を加えても、サイトの表示は変更前のままでした。
利用しているとプログラムの実行結果もキャッシュされていると感じることが多いです。
また、「mod_pagespeed設定」を有効にすると、ファイルを圧縮してデータ転送量を削減する、同種のファイルを一まとめにして無駄な通信を削減するなどの最適化処理を実行しています。
今このmod_pagespeedはOFFの設定でも、表示が修正前のままの状態になっています
HTMLテキストファイルを更新し、表示が反映されないのは、キャッシュが原因です。
キャッシュをクリアするには、PHPファイルの日付を最新にするのが最も簡単な方法です。
以下、sshでxserverにログインして、PHPファイルの日付を更新する方法です。
cd ドメイン/public_html/
(ドメインの公開フォルダに移動します。)
ls *.php
(PHPファイルの一覧を表示させます。）
目的のファイルの日付を更新します。
touch php-file-name.php
touchコマンドは、存在するファイルの日付を最新にします。
ファイルが存在しない場合、新規作成してしまうので、打ち間違いに注意してください。
間違ってファイルを作ってしまったら、以下コマンドで消すことができます。
rm -i 間違って作ってしまったファイル名
-iパラメーターを指定することで確認メッセージが表示されます。
これで、ブラウザで表示を更新すると最新の内容に反映されたことが確認できます。
もし、直っていない方は、更新すべきphpファイルを間違えている可能性があります。
.htaccessでRewriteしている場合、index.phpも合わせてtouchしてみると直る可能性があります。
HTMLを更新後、表示が変更前のままです。コレで直ります【エックスサーバー】
エックスサーバーは、PHPの初回実行時に、PHPの内容を最適化した状態でキャッシュしておき、次回以降、 同じPHPにアクセスがあった際にキャッシュしたPHPで高速になる機能が標準装備されています。(APC / OPcache）
コンパイル済みPHPプログラムをメモリに格納して、メモリ上のプログラムを再利用しています。
PHPプログラムから読むテキストファイルに変更を加えても、サイトの表示は変更前のままでした。
利用しているとプログラムの実行結果もキャッシュされていると感じることが多いです。
また、「mod_pagespeed設定」を有効にすると、ファイルを圧縮してデータ転送量を削減する、同種のファイルを一まとめにして無駄な通信を削減するなどの最適化処理を実行しています。
今このmod_pagespeedはOFFの設定でも、表示が修正前のままの状態になっています
HTMLテキストファイルを更新し、表示が反映されないのは、キャッシュが原因です。
キャッシュをクリアするには、PHPファイルの日付を最新にするのが最も簡単な方法です。
以下、sshでxserverにログインして、PHPファイルの日付を更新する方法です。
cd ドメイン/public_html/
(ドメインの公開フォルダに移動します。)
ls *.php
(PHPファイルの一覧を表示させます。）
目的のファイルの日付を更新します。
touch php-file-name.php
touchコマンドは、存在するファイルの日付を最新にします。
ファイルが存在しない場合、新規作成してしまうので、打ち間違いに注意してください。
間違ってファイルを作ってしまったら、以下コマンドで消すことができます。
rm -i 間違って作ってしまったファイル名
-iパラメーターを指定することで確認メッセージが表示されます。
これで、ブラウザで表示を更新すると最新の内容に反映されたことが確認できます。
もし、直っていない方は、更新すべきphpファイルを間違えている可能性があります。
.htaccessでRewriteしている場合、index.phpも合わせてtouchしてみると直る可能性があります。
AMP対応ページは、別ドメインでも公開可能だが、警告が出る
完全に別のドメインのAMPサイトを公開した場合、元々のPCページとの関係性をGoogleがどう管理してるのかがわかりました。今回無料ブログをPC向けサイト、独自ドメインをAMP専用サイトとしてAMP対応してみました。多くの無料ブログはAMP（Accelerated Mobile Pages）に未対応です。無料ブログから独自ドメインへ全面移行してしまえば簡単ですね。でも試しにドメインが異なるAMPサイトを公開しました。完全に別のドメインのサイトになります。
具体的には、無料ブログのheadに<link ref="amphtml" href=https://"独自ドメイン/..."/>を追加して、独自ドメイン(HTTPS)のAMPページへ飛ばしています。
無料ブログ(PC向けサイト）、独自ドメイン（AMPサイト)共にGoogle Search Console、Google アナリティクスに登録しています。
Google Search Consoleの検索での見え方からAccelerated Mobile Pagesのインデックスに登録された AMP ページ数や重大な問題のある AMP ページを知ることができます。
PCサイトからAMPサイトへリンクを貼ってしばらく経つと、PCサイトのサーチコンソールに「新しい重要メッセージ」が届きます。
PCサイトURLのAMPドメインの更新というタイトルでした。
独自ドメイン側に出てくるかと思っていましたが、１週間経っても「Accelerated Mobile Pages は見つかりませんでした」のまま。きっとこっちには登録されませんね。
無料ブログ（PC向けサイト）：Accelerated Mobile Pagesのインデックス状況が表示されます。
独自ドメイン(AMPサイト)：表示されません。「サイトにAccelerated Mobile Pages は見つかりませんでした」
この先ドメインを統合するまで、ずっとこの警告が表示され続けることになります。
検索での見え方は、独自ドメイン(AMPページ）で選択できます。
通常、同一ドメインでAMP対応した場合、検索トラフィック＞検索アナリティクスのフィルタ項目に「検索での見え方」が追加選択できるようになります。フィルタなし、AMPなどが選べますよね
無料ブログ（PC向けサイト）：「検索での見え方」フィルタはありません。
独自ドメイン(AMPサイト)：「検索での見え方」があります。
ここまでのまとめてとして、別ドメインでAMPページを公開すると以下のようになります。
続いては、Googleの検索結果です。
別ドメインでAMPページを公開し、Accelerated Mobile Pagesで重大なエラーがないページは稲妻マークのAMPページとして検索結果に表示されます。
PCブラウザの検索結果はPCサイトのURLをナビゲートしていました。
一方スマホブラウザの検索結果は、見た目PCサイトのURLですが、AMPサイトが表示されます。
iPad Proで検索した結果、AMPサイトが表示されました。
AMPページ対応することで、いままで通りパソコンのブラウザで検索した訪問者をPCサイトへ流せます。
タブレット、スマホのブラウザで検索した訪問者をAMPサイトへ流すことができます。
検索結果をクリックした後、AMPサイトが表示されたタイミングで初めてドメインが違うことがわかる仕組みでした。そのため、Googleは別ドメインで実装したAMPページに警告を表示しているんですね。
具体的には、無料ブログのheadに<link ref="amphtml" href=https://"独自ドメイン/..."/>を追加して、独自ドメイン(HTTPS)のAMPページへ飛ばしています。
Google Search Console
無料ブログ(PC向けサイト）、独自ドメイン（AMPサイト)共にGoogle Search Console、Google アナリティクスに登録しています。
Google Search Consoleの検索での見え方からAccelerated Mobile Pagesのインデックスに登録された AMP ページ数や重大な問題のある AMP ページを知ることができます。
Accelerated Mobile Pages（検索での見え方）はPCサイト(無料ブログ）で確認できます
PCサイトからAMPサイトへリンクを貼ってしばらく経つと、PCサイトのサーチコンソールに「新しい重要メッセージ」が届きます。
PCサイトURLのAMPドメインの更新というタイトルでした。
独自ドメイン側に出てくるかと思っていましたが、１週間経っても「Accelerated Mobile Pages は見つかりませんでした」のまま。きっとこっちには登録されませんね。
無料ブログ（PC向けサイト）：Accelerated Mobile Pagesのインデックス状況が表示されます。
独自ドメイン(AMPサイト)：表示されません。「サイトにAccelerated Mobile Pages は見つかりませんでした」
警告が表示されます。Accelerated Mobile Pages > AMP ページのドメイン不一致（問題の重大性: 重要ではない問題）
AMP ページをホストしているドメインが正規ページのドメインと異なると、AMP ビューアでユーザーの混乱を招く恐れがあります。
この先ドメインを統合するまで、ずっとこの警告が表示され続けることになります。
検索アナリティクス（検索トラフィック）
検索での見え方は、独自ドメイン(AMPページ）で選択できます。
通常、同一ドメインでAMP対応した場合、検索トラフィック＞検索アナリティクスのフィルタ項目に「検索での見え方」が追加選択できるようになります。フィルタなし、AMPなどが選べますよね
無料ブログ（PC向けサイト）：「検索での見え方」フィルタはありません。
独自ドメイン(AMPサイト)：「検索での見え方」があります。
Google Search Consoleの別ドメイン AMPページのまとめ
ここまでのまとめてとして、別ドメインでAMPページを公開すると以下のようになります。
- AMP ページのドメイン不一致警告が表示される
- Accelerated Mobile Pagesインデックス状況は、PC向けサイト
- AMPのクエリ、ページのCTR、掲載順位は、AMPサイト
続いては、Googleの検索結果です。
Googleの検索結果
別ドメインでAMPページを公開し、Accelerated Mobile Pagesで重大なエラーがないページは稲妻マークのAMPページとして検索結果に表示されます。
PCブラウザの検索結果タイトル | スマホブラウザの検索結果タイトル |
PCブラウザの検索結果はPCサイトのURLをナビゲートしていました。
一方スマホブラウザの検索結果は、見た目PCサイトのURLですが、AMPサイトが表示されます。
iPad Proで検索した結果、AMPサイトが表示されました。
AMPページ対応することで、いままで通りパソコンのブラウザで検索した訪問者をPCサイトへ流せます。
タブレット、スマホのブラウザで検索した訪問者をAMPサイトへ流すことができます。
検索結果をクリックした後、AMPサイトが表示されたタイミングで初めてドメインが違うことがわかる仕組みでした。そのため、Googleは別ドメインで実装したAMPページに警告を表示しているんですね。
タグ：AMPページ
database is lockedに悩んだら、コレで解決！原因は予想外のコイツ！でした
SQLite3でたまに発生するdatabase is lockedって悩ましいですよね。勝手にロック解除してくれるとありがたいんですがlock状態を継続してしまうので時間経過で問題も大きくなりがちです。ここではdatabase is lockedになったデータベースファイルをunlockの状態に戻す方法、真の原因、lockされているデータベースファイルを特定する方法などがわかります。
ここではロックされているデータベースをdb.sqlite3としています。アンロックする方法自体はとても簡単でした。リモートログインしてshell操作する必要があります。FTPでも同様のことができるかもしれませんが、ここでは試していないのです。
移動して、コピーすることで、unlockできました。
1. mv db.sqlite3 bk.db.sqlite3
ロックされているSQLite3のデータベースファイルを別名にします。(mv)
2. cp -p bk.db.sqlite3 db.sqlite3
元と同じファイル日付で、元と同じファイル名としてコピーします。(cp -p)
たったこれだけの操作で悩み悩んだdatabase is lockedが回避できました。
ファイルを別名し、コピーすることでロックが解除できます。
sqlite3データベースにロック情報が記録されているのであれば、この操作では中身を一切書き換えていないので、アンロックされることはあり得ません。
このことからロックの原因は、PHPのSQLite3 拡張モジュールで使われているflock系のシステムコールに起因すると想像しています。
SQLite3データベースをunlockする方法にflock系のシステムコールがロックの原因と書きました。これは誰かがflockしているからdatabase is lockedが発生してしまうことになります。では、誰が一体flockをやっているのか？遅延書き込みなどの要因？
疑問でしたが、ようやくわかりました。まず以下のような設計でクーロン実行させています。
このような状況下で、database is lockedが発生しました。SQLite3データベースをunlockする方法で解決しますがロックさせてしまう根本的な対処にはなっていないですよね。
プログラムの設計上、シングルで動作しているのでロックされること自体ありえないって思っていました。原因は、プログラムの重複実行でした（笑）
予想外です。まさかの自分自身のプログラムがdatabase is lockedの要因を作っているなんて・・・
ただ、これ自分でプログラムを複数実行しているわけではないです。スケジュール実行で自動実行されています。今回対象のプログラムは30秒以上動作することがあるのでMaximum execution timeになり、プログラムが強制終了していたはずなのですが。。。どうやら生き残る生命力豊かなたくましい奴がたまに誕生するようです。
１）Maximum execution timeになる処理はデータベースの更新を含んでいるのでタイミングが悪いとトランザクションでロックした状態になりえます。
２）そのため次のスケジュール実行で動いたクーロンプログラムがdatabase is lockedで失敗する
この流れでdatabase is lockedが発生していたと確信しています。
根本的な原因はクーロンが生き残ることがあるということでしたね。あとはこれに対応できるようにプログラムを変えるだけです。例えば29秒経過したら自発的に正常終了させる、クーロン実行されたプログラムのPIDを記録して、killするようにする、ロックの回避方法はわかっているのでロックが発生したらロックの回避方法を試すなどのことをやればdatabase is lockedを撲滅できそうです！
database is lockedエラーが発生した、１つのSQLite3データベースだけ扱っていればロックされたデータベースの特定は簡単ですよね。複数のSQLite3データベースがあるとどれ？これ？どうやって調べるの？となります。どうしたら単純に調べられるのか、コマンドを色々試して見つけたのがこの方法です。
この方法は、リモートログインして確認します。
シェルからsqlite3コマンドでSQLite3データベースファイルに対してVACUUMコマンドを実行する方法です。
$ sqlite3 データベース "vacuum;"
lockedの状態のデータベースファイルは、このコマンドを拒否します。
SQL error: database is locked
というメッセージが出力されます。
問題なければ、VACUUMにより空き領域が解放されます。データベースサイズが膨れていくので定期的にVACUUMコマンドを実行するのが良いとされていますよ。一石二鳥の確認方法ですね！
１つ注意点があって、他のプログラムやPHPからアクセス中にはやらない！ってことです。やっても良いですが失敗する可能性があるのと、参照している側もそのタイミングにアクセスすることでCRUDが失敗する恐れもあります。そのため、アクセスが少ない時にやったほうが良さそうです。
ちなみにCRUDは、Create/Read(select)/Update/Deleteのデータベース操作を示しす用語です。
いかがでしたでしょうか？ここまでSQLite3データベースをunlockする方法、database is lockedが発生した真の理由、ロックされている？データベースロックの確認方法をご紹介してきました。
database is lockedは回避できましたでしょうか。
今回ご紹介したこの方法で私は回避できました。たまに間違えるのですが、mvは重要です。消すのは怖いからと代わりにcpでやると解決できません。lockの状態を継続しますよ。必ず元あったデータベースファイルの存在を消す！ってことが重要です
参考までに、この現象は、xserverで遭遇しました。
SQLite3のバージョンは、SQLite version 3.3.6です。
PHPのバージョンは、7.0.16です。
SQLite3データベースをunlockする方法
ここではロックされているデータベースをdb.sqlite3としています。アンロックする方法自体はとても簡単でした。リモートログインしてshell操作する必要があります。FTPでも同様のことができるかもしれませんが、ここでは試していないのです。
移動して、コピーすることで、unlockできました。
1. mv db.sqlite3 bk.db.sqlite3
ロックされているSQLite3のデータベースファイルを別名にします。(mv)
2. cp -p bk.db.sqlite3 db.sqlite3
元と同じファイル日付で、元と同じファイル名としてコピーします。(cp -p)
たったこれだけの操作で悩み悩んだdatabase is lockedが回避できました。
ファイルを別名し、コピーすることでロックが解除できます。
sqlite3データベースにロック情報が記録されているのであれば、この操作では中身を一切書き換えていないので、アンロックされることはあり得ません。
このことからロックの原因は、PHPのSQLite3 拡張モジュールで使われているflock系のシステムコールに起因すると想像しています。
database is lockedが発生した真の理由
SQLite3データベースをunlockする方法にflock系のシステムコールがロックの原因と書きました。これは誰かがflockしているからdatabase is lockedが発生してしまうことになります。では、誰が一体flockをやっているのか？遅延書き込みなどの要因？
疑問でしたが、ようやくわかりました。まず以下のような設計でクーロン実行させています。
- １）プログラムはPHPで作っています。クーロン実行させています。
- ２）エックスサーバーのクーロンは、１回で動作できる時間が30秒までの制限があります。
制限に達するとこのようなPHP Fatal error: Maximum execution time of 30 seconds exceededエラーメッセージとともに強制終了されます。 - ３）PHPプログラムは、SQLite3データベースに同時にアクセスしない設計になっています。そのタイミングでCRUDを行うのは１つのプログラムだけです
このような状況下で、database is lockedが発生しました。SQLite3データベースをunlockする方法で解決しますがロックさせてしまう根本的な対処にはなっていないですよね。
プログラムの設計上、シングルで動作しているのでロックされること自体ありえないって思っていました。原因は、プログラムの重複実行でした（笑）
予想外です。まさかの自分自身のプログラムがdatabase is lockedの要因を作っているなんて・・・
ただ、これ自分でプログラムを複数実行しているわけではないです。スケジュール実行で自動実行されています。今回対象のプログラムは30秒以上動作することがあるのでMaximum execution timeになり、プログラムが強制終了していたはずなのですが。。。どうやら生き残る生命力豊かなたくましい奴がたまに誕生するようです。
１）Maximum execution timeになる処理はデータベースの更新を含んでいるのでタイミングが悪いとトランザクションでロックした状態になりえます。
２）そのため次のスケジュール実行で動いたクーロンプログラムがdatabase is lockedで失敗する
この流れでdatabase is lockedが発生していたと確信しています。
根本的な原因はクーロンが生き残ることがあるということでしたね。あとはこれに対応できるようにプログラムを変えるだけです。例えば29秒経過したら自発的に正常終了させる、クーロン実行されたプログラムのPIDを記録して、killするようにする、ロックの回避方法はわかっているのでロックが発生したらロックの回避方法を試すなどのことをやればdatabase is lockedを撲滅できそうです！
ロックされている？データベースロックの確認方法
database is lockedエラーが発生した、１つのSQLite3データベースだけ扱っていればロックされたデータベースの特定は簡単ですよね。複数のSQLite3データベースがあるとどれ？これ？どうやって調べるの？となります。どうしたら単純に調べられるのか、コマンドを色々試して見つけたのがこの方法です。
この方法は、リモートログインして確認します。
シェルからsqlite3コマンドでSQLite3データベースファイルに対してVACUUMコマンドを実行する方法です。
$ sqlite3 データベース "vacuum;"
lockedの状態のデータベースファイルは、このコマンドを拒否します。
SQL error: database is locked
というメッセージが出力されます。
問題なければ、VACUUMにより空き領域が解放されます。データベースサイズが膨れていくので定期的にVACUUMコマンドを実行するのが良いとされていますよ。一石二鳥の確認方法ですね！
１つ注意点があって、他のプログラムやPHPからアクセス中にはやらない！ってことです。やっても良いですが失敗する可能性があるのと、参照している側もそのタイミングにアクセスすることでCRUDが失敗する恐れもあります。そのため、アクセスが少ない時にやったほうが良さそうです。
ちなみにCRUDは、Create/Read(select)/Update/Deleteのデータベース操作を示しす用語です。
まとめ
いかがでしたでしょうか？ここまでSQLite3データベースをunlockする方法、database is lockedが発生した真の理由、ロックされている？データベースロックの確認方法をご紹介してきました。
database is lockedは回避できましたでしょうか。
今回ご紹介したこの方法で私は回避できました。たまに間違えるのですが、mvは重要です。消すのは怖いからと代わりにcpでやると解決できません。lockの状態を継続しますよ。必ず元あったデータベースファイルの存在を消す！ってことが重要です
参考までに、この現象は、xserverで遭遇しました。
SQLite3のバージョンは、SQLite version 3.3.6です。
PHPのバージョンは、7.0.16です。
️UTF-8に置き換えました。ウェブフォント読み込み中のテキストの表示警告（ `font-display`）