まえがき

やめておいたほうがいい。まったく得しないしめんどくさい。

tl;dr;

起動時に USB コネクタが接続されていないエラーが表示される（Enter キーをおさないと進まない）
起動時に背面ファンエラーが表示される。（Enter キーをおさないと進まない）元の筐体にも背面ファンなんか無いのに
ロープロファイルからは開放されたが、電源ユニットが 240w なのでつらいはつらい。

モチベーション

Prodesk 600 SFF の筐体は、ロープロファイルの拡張カードしか刺さらなくて色々と面倒
ちょうど、PC ケースのあまりがあった。

入れ替えプラン

HP Prodesk 600 SFF 純正筐体 →Antec NSK 2480 (MicroATX までのケース）

電源の話

これが原因でケース載せ替えてもまったくうれしくない
電源供給周りが専用仕様で、交換が一切効かない。
電源ユニット → マザーの電源ピンは 6 ピンの信号線ぽいの（横一列）と、ATX12V（CPU 電源、これは普通の規格品）、PCI-e 6 ピン（グラボに指すやつ。あれがマザーに刺さる）で構成されているっぽい。

Amazon で普通の ATX 電源ケーブルからの変換もあるようだが試していない

特にこれは対応機器に普通に 600 SFF G2 が入っているので使えるだろうなぁ。という感じ。

試していないから何とも言えないけれども、写真と実物を見比べた限りではうまく行きそうに見える。電圧の変換を行うとかそういうことはしないだろうから、ピン配列さえあっていれば動く…はず。

2020/09/08 追記

(この変換ケーブル)[https://www.amazon.co.jp/dp/B07PNGTB2Y] で ATX 電源から変換してみたが、きっちり動いている。マザーボードから SATA の電源が取れるのはすごい便利。

マザーボードのピン配置

これが書きたかった

1
2
3

↑CPU
12n34
56789

1&2 1 側が+で、電源 LED
5&6 5 側が+で、HDD LED
7&8 電源ボタン
残りは不明

その他

CPU ファン

CPU ファンは、ネジ止め式だがネジの受けがケース側にある。しかし、サイズの合うナットを裏につけてしまえば問題なく止めることができる。

ダイソーで売っているボルト・ナット・ワッシャーセット M4~M6 の M4 のナットがぴったり合う。

CPU 側のスプリングを潰しながら（ようするにドライバーでネジを押し回し）すれば締めることができる。

CPU グリスはカピカピになっているので安物でもいいから塗り直したほうが良い。

ひとつだけ朗報なのは、プラスチックの風道パーツは、かぶさっているだけなので手で引っ張れば外れる。

そして中身はおそらく Intel 純正の CPU クーラー。ケースを替えても困らない。

マザーボード

サイズは普通に microATX のようだ。

ネジ穴の位置も、普通のマザーと変わらない。

ネジ

すべてのネジがちょっと妙なネジになっていて扱いづらいので、普通のネジに交換した。

スピーカー

元の筐体からもぎ取ればいいのだが、ネジがトルクスかなにかになっていて取れないので諦めた。

Mastodonの弱小インスタンスを運用するのに設定したこと

投稿日 2021-08-11 編集日 2025-10-06 カテゴリ tech

前提

環境

Ubuntu 18.04LTS
Mastodon （バージョン 2.4.3 でスタート。随時正式版に追従）

構成

すべて自宅サーバー上の Hyper-V 仮想マシン (Ryzen 7 1700, 32GB メモリ, Windows Server 2016)

Mastodon サーバー (3 コア, 4GB メモリ)
Ceph (2 コア 4GB, 1 コア 1.5GB * 2)

Ceph に関してはオーバースペック。ただの興味で動かしているだけです。以前は minio を使っていました。

将来的にクラウドに移行することを考慮して、最初から画像系は分離しています。

セットアップ回り

https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md

これに従っています。なので docker は使っていません。

監視回り

Raspberry Pi 上で動いている zabbix により監視しています。

現在の監視項目は以下の通り

ロードアベレージ
ディスク残量
Sidekiq ジョブ（https://github.com/ken-washikita/zbx-templates-mstdn)
Redis（https://github.com/ken-washikita/zbx-templates-mstdn)
postgres (https://share.zabbix.com/databases/db_postgresql/mamonsu-monitoring-agent-for-postgresql)

参考資料

大規模 Mastodon インスタンスを運用するコツ

https://speakerdeck.com/harukasan/inside-pawoo-mastodon-infrastructure

バージョンが古いけれどもやってることは基本一緒なはず。実体験でも Sidekiq が詰まってしまうと色々と障害を引き起こしたので

Sidekiq 重要。

設定変更内容

Sidekiq

default キューを処理するのがキモなようなので、default キュー専業のプロセスを作成。

元の全部のキューを処理するプロセスはそのままにすることで、忙しくなったら 2 プロセスで default キューを処理してくれることを

期待している。足りなければスレッドを増やせばよいだろうというくらいの気持ち。

全キュー対象のプロセスのスレッド数増加

# /etc/systemd/system/mastodon-sidekiq.service
# 変更点のみ
Environment="DB_POOL=7"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 10 -q default -q（略）

# ファイル作成後、以下を実行
systemctl restart mastodon-sidekiq

default キュー対象のプロセス新規追加

default キューが滞留すると重いに直結するので、default キューだけを処理するプロセスを立ち上げる。

これで、ダッシュボード上の表示は 2 プロセスになる。

# /etc/systemd/system/mastodon-sidekiq.service をコピーして mastodon-sidekiq-default.serviceを作成
# 変更点のみ
Environment="DB_POOL=5"
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 5 -q default

# ファイル作成後、以下を実行
systemctl start mastodon-sidekiq-default
systemctl enable mastodon-sidekiq-default

PostgreSQL のバッファ増量

2018/09/29 追記

https://pgtune.leopard.in.ua/ ここに”postgres が使用してよい”メモリ量を入れると、適切な config が生成されるので便利。

デフォルトだと 128MB になっているが、あまりに頼りないので増量。

メモリ自体は 2GB くらい空いているので増量しても問題ないと判断した。

1 2	# /etc/postgresql/10/main/postgresql.conf shared_buffers = 512MB # 元は128MB

ulimit 増加

Sidekiq のエラー部に、Too many open files が記録されていたので増量

`/etc/security/limits.conf
# 末尾に追加
      *    soft nofile 65536
      *    hard nofile 65536

備考

DB_POOL 5 => 7 処理スレッド数を増やしたので DB 接続がそれだけ必要になるだろうから増加
sidekiq スレッド数 5 => 10、CPU 負荷に余裕があったので倍増。スレッド数が足りずに Sidekiq のキューが伸びてレイテンシが上がってしまったタイミングがあったため（ダッシュボードで見れます）

事件記録

画像アップロード用サーバーの FW 設定ミスで接続蹴ってた事件

もうそのまんま。画像がアップロードできない状態になると、連合から飛んでくる画像も保存できずに Sidekiq のキューが伸びる。

結果、リモートフォローが失敗したり、プロフィール画像変更すると象が出てきたりした。

サイレンスと同時に画像もブロックしたら画像表示されなかった事件

連合の流れが速すぎるので上位 3 インスタンス(jp, nico, pawoo)をサイレンスにした際に、画像もブロックにしたら

該当インスタンスをフォローしている場合に画像が表示されなくなった問題。画像はブロックしないにして解決。

2018/09/29 追記 Sidekiq のメモリ使用量削減

Rails+Sidekiq 環境でメモリ使用量を減らす

https://qiita.com/imbsky/items/fca64e52f6e1d03504c9

↑（これ、mstdn.jp の運営引き継いだ会社の方ですね）

簡単に言えば jemalloc を使うことでメモリの無駄な領域を削減でき、驚くほどの効果がある。らしいです。 Sidekiq の作者が登場して、これ良いよって言っているのでそれほどの効果なんでしょう。

https://github.com/tootsuite/mastodon/issues/7257 (英語)

https://techracho.bpsinc.jp/hachi8833/2017_12_28/50109 （仕組み：日本語）

なお、docker だと jemalloc は適用できない。みたいなことが issue で語られています。

jemalloc の適用は下記がすごくわかりやすいです

https://qiita.com/kumasun/items/bf4997f181f893130041

2018/10/03 追記

https://qiita.com/motiakoron/items/b81a8f956ae4ea62ce11

こちらの Redis を UNIX ソケット経由接続に変更を適用しました。

少しでも負荷を削れるなら削りたいですよね。

前提

Hyper-V 上の VM
Ext4
debian 10
無停止

手順

parted を使用するので、入っていない場合は apt install parted でインストールする。

ディスク拡張

Hyper-V 上でディスクを拡張する。

VM に容量を認識してもらうため echo 1>/sys/class/block/sda/device/rescan を実行

※ sudo だと上手くいかない？ sudo su - して root だと上手くいった。

parted -l /dev/sda

warning: ~~~~ Fix/Ignore? -> Fix

Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 34.4GB <- 容量が増えたことを確認
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   fat32              boot, esp
 2      538MB   25.8GB  25.2GB  ext4

パーティションの拡張

parted /dev/sda

(parted) p

1
2
3

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   fat32              boot, esp
 2      538MB   25.8GB  25.2GB  ext4

(parted) resizepart 2

Warning: Partition /dev/sda2 is being used. Are you sure you want to continue?

Yes/No? yes

End? 25.8GB? -1

(parted) p

Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 34.4GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   fat32              boot, esp
 2      538MB   34.4GB  33.8GB  ext4   <= 拡張された

ファイルシステムの拡張

resize2fs /dev/sda2

resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 4
The filesystem on /dev/sda2 is now 8257036 (4k) blocks long.

前提条件

4K モニタ + フル HD モニタのデュアル
Linux Mint 20
Core i5 6500 / 24GB メモリ

tl;dr;

前提条件としてデュアルディスプレイするのであれば、グラボはメモリ 4GB 積んでるやつを選ぶべき。

GeForce だと 1050 とか 1650 とか。 AMD だと RX460, 560 あたり？

変更の経緯

そもそも、Skylake の内蔵 GPU は 4K+フル HD のデュアル出力が可能…だが
どうやっても、不具合が解消できなかった。フル HD ＋フル HD であれば全然問題ないのだが、
HiDPI を設定するとマウスカーソルがちらついてしまうのがどうしても解消できなかった。
仕方がないので、できるだけ安い、４ K 出力なグラボを探した結果、Quadro K620 を見つけた。
中指を立てられてしまう nvidia だけれども、プロプライエタリドライバは Jetson Nano で割とよく動くというのは
経験していた。のと、本当は AMD 系がほしかったけれどもお高かった。今なら RX シリーズがマイニング用とかで
お安くでているのでそれを買うと良いかもしれない。
話を元に戻すと、Quadro は普通に動いた。チラツキとも無縁だし、Youtube も普通に見れる。
が、雀魂（麻雀はよくわからないけれども、3D の HTML5 ゲームとしてベンチマークにつかってる）を動かすともう見事なコマ送り。なるほど Linux デスクトップのパフォーマンスってこんなもんか…

ブラウザが GPU アクセラレーション使えてないっぽいし、そんなもんよね。と愚痴っていたのです。

（間違ってます。そんなもんじゃないです）

ある日、ふと、nvidia-smiコマンドを打ってみると、VRAM の使用量が割と最大値に近い値になっていた。

(1800MiB/1900MiB みたいな値）

これはもしかして、VRAM 足りてない…？と思い、うちで 4K 出力が可能なまともなグラボの GeForce 1060(6GB)を

ゲーム用 PC からもってきた（HP のケースから交換した甲斐があった。なお、電源も交換している）グラボを交換して初起動。nvidia プロプライエタリドライバを使っているので特に問題なく起動、HiDPI の設定をしてブラウザを触っていると、なんか軽い。もうこの時点でちょっと違うかもしれないという感じがする。

試しに雀魂を起動してみる。もうアニメーションが全然違う。ログイン画面のさくらの花びらがちゃんと動いている。

今まではこの時点でカクカク、グラフィック処理が間に合わなくてタイムアウトになるくらいだったのが全く問題ない。

プレイしてみても快適だった。なんてこった。もう一枚のモニタで YouTube 動画を再生しても余裕。 nvidia-smiしてみると…

`|===============================+======================+======================|
|   0  GeForce GTX 106...  Off  | 00000000:01:00.0  On |                  N/A |
|  0%   51C    P0    29W / 120W |   2988MiB /  6044MiB |     16%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A       897      G   /usr/lib/xorg/Xorg               1385MiB |
|    0   N/A  N/A      2109      G   cinnamon                          122MiB |
|    0   N/A  N/A      2951      G   ...o/bin/firefox/firefox-bin      625MiB |
|    0   N/A  N/A      3627      G   ...AAAAAAAAA= --shared-files       71MiB |
|    0   N/A  N/A     84089    C+G   ...AAAAAAAAA= --shared-files      461MiB |
|    0   N/A  N/A     87428      G   ...AAAAAAAAA= --shared-files      247MiB |
|    0   N/A  N/A    363160      G   ...o/bin/firefox/firefox-bin        1MiB |
|    0   N/A  N/A    428987      G   ...o/bin/firefox/firefox-bin       65MiB |
+-----------------------------------------------------------------------------+

もう既に 2988MiB も使っている。そりゃあメモリ 2GB の Quadro じゃ重くなるわ…

（同じ構成で Windows なら問題なく動くと思われる）

Linux デスクトップは快適に動くけれども、富豪的なところがあるのでパワーある構成にする必要があるという学びを得た。

Elasticsearchが1ノードでConditionがYellowな時の直し方

投稿日 2021-08-11 編集日 2025-10-06 カテゴリ tech

環境

Elasticsearch 6.4 (Basic ライセンス)
Elasticsearch 7.12 でも確認

状態

とりあえずインストールを行い、ほぼデフォルト値で運用してある程度のインデックスが溜まった状態。

ネタ元は metricbeat や filebeat。Condition 　 Yellow と表示はされるが、問題なく動作している。（ようだ）

ではどうするか

やるべきことは 2 つある。

1: 既存のインデックスのレプリカ数を 0 に変更する。

2: 新しく作られるインデックスのレプリカ数を 0 に設定する。

実行前の注意点

これらの操作を行うと、elasticsearch の負荷が一時的に上がります。

しかも、そのまま Condition が Red になってしまい、しばらく検索クエリを受け付けない状態にすらなりました。

メモリ量がそれなりに必要なようで、ログをみると GC を連発してほぼ、処理が進まない状態になりました。（1.5GB 割り当て）

そのため、メモリ量を増加（2GB）したところ素直に終わりました。インデックス量はおよそ 50GB でした。

大事な環境で実行する際は、テンプレート名を * ではなく、ある程度絞ってテスト実行することをおすすめします。

＃例えば、 metricbeat-*-2018.10.2* のように

既存のインデックスのレプリカ数を 0 に変更する。

すべてのインデックスのレプリカ数を変更してよいのであれば、以下のコマンドで設定できる。

1 2	$ curl -H "Content-Type: application/json" -XPUT localhost:9200/*/_settings -d '{"number_of_replicas":0}' {"acknowledged":true}

新しく作られるインデックスのレプリカ数を 0 に設定する。

新しく作られるインデックスは、 template_1 というテンプレートから作られるようなのでその設定を変更する。

$ curl  -H "Content-Type: application/json" -XPUT localhost:9200/_template/template_1 -d '
{
    "template" : "*",
    "settings" : {
        "number_of_shards" : 1, "number_of_replicas" : 0
    }
}'
{"acknowledged":true}

確認（インデックス一覧取得）

curl "http://localhost:9200/_cat/indices?v"

1 2	health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open .geoip_databases F80oZbJcR2KE7BQwlL6XPQ 1 0 45 0 42.5mb 42.5mb

参考にした記事

はじめての Elasticsearch クラスタ

https://www.slideshare.net/snuffkin/elasticsearch-107454226

シャード、レプリカの概念
割り当てられていないレプリカ、シャードがあると Condition = Yellow になるということ
デフォルトのレプリカ数は 1 なので必ず複数ノードにデータがなければならない
レプリカ数は、インデックスごとに設定される。

[Elasticsearch]Cluster Health の status が yellow となる

https://qiita.com/toshihirock/items/38649fc7310436b2a580

curl http://localhost:9200/（インデックス名）/_settings?pretty でインデックスごとの設定が取得できる。

出典失念

次のバージョンの Elasticsearch ではレプリカ数のデフォルト値は 0 になる
elasticsearch をスモールスタートしてはいけないということはないので、ノード 1 台でも OK

SQL ServerのINSERTスクリプトをどうにかしてPostgreSQLに投入するメモ

投稿日 2021-08-11 編集日 2025-10-06 カテゴリ tech

要件

SQL Server から PostgreSQL に移行するために、SQL Server Management Studio でスクリプト化した SQL をどうにかして PostgreSQL に流したい。

前提

テーブル定義は手動で変換して、既にテーブル自体は作成済みの状態
Windows 上の SSMS で出力した SQL ファイルを Linux ホストに持ってきた上で実行

変換

結論から行くと、以下のコマンドを使用した。

各行の意図は後述

# コピペしても動かないです。1行にまとめてください。

nkf -Lu dbo.example.Table.sql
| tail -n +5
| head -n 3      # この行はテスト用！
| sed -e 's/$/;/'
| sed -e 's/\[dbo\]\.//'
| sed -e 's/\[//g' -e 's/\]//g'
| sed -e 's/DateTime/Timestamp/g'
| sed -e 's/^GO//g'
| sed -e 's/^INSERT/INSERT INTO/g'
| head -n -1
> sql.sql

後半の sed -e を連打しているところは、ひとつの sed -e 's/hoge/fuga/ -e ‘s/bar/baz/‘` の形にまとめることが出来ます。まとめた方が恐らく早いですが説明しにくくなるのであえてわけてあります。

各行の意図

nkf

改行コードの変換。出力元が Windows なので改行コードが CRLF になっているので LF に。

改行コードが違うと sed がまともに動かなかったりしてつらいです。

1 2	`nkf -g dbo.example.table.sql UTF-16

なのにも関わらず、処理後に ASCII になっているのは問題になるのか悩ましい。

tail

先頭の SQL Server 用の指示をスキップさせている。

head

テスト用なので本番では外す。 tail -n 10 にしてもよいが、ファイルを全部読んでしまうので遅くなる。

sed (1)

INSERT 文の末尾に ; がついていないので付ける

sed (2)

テーブル名が、 [dbo].[example] となっているので、[dbo]. を削除

sed (3)

前段の置換で、テーブル名が、 [example] となっているので、[] を削除

sed (4)

SQL Server の DateTime 型は PostgreSQL では Timestamp 型にマップすることにしたので置換。

CAST(N’2017-01-01T12:34:56.789’ As Timestamp) は PostgreSQL でもそのまま通る。

sed (5)

GO は不要なので削除。空行が残りますが問題ありません。

sed (6)

SQL Server では INSERT テーブル名 が通るが、PostgreSQL では INSERT INTO テーブル名 なので INTO を補う

head

末尾に SET IDENTIFY example OFF; という行が含まれるのでそこを削除。

リダイレクト

説明不要だけど、ファイルに吐かせる

蛇足

作成した SQL ファイルは、 psql 内で \i ファイル名 とすることで実行できる。

なお、トランザクションが設定されてないので、自動 commit されることに注意。

失敗したら TRUNCATE TABLE でテーブルをクリアしてから実行していたので、特にそのあたりはケアしていません。

件数が多い場合は、\i sqlfile.sql を実行する前に begin transaction しておいた方が早いかもしれません。

※ 多分、INSERT 一回ごとに COMMIT が暗黙でかかるはずなので

その場合、進捗が分からないとつらいので、GO を commit; begin transaction; に置換すると良いかもしれません。

（100 行に 1 度挟まれています。）

あと、件数の確認は確実に行ってください。それほど多くのパターンでテストしていないので行が欠けているかもしれません。（特に、先頭・末尾）

Windows Server 2019 のファイル共有が遅かった件

投稿日 2021-08-11 編集日 2025-10-06 カテゴリ tech

2019/01/10 追記

解決しました。 NIC との相性なのかなんなのかわかりませんが、NIC を Intel の

ものに変更したら治りました。

前書き

本件、未解決です。内容も全然ありません。

環境

Ryzen 1700X / ASRock X370 Fatality Gaming K4
Windows Server 2019 Standard Edition
NIC を増設（Broadcom の 2 ポート NIC）
Adaptec 6805T
Hyper-V ロール

現象

ファイル共有にアクセスした際、ものすごく遅い。Windows10 の表示だと 300kb/s くらいしかでない。

しかし、VM 上の Ubuntu でホストしている Samba 共有にアクセスすると通常の速度（100MB/s)が出る。

調べたこと

https://social.technet.microsoft.com/Forums/windowsserver/en-US/02593d94-1cea-4318-a2ff-aaa8a2eafd83/server-2019network-problems-hyperv-role-is-suspected

Hyper-V ロールが入っていなければ問題ない？という書込。

色々なサービスを動かしてしまっているので Hyper-V を止められないので未テスト。

試したモノ

Offload 類をオフ　 → 変化なし
USB-NIC を追加して、そちら経由でアクセス → 変化なし

→Broadcom の NIC が 2012R2 の頃にバグってる的な記事があったので NIC を変えてテストしたかった

→ 管理 OS と共有していない NIC なら Hyper-V の影響はあまりないだろうと考えた

結局

ファイル共有を全て Ubuntu に任せる事に。うーん。

蛇足

Windows、割とバージョンアップごとにファイル共有がおかしくなってるような気がする。。

kubernetesのdocker -> containerd 切り替え

投稿日 2021-08-11 編集日 2025-10-06 カテゴリ tech

まえがき

環境

kubernetes 1.20.1
worker も master も同じ手順で切り替え可能。

備考

用語の定義

master = コントロールプレーン
worker = ワーカー

手順

worker / master 共通

2021/09/09 追記
この作業を行うと、そのノードに割り当てられていたPodは終了されるが、それについてkubeletは感知できない。何が言いたいかというと、kubectl drain node をしてから作業したほうがいいですよ。（１敗）
やらかしてしまったら、Terminating で止まっているPodを一つずつkillしていくと復帰してきます。

docker 削除

docker を削除して containerd を入れる（docker をつかっているなら containerd はインストール済みなので、apt install で手動インストールフラグを建てておく）

1 2	apt install contained apt purge docker

containerdのconfigを生成する

2021/09/18 この手順が抜けていました。これを行わないとcontainerdは起動しません
生成されたconfig.tomlは特に修正する必要はありません。

1 2	$ sudo mkdir -p /etc/containerd $ sudo containerd config default > /etc/containerd/config.toml

/var/lib/kubelet/kubeadm-flags.env

KUBELET_KUBEADM_ARGS に追記

1	--container-runtime remote --container-runtime-endpoint unix:///run/containerd/containerd.sock

これを機に “–cgroup-driver” とかのdeprecatedなパラメタが含まれていたら削除しても良いかもしれません。

kubeletを再起動

この際なのでホスト毎再起動しても良いが、 systemctl restart kubelet でもOK

以下はmasterのみ

master で kubeadm の作業をする場合のみ

root で作業する。

共通の手順を行えば、とりあえず kubernetes クラスタは普通に稼働する。

しかし、バージョンアップ時など、kubeadm を使用しようとすると

1	[ERROR ImagePull]: failed to pull image k8s.gcr.io/kube-proxy:v1.21.0: output: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

このようなエラーが出てしまう。とりあえずの対処をしたがこれで正しいのかはちょっとわからない。

criSocket を指定する yaml を作る

これは、 kubeadm config print init-defaults の中から必要な行だけを切り出して作成した。

apiVersion: kubeadm.k8s.io/v1beta1
kind: InitConfiguration
nodeRegistration:
  criSocket: /run/containerd/containerd.sock

ファイル名とファイルの場所はどこでも OK。

yaml のバージョン変換

作った yaml を使用すると、それはバージョンが古いという警告がでるので変換しておく

kubeadm config migrate --old-config /etc/kubernetes/kubeadm-crisocket.yaml --new-config new.yaml

実際のコマンドを入力

kubeadm upgrade apply v1.21.0 --config=new.yaml

メモ

kubeadm はクラスタの configmap に情報を記録していて、それを読んでどうこうしているらしい。

取得の仕方は以下。

kubectl -n kube-system get cm kubeadm-config -o yaml

蛇足

master を切り替えるとデータどうなるんだろうと不安だったけれども特に問題はなさそう。
kubeadm --cri-socket=/run/containerd/containerd.sock upgrade apply v1.21.0 が通ればなんの問題もなかったのだが、upgrade コマンドは cri-socket オプションが通らないように 1.17 から変更されている。

SQL中の謎の =* という演算子について(SQLServer 2000)

投稿日 2021-08-11 編集日 2025-10-06 カテゴリ tech

既存の SQLServer 2000 を使用しているシステムの SQL に謎の SQL があった
適当にサンプルを上げるとこんな感じ。

select a.col1 , b.col2
from a , b
where
 a.col1 *= b.col2

WHERE 条件の *=とか、=*とかなんだこれ？と思ってググってみたけれどもヒットしない。

列名から JOIN 絡みの何かだろうと当たりをつけて試してみた結果

1 2	= → LEFT JOIN = → RIGHT JOIN

だった。なんか黒歴史みたいなものに触れてしまった感じだ。

ちなみに、これは最近の SQLServer では使用できず、エラー扱いになる模様。

追記

ちなみに、Oracle にも同様の記法がある。コメント欄で教えて頂いた通り、

LEFT JOIN/RIGHT JOIN が制定される前の名残だろうか。

select a.col1 , b.col2
from a , b
where
 a.col1 (+)= b.col2

1 2	where a.col1 = b.col2 (+)

JOIN したい方に(+) を付けるだけ。今でも使えますが、標準 SQL で書いた方が無難。

kubernetes障害記録：podにはできるだけrequestsに使用するメモリ量を書いた方が良い

投稿日 2021-08-11 編集日 2025-10-06 カテゴリ tech

tl;dr;

pod に requests を書いた方がいい。特にメモリ量。
さもないと、Out Of Memory(OOM)が発生してエライことになる可能性がある。

事故事例

requests が書かれていない状態で起きた。

requests がないのでメモリが逼迫したノードに新しいコンテナが配置された
OOM が発生してワーカーノードがマスターノードと疎通できなくなった
OOM でプロセスがkillされたが回復出来ずワーカーノードが応答不能状態に
ワーカーノードがダウンしたと判断され、他のノードに pod が移動を始めた
他のノードもメモリ量がそれほどあるわけではないので OOM 発生
ギリギリだったノードにさらに割り振られて OOM 発生
ワーカーノード全滅

requests に書くメモリ量が分からない

とりあえず稼働させてみて、その pod が動作している pod に SSH でログインし、
docker stats [containerID] を実行することで使用中のメモリ量がわかる。

記述例

Deployments、ReplicaSet、DaemonSet、StatefulSet 等の conteiners の定義に書くことができる。
requests はスケジューリングに使用されるが、制限はされない参考情報なので多すぎる分には問題だが
少なくても問題は起きない（OOM が起きる可能性はあるが）のでちょっと多いくらいの数値が良いと思われる。

※ 未確認ですが、リソースがどのノードでも不足する場合は、pod が作成されずに Pending されるそうです。

containers:
  - name: db
    image: postgres:11
    resources:
      requests:
        cpu: 1000m         # CPU使用量の見込み
        memory: "500M"     # メモリ使用量の見込み
      limits:
        cpu: 2000m         # CPU使用量の上限
        memory: "700M"     # メモリ使用量の上限