Google Search Console に新しいサブドメインのサイトを登録する。

Google Search Console に新しいサブドメインのサイトを登録してみました。別の新しいドメインの場合も同じかと思います。そのやり方を記載しておきます。

Search Console にログインして管理画面の左上にあるサイトの選択リストから「プロパティを追加」を選びます。

プロパティタイプの選択の画面が表示されます。ドメインのほうに新しく登録するサブドメインを記載します。「続行」のボタンを押下します。

DNSレコードでのドメイン所有権の確認の画面が表示されます。DNSのTXTレコードに登録するコードが表示されているので、これをコピーします。右下の「確認」ボタンはまだ押下しません（そのままにしておく）。

別のウィンドウでDNS設定の画面を開きます。僕の場合は LightSail(Amazon linux 2023) を使用していますので、その画面の例です。

レコードタイプには「TXTレコード」、レコード名は「@」、TXTレコードの応答内容に先ほどコピーしたコードを記載します。記載をしたら「保存」を押下します。

DNSのTXTレコードの登録が完了したら、先ほどのDNSレコードでのドメイン所有権の確認の画面で「確認」ボタンを押下します。

Google側の確認が正常に行われると「所有権を証明しました」の画面が表示されます。「プロパティに移動」を押下します。

Search Console に登録されたばかりだと集計するデータがないので「データを処理しています。1日後にもう一度ご確認ください」となっていました。

翌日に確認すると表示がされていました。クリック数が0回です。。

新しいサイトのサイトマップも登録しておきます。管理画面の左側の項目からサイトマップを選びます。新しいサイトマップの追加のところに sitemap.txt を配置するURLを記載します。

サイトマップにはXML形式もありますが、遷移するページが少ない場合はTXT形式で記載したほうが楽だと思います。今回の新しいサイトは小規模ですのでTXT形式でサイトマップを作成しました。

TXT形式の場合のサイトマップ（sitemap.txt）は以下のような記載となります。

https://sub.example.com/sample01/memo.html
https://sub.example.com/sample01/file.html
　　：
（遷移するページのURLを記載していく）
　　：
https://sub.example.com/sample09/request.html
https://sub.example.com/sample09/image.html

なお sitemap.txt はサイトのトップページ（index.htmlと同じ場所）に配置しています。「送信」ボタンを押下すると Search Console がサイトマップを取得しに行きます。

「送信」ボタンの押下直後だとステータスが「取得できませんでした」となってしまいました。

ただその行をクリックして確認すると「サイトマップは正常に処理されました」となっています。検出されたページ数も sitemap.txt に記載したレコード数と一致していました。

しばらくしてからサイトマップを見直してみるとステータスが「成功しました」になっていました。

Search Console のもう一つの設定として robots. txt の設定があります。

robots. txt ですが、これは必ずしも設置が必要なものではないようです。

Googleのヘルプによると「robots.txt とは、クロールを禁止するサイトの URL やディレクトリを検索エンジンに伝えるテキストファイルの名前です　・・（中略）・・　小規模なサイトであれば、robots.txt ファイルはおそらく必要ありません。」とのことでした。

ですので今回は robots. txt の設置は割愛しています。

MySQLが必要以上にメモリを使い過ぎていたので対処してみた。

メモリ1Gの Amazon Linux 2023 を稼働させていたのですが、いつもほとんどメモリが残っていない状況でした。以下がそのときのfreeコマンドです。

$ free -m

availableが46Mしかありません。psコマンドを見てみたらMySQLがかなりのメモリを使っていることがわかりました。

$ ps aux

全メモリの半分近く（49.8%）をMySQLが使用していました。MySQLのバージョンは 8.4.0 です。データベースとしては数テーブルを使っているだけなので、MySQLの使用メモリ量を抑えたい。

とりあえず、MySQLの innodb_buffer_pool_size と innodb_log_file_size をそれぞれ確認してみました。

mysql> SELECT @@GLOBAL.INNODB_BUFFER_POOL_SIZE/1024/1024 as メモリサイズ（単位：MB）;

mysql> SELECT @@GLOBAL.INNODB_LOG_FILE_SIZE/1024/1024 as ログファイルサイズ（単位：MB）;

それほど大きくはなさそうです。他をネットで調べてみたところ table_definition_cache というものを下げれば良いらしいです。

mysql> show variables like 'table_definition_cache';

今の設定は2000になっていました。これを最小値の400にします。MySQLの設定ファイルである /etc/my.cnf を編集します。my.cnf ファイルに以下の1行を追記します。

table_definition_cache=400

MySQLを再起動させます。

# systemctl restart mysqld

table_definition_cache が変更されいてるか確認します。

400に変更されていました。空きメモリをfreeコマンドで確認すると空きができていました。ただMySQLは使用しているうちに使用メモリが増えていくようなので、肌感覚では多少は空いた程度の気がします。

もう少し使用メモリを下げられないか調べていると performance_schema というものをOFFにすれば良いらしいことがわかりました。現状はデフォルトでONのようです。

mysql> show variables like 'performance_schema';

performance_schema をONにしているとDBのパフォーマンスに関する統計情報を収集できるようですが、レコード数がそれほど多くない現状では不要と判断してOFFにすることにしました。my.cnf ファイルに以下の1行も追記します。

performance_schema=0

MySQLを再起動させて performance_schema の値を確認します。

performance_schema がOFFになりました。

table_definition_cache と performance_schema の値を変更してからしばらくMySQLを稼働させます。freeコマンドで確認するとメモリは以下で落ち着いてきているようです。

availableが234Mまで増えています。

psコマンドでもMySQLの使用メモリも確認しました。

全メモリの1/4（25.3%）まで下がりました。

感覚的には table_definition_cache を下げるより performance_schema をOFFにしたほうが効果があったような気がします。