ここ最近受けたインタビュー記事・寄稿記事について

この2〜3ヶ月でインタビューを受けて記事にしてもらったり、久しぶりに外部メディアに寄稿したりしたので、そのログを残しておく。

Findy Engineer Lab

Findy Engineer Labさんへの寄稿記事。
最近、こうした外部メディアに寄稿することは滅多にしなくなってしまったのですが、ありがたいことに昔はよく機会をいただき、技術的な内容の記事をよく寄稿させていただいていた。
(過去の寄稿記事についてはプロフィールページなどに -> https://profile.hatena.ne.jp/rx7/ )

で、今回は自分のキャリアの話を書いていただきたいとリクエストをいただいたので、改めてこれまでのキャリアを振り返り、何を考えてどう行動したかを愚直に書かせてもらった。

こんなリクエストが来るなんて随分歳をとってしまったのだなという気持ちになったのと、振り返ってみて、改めて色々やってきて色々考えながら進んできたのだな、と。

こうして、自分のやってきたことの棚卸しも大事だけど、気持ちや感情面も振り返ることができて、改めてよいきっかけを頂いたなと思いました。機会を頂戴できたこと感謝いたします。

テクフリ

こちらはPR記事的な感じですが、会社でお世話になっている人材紹介会社様からのインタビュー記事。

QA形式の雑談的な感じの会話をした、くらいのイメージなんですが、いい感じのインタビュー記事にしていただけて、とても楽でしたw こちらもありがたし。

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

子供用のみまもりに "GPS BoT" から "あんしんウォッチャー" に乗り換え

子供用のみまもりに Bsize社の "GPS BoT" を2年半ほど使っています（いました）。

↓のエントリでも記載していますが、GPS BoT は、子供が1人で出かけたりする時に持たせておくことで、現在位置を特定するGPS発信機的なもの。スマホアプリなどで子供が今どこにいるかを（設定により1〜3分程度のラグはありますが）確認できます。

今使っている GPS BoT のデバイス自体は、現モデルからは1世代前のもので、2年半ほど使ってみて大きなトラブルもないのですが、改善したいなぁと思うのはバッテリーのもちがイマイチという部分。

購入当初から、頻度優先（最短1〜2分間隔で更新）設定で、1度充電するとバッテリーは約3日もち、2年半使うと少しへたってきて、フル充電から2日強のもち、といったところ。

買い増しの必要性により、デバイス・サービスの再検討

で、この4月から下の子が小学校に入学するということで、妻と話し合い、GPS BoTを買い増しするか、という話になりました。

GPS BoTも新モデルであれば、バッテリーの持ちは最長1ヶ月（平日は3時間移動、土日は利用なし想定で、の計算らしい）とのことで、ペインも解決されている。

んじゃ、下の子用にもう1台買うかー、何だったら、バッテリーが改善されているので、上の子の分も含めて2台買うかなー、となったのですが、、、良いきっかけなので他社製品・サービスも見ることにしました。

あんしんウォッチャー by au (KDDI)

タイトルにも書いていますが、結論から書くと、"あんしんウォッチャー" という製品に買い換えることにしました。

決め手は、

• 2台運用時のランニングコストが安い
• バッテリーのもちが良さそう（GPS BoTの第2世代相当クラス）
• GPS BoT と機能性は大きく変わらない

あたりです。

コスト

1つ目のコストですが、"GPS BoT"は、デバイス本体が2022/04時点で1台あたり税込5,280円、月額528円。つまり2台だとその倍のコストが必要です。
それに比べ、"あんしんウォッチャー"はデバイス本体が2022/04時点で1台あたり税込11,000円で、これには12ヶ月分の月額費用が込みとなっています。で、13ヶ月目以降は月額539円が必要なのですが、この月額費用はデバイスではなく au ID に紐づくものなので、デバイスは最大2台までこの月額539円で利用できるとのこと。

お申し込みから最大12カ月間、月額不要で本商品代金以外はかかりません※。13カ月目以降は、au HOME基本利用料月額539円がかかります。 ひとつのau HOME契約に対し最大２台のあんしんウォッチャーを登録、利用可能です（2台目は追加の月額料金はかかりません）。

https://amzn.to/3s4z3iC

つまり長く使えば、あんしんウォッチャーの方がお得。ただし、短い期間（3ヶ月など）で辞めたくなった場合のことを考えると、GPS BoTの方が低リスク、といった感じでしょうか。

我が家のように2台のデバイスで運用する場合、期間別のトータル費用感を以下表にしておきます。

利用期間	GPS BoT費用	あんしんウォッチャー費用
(初期費用)	10,560円	22,000円
3ヶ月	13,728円	22,000円
6ヶ月	16,896円	22,000円
1年	23,232円	22,000円
2年	35,904円	28,468円
3年	48,576円	34,936円

こんな感じで、利用開始から11ヶ月目くらいで損益分岐点がある感じ。

我が家では、すでに上の子が2年半使っていて、使い勝手もわかっているし、よほどサービスレベルがひどい等でない限り、買って早々に利用を止めることはなさそうだったので、あんしんウォッチャーで良さそうだな、と。

これは、ちなみに情報なのですが、私はこのあんしんウォッチャーをAmazonの2月のセールで購入したのですが、1台あたり7,980円で購入できました。
タイミングによっては、初期費用は抑えられるかと思います。（これはGPS BoTも同様の話です。）

KDDI あんしんウォッチャー GPS 1年間月額不要 大切な家族やモノの居場所をスマホでみまもり docomo、ソフトバンク、au、MVNOのスマホも利用可能 UHA01A

Amazonのレビューを見て、気になるレベル感のものが少なかったのも、参考にしています。

バッテリー

あんしんウォッチャーの公式サイトの記載によると GPS BoT 第2世代と同等のもち（平日は3時間移動、土日は利用なし想定）の記載があったので、想定は同等といったところです。

ちなみにですが、我が家の子たちが、約1ヶ月運用した感じだと、更新間隔90秒（測位優先）の平日メインの利用（学校と習い事）で、およそ20日程度、充電なしで連続利用できました。このくらいバッテリーがもってくれると十分な感じです。

機能性

あくまで GPS BoT の機能と比較して、の話ですが、大きくはほとんど変わらず、1つ挙げるとするなら、GPS BoTは子供がよく行動する範囲を勝手に学習してくれて、その行動範囲から外れるとスマホに通知がくる、という機能があったのですが、あんしんウォッチャーでは、似たような機能はあるものの「よく行動する範囲」を手で定義（特定地点から半径何キロ圏内）する必要があり、勝手に学習してくれる感じではなかったです。

他の機能については、

• 複数のスマホ（私と妻の両方）で子供たちの位置情報が共有できること
• 登録した特定の場所に到着したり離れたりするとスマホに通知がくる
• 行動履歴（1週間分）が記録される

あたりのメイン機能については、同レベルの機能提供がされており、問題なく使えています。

あと、ほんのわずかながら気になった機能差異は、通知が必要な場所（地点）の登録を、GPS BoTは各スマホのアプリで登録する必要があった（各スマホごとに独立して登録できる）のですが、あんしんウォッチャーでは地点の登録も各スマホで共有することができました。
これを便利と捉えるか不便と捉えるかは、使い方によりますが。（我が家では私と妻は同じ目線でモニタリングしているので便利だった。）

デバイスの物理比較

両公式サイトのスペック表を見てもらったらわかるのですが、サイズはほとんど同じで変わりません。重量はわずかながらあんしんウォッチャーの方が重いかなぁ、という感じですが、53g と 46g の違いなのでこちらも誤差です。

おわりに

GPS BoT の解約はアプリ（サイト）経由で、Webから行えますが、即時解約できました。解約申し込みしたタイミングから利用できなくなります。
そして、使い終わったデバイスは再利用できないのでご注意を。

ちなみに、他にも検討したサービスはmixiの "みてねみまもりGPS" なのですが、正直、コスト以外の大きな差異が見つけられなかったのと、使い勝手は、数ヶ月使ってみないとわからないこともあり、最後はえいやで決めた感じですね。

・・・こんな感じで、まだ使い始めてから1ヶ月経ったくらいのところなのですが、今のところ、あんしんウォッチャーも大きな問題なく使えています。

また気になったことがあれば追記しまーす。
それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

KDDI あんしんウォッチャー GPS 1年間月額不要 大切な家族やモノの居場所をスマホでみまもり docomo、ソフトバンク、au、MVNOのスマホも利用可能 UHA01A

Linuxで仮想コンソールを切り替える chvt コマンド

備忘録。

自宅にある物理サーバ (Linux) をメンテナンスする際、モニターとキーボードを接続させてオペレーションすることがたまにあるのですが、CUIメインな環境なので、仮想コンソールを使い分けたりしています。

んで、大抵は仮想コンソールを切り替える際に、キーボードで Ctrl + Alt + (F1 〜 F6) を入力して切り替えていくと思うのですが、今日、特定の仮想コンソールがキーボードを押しても何故か反応せず (切り替えられず)、アレっとなったので、仮想コンソールを移動させるコマンドの存在を思い出して、コマンド名をググって久しぶりに使ったという話。

・・・というだけの話ですが、そのコマンドは chvt コマンド。rootユーザで実行、もしくはsudoで実行する必要があります。
tty2 に接続する場合は、

# chvt 2

みたいな感じで実行します。

CHange foreground Virtual Terminal で chvt です。滅多に使わないので絶対に忘れる。

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

本気で学ぶ Linux実践入門　サーバ運用のための業務レベル管理術

CentOS 8 で "Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist"

メモ書き。

自宅で CentOS 8 が動いているサーバがあるのですが、先日 dnf コマンドが使えなくなってしまい、あ、そういえば CentOS 8 って、昨年末で EOL を迎えてしまっていたのかーー、と気づいた次第。

ちなみに↑の時にインストールしたやつ。

さて、、、

# dnf update
CentOS Linux 8 - AppStream                                                                                       24  B/s |  38  B     00:01
エラー: repo 'appstream' のメタデータのダウンロードに失敗しました : Cannot prepare internal mirrorlist: No URLs in mirrorlist

dnf コマンドを実行するとこんな感じ。英語だと、以下のような感じか。

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

そういえば、↑のエントリの通り CentOS 6 の時も一時的に同じように対応したのですが、リポジトリリストのURLを vault.centos.org (過去バージョンも含めて、パッケージが公開されている) へ向けることにします。

# sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
# sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-Linux-*

この2つのコマンドを実行してリポジトリを書き換え。

# dnf clean all
47 ファイルが削除されました
# dnf update
CentOS Linux 8 - AppStream                                                                                      421 kB/s | 8.4 MB     00:20
CentOS Linux 8 - BaseOS                                                                                         566 kB/s | 4.6 MB     00:08
CentOS Linux 8 - Extras                                                                                         3.2 kB/s |  10 kB     00:03
依存関係が解決しました。

こんな感じで、きちんとメタデータをダウンロードできるようになった。

さて、この CentOS 8 も EOL を迎えているので、次は Rocky Linux とかが良いのだろうか。

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

参考リンク

VCDSを使ったコーディング入門 (VW/Audi向け) - 4. MMI ナビを Wi-Fi クライアントとして動作させ無線APに接続する

VCDS を使ったコーディングを行なったので、自分へのメモがてら使い方のログを残しておきますシリーズ。前回の続きです。

これまでやってきたことは以下な感じ。

• VCDSを使ったコーディング入門 (VW/Audi向け) - 1. 準備・設定編
• VCDSを使ったコーディング入門 (VW/Audi向け) - 2. デイタイムランニングライト (DRL) 編
• VCDSを使ったコーディング入門 (VW/Audi向け) - 3. オートライトの感度調整

さて、最近の Audi の MMI (ナビゲーションシステム) が搭載されているモデルには、SIMカードによるモバイル通信 (LTE) が可能になっていて、新車から最初の3年は無償 (Softbank の SIM カード が付属) で利用することができます。

初回の車検のタイミングで、この無償利用の権利が切れるので、必要であれば更新 (有償) する感じになるのですが、すごく利用頻度が高いわけでもないので、私は更新しませんでした。

モバイル通信できなくなる = Audi Connect が利用できなくなることで、ニュースや天気情報が取得できなくなったり、Google Earth が使えなくなった点は特に問題ないのですが、オンライン検索を利用して目的地設定したり、スマホの myAudi アプリから事前に設定した目的地が同期できなくなった点は不便を感じるようになりました。

で、MMI には無線APの機能がついていて、Wi-Fi のホットスポットとなれる機能があるのですが、それならば、Wi-Fi クライアントとして動作することができれば、自宅の Wi-Fi やスマホのテザリングで使えるようになるのではないか？と考えました。

そこで、色々調べたところ、同じようなことに取り組まれている方がいました！インターネットの世界は広い。
ので、今日はそれをやってみた、という話です。

毎回記載していますが、くれぐれもコーディングは自己責任でお願い致します。

尚、VCDSって何？とか、基本設定はどうするの？的な話は、1回目のエントリをご覧くださいませ。

VCDS で 5F-Information Electr. コントロールモジュールへアクセス

1回目のエントリで記載したような基本的な設定は済ませてある前提で、具体的なやり方を記載していきます。

まずはお馴染みのトップ画面で、"Select" をクリック。

次に、"5F-Information Electr." をクリック。

次に、"Adaptation - 10" をクリックです。

ちなみに、、、↑の画面で "Security Access - 16" が存在しますが、今回のケースでは入れなくても大丈夫のようでした。

もし上手く書き換わらない等、必要だったら入力するようにしましょう。ちなみに、5F の "security access key" は "20103" でした。

Wi-Fi Client 機能を有効にする

本エントリーの最初に書いた通り、Wi-Fi クライアントとしても使えるよう機能を有効化します。

IDE03471-ENG137648-Vehicle configuration-WiFi_Client_HMI

Channel から上記を選択します。
デフォルトの値は "OFF" となっているかと思うので、New Value で "On" を選択し、"Do It!" をクリックします。

これで、コーディング自体は完了です。

MMI 側でネットワークの設定を行う

次に、MMI 側で設定を行なっていきます。

まずは、メニューから "設定" を選択。

"接続マネージャー" を選択。

データ接続の部分は、SIMカードとなっていますが、 右側 "+" でオプションを開きます。

"オンライン" 設定を選択。

オンライン設定から "接続状況" を選択すると、SIMカードの契約切れになっている場合は、こんな感じで何も表示されていない感じかと。

というわけで、SIMカードでの通信機能をOFFにします。
"データモジュールオフ" を選択。

"オフにする" を選択。

改めて、データ接続のオプションに戻って、、、"Wi-Fi設定" を選択して、、、

Wi-Fi で "オン" を選択するのですが、、、あれ？ネットワークの設定項目が出てきません。。。
はて、なぜだろう？となりましたが、結論から言うと、MMI の再起動が必要だったみたいです。

Audi RS3 で MMI ナビゲーションシステムの再起動は、↑の画像の赤丸の3点を、3秒以上同時押しして離すことで、強制的に再起動されます。

再起動後、無事に設定項目が出てきました！ "ネットワークの検索" を選択。

Wi-Fi 接続したい SSID を選択します。

接続したい SSID のパスワードを入力します。入力後、"OK" を選択。

Wi-Fi に接続されたら、↑のようなダイアログが表示されるので、"OK" を選択。

接続マネージャーのデータ接続の部分に Wi-Fi の SSID が表示されていたら接続されているみたいです。

ちなみになんですが、私の環境では、この状態で Audi Connect のサービスを使うことはできませんでした・・・。他の方の情報を読む限り、Audi Connect の一部サービスは使えないものの、天気の情報やオンライン検索はできているようでしたので、何か条件があるのかもしれません。

↑では、データ接続の行の文字がグレーとなっているので、何かがうまくいってないのかもしれません。
(うまく一部のサービスが使えている方も、ここの文字はグレーになっていたので、よくわかりませんが。)

ちなみに、Wi-Fi への接続は、ネットワーク的には問題なく成功しているようでして、自宅の無線APの設定を見ても、DHCPでIPアドレスが払い出されているのと、↑の画像で Wi-Fi プレーヤーの項目に nasne と見えると思うのですが、自宅内のNASへ接続できていて、そこに保存されているファイル等は問題なく表示されていました。

ということで、Wi-Fi クライアントとして、自宅やスマホ (テザリング) への Wi-Fi 接続はできたのですが、そもそもの目的であった、一部の Audi Connect の機能が利用したい、という目的は達成できずで消化不良です。

Audi Connect 側の問題というか、何か設定やライセンスが足りていないのかもしれません。
(MMI にて確認できるライセンスも確認してみたのですが、2120年まで有効、みたいになっていたので、そっちは問題ないと思っているのですが、、、そもそもネットワーク接続できていなかったので更新されていないだけ？・・・よくわかりません。)

ちょっと消化不良気味ではあるので、次回は別のコーディングで、MVNO等の一般的な SIM カードの利用を試してみたいと思います。

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

追記

続きを書きました。

Amazon EC2 (AWS) のインスタンスファミリーを t2 → t3 に移行した

Amazon EC2 (AWS) で動かしていた t2 インスタンスを、今更ながらですが、t3 インスタンスへ移行したので、そのメモ書き。

t3 インスタンスに変更すると、CPUクレジットの扱いが少し変わりますが、コストパフォーマンスはよくなるケースが多いはず。
t2 から t3 へ移行したブログエントリーは探すといくつか見つかるが、日本語での欲しい情報にたどりつけなかったこともあり、その辺もこのエントリにメモしておくことにする。

はじめに: このエントリーを書こうと思ったきっかけ

事前に作成されていたAMIから都度 t2 インスタンスを起動して使用するようなユースケースが前提としてあり、その保存済みのAMIからは、t3 インスタンスが起動できない状態でした。

インスタンスタイプの選択画面はこんな感じ。

で、この保存済みの AMI の設定をなんとか変更して、t3 インスタンスタイプに対応できないか、と色々調べたのですが、結論としては、AMI を再作成しないといけない模様。多分。

ので、やったことはシンプルに AMI からインスタンスを起動し、t3 でも起動可能な設定を行い、AMIを再作成するという流れで行いました。

ということで、以下の公式ドキュメントを参考に作業したので、こちらを見てもらう方が確実かもしれない。

確認していくべきこと

t3 インスタンスで動かすためには、ENA (Elastic Net Adapter) を有効化する必要があります。

お使いのインスタンスで ENA サポートが有効かどうかは、

• カーネルモジュール (ena) が有効になっているか
• "enaSupport" 属性が設定されているか

を確認する必要があります。

次の AMI には必要な ENA モジュールが含まれており、ENA のサポートが有効になっています。

• Amazon Linux 2
• Amazon Linux AMI 2018.03
• Ubuntu 14.04 (linux-awsカーネル) 以降
• Red Hat Enterprise Linux 7.4 以降
• SUSE Linux Enterprise Server 12 SP2 以降
• CentOS 7.4.1708 以降
• FreeBSD 11.1 以降
• Debian GNU/Linux 9 以降

Linux/ インスタンスにおける Elastic Network Adapter (ENA) を使用した拡張ネットワーキングの有効化 - Amazon Elastic Compute Cloud

実際の確認ログ

既存の AMI から EC2 インスタンスを起動して、 ena モジュールが有効化されているかを確認します。

# modinfo ena
filename:       /lib/modules/4.9.76-3.78.amzn1.x86_64/kernel/drivers/amazon/net/ena/ena.ko
version:        1.4.0U
license:        GPL
description:    Elastic Network Adapter (ENA)
author:         Amazon.com, Inc. or its affiliates
srcversion:     963AA763EBF4D86DF9EF826
alias:          pci:v00001D0Fd0000EC21sv*sd*bc*sc*i*
alias:          pci:v00001D0Fd0000EC20sv*sd*bc*sc*i*
alias:          pci:v00001D0Fd00001EC2sv*sd*bc*sc*i*
alias:          pci:v00001D0Fd00000EC2sv*sd*bc*sc*i*
depends:
intree:         Y
vermagic:       4.9.76-3.78.amzn1.x86_64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

modinfo コマンドで確認。有効化されていますね。
もし有効化されていない場合、Amazon Linux の最新バージョン等では、ENA がインストールされた拡張ネットワーキングに必要なモジュールが含まれているとのことなので、 "sudo yum update" などで最新に更新してみましょう。
(OSのアップデートについては、OSによって手順が異なりますが、その説明はここでは割愛します。)

次、ネットワークインターフェースでドライバーがロードされているかを確認します。

# ethtool -i eth0
driver: vif
version:
firmware-version:
bus-info: vif-0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

ふむ。ena ではなく vif モジュールがロードされています。

ということで次、インスタンスに enaSupport 属性が設定されているかどうかを確認します。
動かしているインスタンスIDを調べた上で、AWS CLIの以下コマンドを実行してみます。

$ aws ec2 describe-instances --instance-ids i-xxxxxxxx --output json | jq '.Reservations[].Instances[].EnaSupport'
null

値がつまっていないので設定されていないですね。
ということで、次に拡張ネットワーキングの設定を行います。

拡張ネットワーキング (enaSupport 属性) の設定

こちらも AWS CLI の以下コマンドで実行。

$ aws ec2 modify-instance-attribute --instance-id i-xxxxxxxx --ena-support

An error occurred (IncorrectInstanceState) when calling the ModifyInstanceAttribute operation: The instance 'i-xxxxxxxx' is not in the 'stopped' state.

エラーが返ってきました。
インスタンスが稼働したままでは設定変更ができないようなので、インスタンスを停止してから、再実行します。

$ aws ec2 modify-instance-attribute --instance-id i-xxxxxxxx --ena-support

エラーが返ってきていないので、今度は問題なさそうです。(ちゃんと終了コード見るべきかw)

$ aws ec2 describe-instances --instance-ids i-xxxxxxxx --output json | jq '.Reservations[].Instances[].EnaSupport'
true

上記のように確認のコマンドを実行したところ、問題なく "true" が返ってきています。これで有効化された、と。

この状態で、AMI を再作成しておけば、ENAが有効化された AMI となります。
(ということで AMI を作成した。)

t3 インスタンスを起動して確認

さて、EC2 インスタンスを起動する際の AMI の選択画面を見ると、先ほど作成した AMI は、以下のような感じで、"ENA 有効" の項目が "はい" になっていることが確認できます。

ENA が有効なAMIを作成すると、以下のように t3 ファミリーのインスタンスを選択して起動することができます。

で、t3 インスタンスは問題なく起動したので、実際に起動したインスタンスで、ネットワークインターフェースのドライバーに ena があたっているかを確認してみると、、、

# ethtool -i eth0
driver: ena
version: 1.4.0U
firmware-version:
bus-info: 0000:00:05.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

OK、変更されていますね。

手順はざっくりこんな感じでしたー。
それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

---

まとめ

• Amazon EC2/S3を使ってみた - まとめ (Amazon Web Services関連エントリ目次)

MySQL で使用するメモリサイズの見積もり

最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。

結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。
このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。

MySQLトラブルシューティング

著者について
Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQLのバグ修正とサポートを担当する。

発売は2012年と少し古い本で、本書によると対象としているMySQLのバージョンは5.5の模様。なので、少し古い記述ではあると思う。

尚、MySQL 5.7 や 8.0 については、以下の公式ドキュメントに近しい内容がかかれている（と思う）。

• MySQL :: MySQL 5.7 Reference Manual :: 8.12.4.1 How MySQL Uses Memory
• MySQL :: MySQL 8.0 Reference Manual :: 8.12.3.1 How MySQL Uses Memory

メモリ使用量のざっくり計算式

メモリ使用量 = グローバルバッファの使用量 + max_connections * スレッドバッファの使用量

上記に加えて、OSのメモリ使用量等を加えたものが、サーバの物理メモリ量を超えないように調整する必要があります。

グローバルバッファ

このオプションはグローバルで、すべての接続とクエリに影響。
サーバの起動時に割り当てられるものもあれば、使用しながら増えていくオプション (クエリキャッシュなど) もある。

• query_cache_size
• innodb_additional_mem_pool_size
• innodb_buffer_pool_size
• innodb_log_buffer_size
• key_buffer_size

(参考) グローバルで省略できるパラメータ

サーバには、ファイル記述子の数を制限するオプションとキャッシュされるスレッドの数を制限するオプションもあるが、モダンなシステムでは無視できるほど小さいので、省略できるとのこと。以下がそのリスト。

• thread_cache_size
• table_definition_cache
• table_open_cache
• innodb_open_files

スレッドバッファ

基本的にスレッドごとに割り当てられるバッファ

• net_buffer_length
• thread_stack
• query_prealloc_size
• binlog_cache_size
• binlog_stmt_cache_size

特定処理に割り当てられるバッファ

これらのバッファは、サーバが特定の処理を実行しなければいけない時に、必要に応じて割り当てられる。
割り当てられるメモリ量を正確に計算するのは難しく、クエリを分析して、どれが大量のリソースを要求しているかを調べて、以下のような計算を行う。

(バッファサイズ) * (特定のクエリに割り当てられたバッファ数) * (並列して実行されるクエリの数)

これを全ての変数で実行し、結果の合計を計算する。

これらのオプションは、ほとんどのクエリで小さな量に抑えておくのが良い。もし、特定のクエリでより多くのメモリが必要な場合は、その変数の値をセッションごとに増やすのが良い。(ものによってはグローバルに設定しても意味がないので、クエリを実行する直前に設定する。)

スレッドごとに1回割り当てられるオプション

• read_rnd_buffer_size
• sort_buffer_size
• myisam_mmap_size
• myisam_sort_buffer_size
• bulk_insert_buffer_size
• preload_buffer_size

スレッドごとに複数回割り当てられるオプション

• join_buffer_size
• read_buffer_size
• tmp_table_size

MySQL が消費するメモリの最大量を計算する公式 (MB表記)

Set @join_tables = 1スレッドあたりでJOINされるテーブル数の見積;
Set @scan_tables = 1スレッドあたりのテーブルスキャン数の見積;
Set @tmp_tables = 1スレッドあたりで作成される一時テーブル数の見積;

SELECT(@@query_cache_size + @@innodb_additional_mem_pool_size + 
@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size + 
@@max_connections * (@@global.net_buffer_length + @@thread_stack + 
@@global.query_prealloc_size + @@global.read_rnd_buffer_size + 
@@global.sort_buffer_size + @@myisam_mmap_size + 
@@global.myisam_sort_buffer_size + @@global.bulk_insert_buffer_size + 
@@global.preload_buffer_size + @@binlog_cache_size + 
@@binlog_stmt_cache_size + @@global.join_buffer_size * IFNULL(@join_tables, 1) + 
@@global.read_buffer_size * IFNULL(@scan_tables, 1)+
@@global.tmp_table_size * IFNULL(@tmp_tables, 1)))/ (1024*1024);

(参考) MySQLの各オプションの設定値を確認する例

mysql> SHOW GLOBAL VARIABLES LIKE '%buffer%';

(追記) 集まったご意見

yokuさんとか、nippondanjiさんとか、僕からするとMySQL神クラスの方が、フィードバックをくれてありがたい。集合知。

最近のはこれに（グローバルバッファとして）performance_schemaのテーブル分が載ってくるのでお気をつけください！

— yoku0825 (@yoku0825) June 21, 2021

mallocに依存してる都合上、libc内部にも結構メモリがたまってしまうってのも注意が必要。個人的にはベンチマークして欲しいし、最初は控えめにバッファを割り当てて、様子を見て余裕があるなら割り当てを増やす運用がオススメ。

— Mikiya Okuno (@nippondanji) June 21, 2021

参考にさせていただいた書籍・リンク

MySQLトラブルシューティング

実践ハイパフォーマンスMySQL 第3版

DELL U4021QW (40インチ5K2Kワイドモニター) を発注した

以下エントリの続き。

ドッキングステーションを検討していたものの、↑のエントリでも触れていた通り、決め手に欠く状態だったので、それならばとタイトルにも記載したドッキングステーションも兼ねられる高級モニター (DELL U4021QW) を買うことにした。

決して安い買い物ではないので、本当はもうちょっとレビュー記事が出てきてから・・・と思っていたのだけど、全く使えないということはないだろうし、ほぼフルリモートワークで毎日使う機材でもあるので、勢いで買うことにした。
期末のおかげか、15%割引クーポンもついていたので。

なかなかいい値段しますねー・・・。
(ちなみに楽天リーベイツ経由で購入して、3.5%ポイントバックでした)

今の34インチワイドモニターよりも、もう二回りくらい広い作業環境が欲しいと思っていたので、到着が楽しみです。あと、インターフェースが盛り沢山なので、狙い通りにデスクの配線がすっきりすると嬉しい。(MacBook Pro からケーブル1本のみでの接続)

他、49インチのウルトラワイドも魅力的だったのですが、縦方向の解像度も上げたかったのと、このモニターの他に、4Kモニターと38インチのWQHD+も悩んだのですが、後で後悔するのが嫌だったので、一番ベストなものを選択した感じです。（その代わり、高価...）

さて、この商品、ずっと品切れ状態が続いていて、発注したのは2日程前なのですが、気になる納期は 5/23 とのこと。1ヶ月半待ちってところですね。
追記：4/14に到着しました！注文してから9日で到着。

あと考えなくてはいけないのが、今メインで使っている34インチモニターをどうするかということ。
モニターアームを使って横に据えるか、もしくは縦に据えるか。縦というか上になるのですが、さすがに上は見ないかなー。首が痛くなりそうw
というか、5K2Kがあれば、もう追加のディスプレイは不要な気もしているので、別の用途に回すか、ですかね。

その辺を、今月は検討してみようと思います。
それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

Dell 曲面モニター 39.7インチ U4021QW(3年間無輝点交換保証/sRGB 100%,Rec.709 100%,DCI-P3 98%/フレームレス/USB-C/LANポート(RJ45)/WUHD/5K2K/IPS非光沢/Thunderbolt™ 3,DP,HDMIx2/高さ調節/スピーカー付)

MacBook Pro の配線をスッキリさせるために、ドッキングステーション or 多インターフェースなディスプレイを検討

言いたいことを全部タイトルに書いてしまいましたが、そういうことです。
尚、結論は出ていませんw 下記エントリの続きですね。

普段使いの MacBook Pro は USB-C (Thunderbolt 3) の4ポートを使い切っており、どうも配線的には美しくない。
このご時世で、昔ほどPCを持って移動する機会はかなり少なくなってきてはいますが、移動の時に、線を4本とも取り外すのが煩わしい。せっかくなので1本にまとめてしまいたい。

そんなところで、ドッキングステーションを検討しはじめました。

要件というか希望としては、、、

• MacBook Pro には、USB-C (Thunderbolt 3) のケーブル1本だけで接続できるようにしたい。
  • Thunderbolt 3 に対応したインターフェースが理想。
• PD給電できるもの。16インチユーザなので、100W(85〜87W)対応の製品が良い。
• 複数のディスプレイを接続したいのと、DisplayPortへの対応。
• 有線LANで接続したいので、RJ-45のコネクタ付き。
• USB-A 3.0以降への対応。(これは大体の製品で満たせている)

こんな感じ。

これらを満たすような製品を探すと、以下あたりが候補になってくる。

ドッキングステーション

CalDigit TS3 Plus/Thunderbolt Station 3 Plus/Thunderbolt 3 ドッキングステーション（スペースグレイ・0.7mケーブル付き）

ドッキングステーションでは、個人的には最有力候補。
AmazonのレビューやTLの評判を見ていても、これが一番良さそうな雰囲気。DisplayPortのバージョンが1.2であるため、少し古さは否めない気がするが、安定感がありそうなので、安心できそう。

一部、レビューの中では、スリープの復帰で難がある報告があったりして、個体の問題なのか接続元(PC)か接続先(ディスプレイ)との相性問題があるのかもしれない。

あと、筐体は夏場などではそれなりに熱くなる模様。

一応、Apple Store で Mac のアクセサリとして公式に販売されているので、それなりに信頼して良さそうという感じ。

Belkin ドッキングステーション ハブ USB-C Thunderbolt3 Macbook Pro 2020 / Air iPad Pro / M1 iPad Pro / M1 iMac 5Kディスプレイ対応 0.8mケーブル付 F4U097JA-A

Belkin の製品なので、勝手ながら Mac と相性は良いのかなと想像している。

が、Amazonのレビューを見ていると、スリープからの復帰で、うまくモニターに表示されないケース、有線LAN(イーサネット)がうまく通信できないケースがいくつか報告されているのが気になる。

そして、この製品もとにかく熱を持つとのこと。

Anker PowerExpand Elite 13-in-1 Thunderbolt 3 Dock ドッキングステーション 85W出力 USB Power Delivery 対応 USB-Cデータ & 充電ポート USB-Aポート 4K対応 HDMIポート 1Gbps イーサネット 3.5mmオーディオジャック microSD＆SDカード スロット搭載

Anker の比較的新しめの製品。こちらも一部スリープからの復帰時に表示されないケースの報告があるが、そもそもレビューの母数が少ないのでよくわからない。

評判は良さそうなので、少々人柱感はあるが試してみても良さそう。
他製品と変わらず、熱を持つのとアダプタが大きいのは変わらなそう。

HP Thunderbolt Dock 120W G2

追記：Twitter で HP のこの Dock も良いのでは、と教えていただきました。
確かに要件を満たしていて良さそうです。スリープからの復旧時に、稀にUSBを認識しないこともあるそう・・・。HPのオンラインストアでは日常的に約60%OFFのキャンペーン価格で売られているので、こっちから買うのがオススメっぽい。

TIPS

尚、Twitter TLやFBコメント、Amazonのレビュー情報を眺めていて、ドッキングステーションの有線LANに何かしらの不具合が生じているケースにおいては、ドッキングステーションの有線LANアダプタでは、Realtekのチップが使われているケースが多いようで、MacOSとの相性問題なのかはわかりませんが、このイーサネットコントローラーのドライバをインストールすれば解決した、という情報が複数ありました。

• https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software

多インターフェースなディスプレイ、という選択肢

ドッキングステーションは、どれも決め手にかけるなぁと思い始めてきたので、思い切ってリッチなモニターを選択肢に入れてみようと思い始めました。

最近、色々なインターフェースがついていて、ドック代わりに使えるディスプレイが各社から発売されています。

かなりお高いんですが、今一番良いなぁと思っているのは最近発売になった以下の製品。

Dell U4021QW 39.7インチ 曲面 大型モニター (3年間無輝点交換保証/WUHD/IPS非光沢,5K2K/Thunderbolt™ 3,DP,HDMIx2/高さ,傾き調整/sRGB 100%,Rec.709 100%,DCI-P3 98%/LANポート(RJ45)/スピーカー付)

40インチ(正確には39.7インチ)の曲面 5K (5120x2160) ディスプレイです。

Thunderbolt 3 に対応、PD給電可能、LANポート有り、と私が↑で書いた要件は全て満たしています。ディスプレイから Thunderbolt 3 の一本で接続すれば全て終わる感じ。超シンプルで良さそうです。

今、DELL公式から消えてしまっていて、それなりに売れていそうですが、問題は20万円近くするところ・・・。

Dell U3821DW 37.52インチ 曲面 モニター (3年間無輝点交換保証/WQHD+/IPS非光沢,2300R曲面/DP,HDMIx2/高さ,傾き調整/sRGB 100%,Rec.709 100%,DCI-P3 95%/LANポート(RJ45)/スピーカー付)

少しグレードを落とすと、上記の38インチ (正確には37.5インチ) の曲面ディスプレイ (3840x1600) も有りかなと思っていますが、こちらは Thunderbolt 3 には対応していません。
ですが、1ディスプレイに接続するだけならこれでも十分です。ドッキングステーションとしての機能は果たせているかと。

・・・と、こんな感じで悩んでいます。
数年使用することを考えると悪くない投資なので、5Kディスプレイを買ってしまいそうですが、今、品薄になっているので、DELL公式サイトで供給が安定してきて、他の方のレビューを見てから決めようかなと考えています。

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

追記：続き

Error: Fetching /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core failed!

メモ書き。
環境は、macOS 10.15.7、Homebrew 3.0.5。

$ brew update
Error: Fetching /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core failed!

上記のように update を走らせたら、こういったエラーが出た。
なぜフェッチできなかったのか、それを出力してくれないとわからない・・・。

$ brew doctor

とりあえず困ったので doctor を実行した (何かヒントや修復されたような出力は無かった) 後、update を行うと、いつも通り、何事も無かったかのように実行できた。

はて、なんだったのだろう・・・。

何かわかれば追記します。
それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́