こぼれネット

🔷 まとめ

✅ 「どちらか分からないなら、Docker Volume を使うのが安心！」

ボリュームを使っていれば確実にバックアップされるし、もしコンテナの中にデータがあっても問題なく移行できるので、安全な方法！ 🎯

docker images をやったのですが、同じ名前のdocker imagesが出てくるのですが、どれが最新なのか見分ける方法を教えて下さい。

↓

同じ名前のdocker imagesが出てくるのですが、どれが最新なのか見分ける方法を教えて下さい。

↓

CREATED も同じく"2months"になっていて見分けがつきません。 ですので、例えば、Dockerコンテナを動かして確認する方法はありませんか。現在、私は "docker-compose start" をした後にシェルでDocker内部に入っているのですが、この状況からの確認方法を教えて下さい

Dockerの外側（ホストOS）から稼働中のDockerコンテナを確認するには、いくつかの方法があります。以下は、その代表的な方法です。

1. docker ps コマンドで稼働中のコンテナを確認

ホストOS上で、現在稼働中のコンテナを一覧表示するために、以下のコマンドを使用します。

1. イメージを保存する
まず、docker save コマンドを使用してイメージをファイルに保存します。以下のコマンドを実行してください。

$ docker save -o u2404b-dev-environment.tar u2404b-dev-environment

このコマンドは、u2404b-dev-environment という名前のイメージを u2404b-dev-environment.tar というファイルに保存します。

2. 保存されたファイルを確認する
保存が完了したら、ファイルが正しく作成されたか確認します。

$ ls -lh u2404b-dev-environment.tar

このコマンドで、保存されたファイルが存在し、適切なサイズであることを確認できます。

あとは、zip等で固めて、先方に送付すればO.K.

-----

保存したイメージを他の環境でロードするには、どうしたら良いですか。

もし他の環境に移動してこのイメージを使用したい場合、docker load コマンドを使用してイメージをロードします。

ファイルを解凍して、

$ docker load -i u2404b-dev-environment.tar

これにより、保存されたイメージが再びDockerにインポートされ、使用可能になります。

ところが、この方法では、自力で設定した環境などが全く引き継がれないらしいです。

送付いただいたものはgstreamer、コンパイル環境が入っていない状態でした。
お手数ですが、コンテナをcommitしてsaveしたものを送付願います。
(参考:https://sagantaf.hatenablog.com/entry/2018/09/04/190801)

上記の参考資料の通りにやってみることにしました。

(Step.1) まず、ゲストOSを立ち上げておいて、ホストOSから以下のコマンドを投入します
cam@cam-desktop:~$ sudo docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c928a6ab4e6b u2404b-dev-environment "/bin/bash" 4 days ago Up 3 hours u2404b-dev-environment-1

(Step.2) 次に、このc928a6ab4e6bを使って、20240828_shajyoという名前(名前は好きなように)でコミットします

cam@cam-desktop:~$ sudo docker commit c928a6ab4e6b 20240828_shajyo
sha256:ac3405c474d294e5b5d0bd9a8cdc51a600f8cd3d04685877cecfb772e284b17e

# コミットしている最中、ゲストOSにアクセスできなくなるようですが、恐れず、じっと我慢しましょう。

(Step.3) コミットに成功しているかを確認します

cam@cam-desktop:~$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
20240828_shajyo latest ac3405c474d2 4 minutes ago 2.5GB  ← できている
u2404b-dev-environment latest 48248de5e524 2 months ago 1.23GB
<none> <none> dcb4a05fb5a5 2 months ago 1.23GB
<none> <none> 132165fbb602 2 months ago 986MB
u2404_dev-environment latest 940f87bcbccf 2 months ago 986MB
<none> <none> a4252fdea034 2 months ago 988MB
u2404-dev-environment latest a042684decc4 2 months ago 971MB
ubuntu 24.04 ffb64c9b7e8b 2 months ago 101MB
hello-world latest ee301c921b8a 16 months ago 9.14kB

(Step.3) 20240828_shajyoをセーブします

cam@cam-desktop:~$ docker save 20240828_shajyo -o 20240828_shajyo.tar

あとは、これをzip等で圧縮して、先方にお送りすれば良いです。

cam@cam-desktop:~$zip 20240828_shajyo.tar.zip 20240828_shajyo.tar

-----

これを展開するのは、多分、以下のようになると思います(というのは、私が試していないからです)

(Step. 1) 一旦、ホストOSからイメージを削除する
$ docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
20240101_shajyo          latest              3c053ce8d919        25 minutes ago      193MB

$ docker rmi 20240101_shajyo

(Step. 2) ホストOSから、ファイルからイメージを作成する

$ sudo docker load < 20240828_shajyo.tar

これでイメージが復活する(ハズ)とのことです。

ご対応ありがとうございました。
コンパイル環境と各プログラムがイメージに入っていることを確認しました。

というコメントをいただいたので、多分大丈夫です。

=======

今回イメージを受けとる側になりましたので、イメージの作成方法を追記します。

cam@cam-desktop:~/u2404b$ docker-compose start
service "dev-environment" has no container to start
と言われてしまいました。

解決手順

1. 現在のコンテナ状況を確認

まず、docker-compose.ymlのディレクトリに行きます。

現在のコンテナ状況を確認するため、以下のコマンドを実行します：

出力が空の場合、まだコンテナが作成されていないことを意味します。

2. コンテナを作成・起動

$ sudo docker load < 20241016_shajyo_latest.tar
でつくったもので
20241016_shajyo latest bf4a5d825daa 13 months ago 3.15GB
となっています。

もし 20241016_shajyo:latest を docker-compose.yml 内で使用する予定がある場合、以下の手順を考慮してください。

version: '3'

services:
  dev-environment:
    image: 20241016_shajyo:latest  # ロード済みのイメージを使用
    environment:
      DISPLAY: ${DISPLAY}
      XDG_RUNTIME_DIR: /tmp/xdg
    volumes:
      - /tmp/.X11-unix:/tmp/.X11-unix
      - /home/cam/u2404:/home/cam/u2404
    stdin_open: true
    tty: true
    network_mode: host

docker-compose up コマンドで、コンテナを作成して起動します：

• --build は、新しいビルドが必要な場合に使用します。
• -d は、デタッチモード（バックグラウンドで実行）を有効にします。

このコマンドで新しいコンテナが作成され、サービスが開始されます。

ところが、これでもDockerで作ったデータベース本体丸ごとでの移行はしないみたいです(ちょっと待った。現在これ検証中)。

結論：docker commit ではデータは移行されない可能性が高い！
データベースごと移行するなら docker volume をバックアップするか、pg_dump を使うべき

データベース本体と丸ごと持っていきたい場合は(も、あてにならないので、現在検証中)

DockerのPostgreSQLデータベースをWindows→WSLのDockerへ移行する方法

11日の休日は、

On the 11th, my holiday,

(1)午前中に、Docker Desktopからコンテナをエクスポートして、別のマシンのWindowsのWSLにDocker環境を構築してインポートし、

(1) in the morning, I was going to export a container from Docker Desktop, build a Docker environment on Windows WSL on another machine, and import it,

(2)午後からは日本語のドラフトを英文カンファレンスペーパーにする

(2) in the afternoon, I was going to turn a Japanese draft into an English conference paper

つもりでした。

スマートに、エレガントに、コーヒーカップを片手にしながら。

Smartly and elegantly while holding a cup of coffee in my hand.

なのに、なんでどうしてこうなる？

But why did it turn out like this?

―― 翌日の深夜午前4時まで、連続18時間格闘し続けて、上記『午前中』の処理が、まだ完了していない(継続中)

I continued to fight for 18 hours straight until 4 am the next day, and the above 'morning' process is still incomplete (still ongoing).

複数のマシンにばらまいていたDockerのデータベースの中身がスカスカで、バックアップのほぼ全部が「ザル」であったことが分かり、心底青さめています。

I was disappointed to find that the contents of the Docker database, which had been spread across multiple machines, were very sparse and that almost all of the backups were “sieve-like.”

今やれることは、何でもやっている、という感じです。

I feel like I am doing everything I can right now.

イントラネットの実験用のマシンとして使うために、Windowsのセキュリティを全解除したいです(pingとか、ポートオープンとか面倒くさい）。設定方法を教えてください。

バックアップが不安な状態が続く状態が怖くて、1秒も早くこの作業を完了したいのですが、定例と出張で、そんな時間取れません。

I'm scared that the uncertainty about the backup will continue, and I want to complete this task as soon as possible, but I can't find the time to do it with my regular work and business trips.

なんか体調も悪くなってきました(喉が痛い)。

I'm starting to feel unwell (my throat hurts).

こんな気持ちと体調のまま、週末に突入するのか、と考えるだけで、死ぬほど憂鬱(ゆううつ)です。

Just thinking about entering the weekend with these feelings and physical condition is enough to make me feel depressed to the point of death.

だれか、私に「大丈夫だよ。なんとかなるよ」と、耳元でささやいて欲しい。

I want someone to whisper in my ear, “It's okay. You'll manage somehow.”

嘘でもいいから。

Even if it's a lie.

Windowsのセキュリティを全解除する方法を説明します。ただし、これはセキュリティリスクが極めて高いため、イントラネット内での実験用に限定し、外部ネットワークに接続しないことを強く推奨します。

1. Windows Defender ファイアウォールを完全無効化

方法1: コマンドで無効化

管理者権限のPowerShellを開いて、以下のコマンドを実行してください。

これで、全ネットワークプロファイルのファイアウォールを無効化します。

とりあえず、ここまででいいかな。

方法2: GUIで無効化

1. ファイアウォールとネットワーク保護 を開く
2. ドメイン ネットワーク、プライベート ネットワーク、パブリック ネットワーク の3つ全てを「オフ」にする

2. Windows Defenderのリアルタイム保護を無効化

管理者権限のPowerShellで以下を実行：

GUIで行う場合：

1. Windows セキュリティ → ウイルスと脅威の防止
2. ウイルスと脅威の防止の設定 → リアルタイム保護 をオフにする

3. Windows SmartScreenを無効化

管理者権限のPowerShellで以下を実行：

GUIで行う場合：

1. Windows セキュリティ → アプリとブラウザーコントロール
2. SmartScreen の全項目をオフにする

4. UAC（ユーザーアカウント制御）を無効化

レジストリを変更することで完全無効化できます。

変更後、再起動が必要です。

5. Pingを許可

ICMP（ping）を許可するには、以下のコマンドを実行：

6. すべてのポートを開放

方法1: 特定のポートをすべて開放

以下のコマンドで全ポートを開放：

方法2: ファイアウォールを完全無効化

上記の**「1. ファイアウォールを無効化」**を実施すれば全ポート開放されます。

7. Windows Updateの無効化

Windows Updateを完全に無効化したい場合：

8. 共有フォルダの制限解除

管理者権限のPowerShellで、SMBの制限を解除：

さらに、ファイル共有を完全開放するには以下を実行：

"C:\Shared" を共有フォルダとして、全ユーザーにフルアクセスを付与します。

9. リモートデスクトップを有効化

RDPを有効にするには、以下のコマンドを実行：

10. 自動ログインの設定

特定のユーザーで自動ログインしたい場合、以下のレジストリ設定を変更：

注意点

• 外部ネットワークには絶対に接続しないこと
• 一度無効化したら、戻すのも手間がかかるため慎重に
• Windows Updateを止めると脆弱性が残るので要注意

イントラネット環境での実験用なら問題ありませんが、セキュリティリスクを理解した上で行ってください。

DockerのPostgreSQLデータベースをWindows→WSLのDockerへ移行する方法

Windows上のDockerで動作するPostgreSQLデータベースを、WSL（Windows Subsystem for Linux）のDockerに移行する 手順を説明します。

🔷 方法 1: Dockerボリュームごと移行する（推奨）

Windowsでは grep や busybox は不要 で、標準的な PowerShellコマンド を使用して移行できます。

📌 ① ボリューム名を確認

まず、PostgreSQLのデータが保存されているボリューム名を確認します。

出力例：

この hakata_db-data がPostgreSQLのデータが格納されているボリュームです。

📌 ② ボリュームをtarファイルにバックアップ

PowerShellを管理者権限で開き、以下のコマンドを実行します。

重要なポイント

• C:\Users\tomoi\backup はWindows側のバックアップ保存先（任意のフォルダを指定）
• ubuntu イメージを使用（busybox は不要）
• hakata_db_backup.tar.gz という圧縮ファイルが作成される

この hakata_db_backup.tar.gz をUSBやネットワーク経由で 移行先のマシンへコピー します。

📌 ③ WSLのDocker環境にファイルをコピー

WSLのファイルシステムにバックアップを移動します。

WSL内で以下のコマンドを実行して、WindowsのバックアップファイルをWSLの /home/ ディレクトリにコピー。

📌 ④ WSLのDockerでボリュームを作成

WSL内で以下を実行し、新しいボリュームを作成します。

作成したボリュームにデータを展開します。

📌 ⑤ WSLのDockerでPostgreSQLコンテナを起動

WSL内で以下を実行し、データをマウントしたPostgreSQLコンテナを起動。

📌 ⑥ データが正しく復元されたか確認

PostgreSQLコンテナに接続してデータを確認。

データベース一覧を表示：

音声を無視して、最も一般的な webm → mp4 変換コマンドは以下のようになります。

説明：

• -i input.webm：入力ファイルの指定
• -vf "scale=640:360"：解像度を640x360に変更
• -r 5：フレームレートを5fpsに変更
• -c:v libx264：H.264コーデックでエンコード
• -preset slow：エンコード速度と圧縮率のバランスをとる（品質優先）
• -crf 23：品質を指定（数値が低いほど高品質）
• -an：音声を削除（無音にする）
• output.mp4：出力ファイルの指定

このコマンドで、音声なしの mp4 に変換できます。

技術の世界は、

The world of technology is a strange world where

(1)先頭を走らなければ負け

(1) if you don't run at the front, you lose

と

and

(2)先頭を走ったら負け

(2) if you do run at the front, you lose

が併存する、不思議な世界です。

coexist.

-----

まず「(1)先頭を走らなければ負け」というのは、新技術に対して大胆に挑戦し続けなければ、技術で生きている会社は生き残れない、という現実があります。

Firstly, “(1) If you don't run at the front, you lose” is a reality that companies that survive on technology cannot survive unless they continue to take on new technology boldly.

スマートフォン市場におけるAppleの事例がわかりやすいと思います。

I think the example of Apple in the smartphone market is easy to understand.

Appleは2007年にiPhoneを発表し、スマートフォン市場の覇権を握りました。

Apple announced the iPhone in 2007 and took control of the smartphone market.

それまでの携帯電話市場はNokiaやBlackBerryが支配していましたが、タッチスクリーンを中心とした新しいUIを導入し、アプリストアというエコシステムを作ったことで、新たな市場を開拓し、技術革新をリードすることで市場を支配するチャンスを得ました。

Until then, Nokia and BlackBerry had dominated the mobile phone market. However, by introducing a new UI centered around touch screens and creating an app store ecosystem, they were able to develop a new market and seize the opportunity to dominate it by leading technological innovation.

技術の進化が激しい分野では、先行しなければ市場において埋もれてしまうのです。

In fields where technology is evolving rapidly, we will be left behind in the market if we don't keep up.

例えば、日本の家電メーカーは液晶テレビやスマートフォン市場でかつて強かったが、新しい技術トレンドに適応できず、海外メーカーに市場を奪わるに至っています。

For example, Japanese home appliance manufacturers used to be strong in the LCD TV and smartphone markets. However, they have not adapted to new technological trends, and overseas manufacturers have dominated the market.

-----

次に「(2)先頭を走ったら負け」というのは、新技術を業界デファクトスタンダードにできなければ、結局、後発技術の方に足並みをそろえなければならなくなって、先行投資のお金をドブに捨てることになる、という現実です。

Next, “(2) If you run at the front, you lose” refers to the reality that if a new technology can't become the industry standard, you'll have to adopt the latecomer's technology, which will result in throwing away the money you invested in advance.

Google Glassの失敗が挙げられるかと思います。

I think the failure of Google Glass can be cited.

Googleはウェアラブルデバイスの未来を見据えて、2013年にGoogle Glassを発表しましたが、市場はまだその技術を受け入れる準備ができておらず、プライバシーの問題などもあって普及しませんでした。

Google announced Google Glass in 2013 with an eye to the future of wearable devices. Still, the market was not yet ready to accept the technology, and it did not become popular due to privacy concerns.

結果として、Googleはこのプロジェクトを一旦終了し、後発のARグラスやVR市場に歩調を合わせる形として継続しています。

As a result, Google has ended this project for the time being and is continuing it in a way that keeps pace with the later AR glasses and VR markets.

日本人にとって最も有名なケースは、ソニーのベータマックスです。

The most famous case that Japanese people know of is Sony's Betamax.

ベータマックスは、VHSよりも技術的に優れていましたが、業界の標準を獲得できなかったため、結果的に市場で敗北しました。

Betamax was technically superior to VHS but failed to gain industry-standard status and was ultimately defeated in the market.

このケースは、技術的に先行していても、業界全体の流れを作ることができなければ、競争に勝てないことを、日本のエンジニアに骨の髄まで思い知らせた超有名な事例です。

This famous case made Japanese engineers realize to the bone marrow that even if we are technically ahead and cannot create a trend for the whole industry, we will not be able to win the competition.

-----

昨日も記載しましたが、私は、PostgreSQL + PostGISを使い倒しています(日本一のヘビユーザではないか、と自負しています)。

As I mentioned yesterday, I use PostgreSQL + PostGIS to the full (I'm proud to say that I'm probably the biggest PostGIS user in Japan).

これなら「プログラムを一切変更せずに」金の力だけで解決できます！

高速のデータベースがあれば、飛び付きたい気持ちがありますが、ここに、「(1)先頭を走らなければ負け」と「(2)先頭を走ったら負け」の現実が立ち塞がります。

If there were a high-speed database, I would be tempted to jump at the chance, but here is the reality of (1) “If you don't run at the front, you lose” and (2) “If you run at the front, you lose” stands in the way.

どんなに良いデータベースであったとしても、それを他の人に使いこなして貰えないのであれば、それを組み込んだ私の作ったシミュレータは死蔵し、そして、私の死後に完全に消滅します。

No matter how good the database is, if other people can't use it, the simulator I made incorporating it will gather dust and completely disappear after my death.

まあ、それはそれで良いのですが ―― 開発現場の人間の一人としては、世界中の人が使っているデータベースは、問題が発見しやすく、トラブル対応が早くすむ、という利点は見逃せません。

Well, that's O.K., but as someone working in development, I can't ignore the advantages of a database that is used by people all over the world, such as the fact that it makes it easier to find problems and respond to issues quickly.

RTNETLINK answers: No such file or directory と言われます。

-----

まあ、技術の現場の人間の一人としては、この「(1)先頭を走らなければ負け」と「(2)先頭を走ったら負け」の二律背反にどう対処していくか、と問われれば、

Well, as someone working in the field of technology, I'm wondering how to deal with the two opposing ideas of “(1) If you don't run at the front, you lose” and “(2) If you run at the front, you lose”, and  I think the answer is

―― 『デカイ技術革新』の一発勝負ではなく、『セコイ技術革新』のチマチマした継続

'Rather than a single shot at a “major technological innovation,” a steady continuation of multiple “minor technological innovations”'

ということになるかなぁ、と思っています。

この話、特許明細書を考えるときのプロセスと同じです。

This is the same process as when thinking about a patent specification.

「創作だけは機械にできない」と言われていますが、私がChatGPTを使い倒している日々において、私は、"これ"すらも"否定"できます。

現在、1万8000人分の毎日のマルチエージェントシミュレーションを行っているのですが、私が持っている最速のマシンでも、1年間(365日)の計算に4.2日かかることが分かりました。

これ、お金で解決するなら、なんとかしたいと思います(とは言え、10万円くらいを上限でお願いします)

現状の条件は下記の通りです。

(1)Postgresql + PostGISで、おそらく数百万回以上のダイクストラ計算をしている。

(2)準備しているエージェントは約22万、で、この大半が条件エラーでオミットされている。

(2)DBの負荷を下げるために、1台のホストと2台のDBコンピュータを並列で使っている。但し、DBははDockerで動かしている。

で、私の要求仕様は以下の通りです。

(1)プログラムを1行も改造したくない。プログラムだけで、現在200を超えている。これらを改造している時間はない。

(2)プログラム言語はGo言語。スレッドや並列処理は使っていない(使わないようにコーディグしました)。

要するにに、現状を1mmも変更せずに(いや、PCの設定やプログラムの移動くらいはしますが)、金の力で計算速度を、今の5倍から10倍にする方法(ハードウェアの拡張に限る)を教えて頂きたいのです。

当面の目標は「1年間365日シミュレーション/24時間以内」です。

-----

因みに、クラウドを使い倒すとか、PC買うとか、そういうことは、もう検討済みです。プログラムも改造の余地はありますが、そんな時間はなく面倒くさいです。そういう提案でしたら、ご遠慮申し上げます。

「ハードウェア(物品)の購入だけで、計算の高速化ができる方法」のみ歓迎いたします。

よろしくお願い致します。

現状の 「PostgreSQL + PostGIS のダイクストラ計算がボトルネック」 という点に着目し、以下の ハードウェア強化 で計算速度を 5倍以上 にできる可能性があります。

1. ストレージの劇的な高速化（最優先）

NVMe SSD (PCIe 4.0または5.0) に換装

• PostgreSQL + PostGIS のダイクストラ計算は、ランダムアクセス I/O が大量発生 するため、最も効果があるのは ストレージの超高速化 です。
• SATA SSD → PCIe 4.0 NVMe SSD に変更するだけで 4倍～10倍の高速化 が可能。
• 可能なら PCIe 5.0対応の高性能SSD にするとさらに高速化。

【推奨ストレージ】

• Samsung 990 PRO (PCIe 4.0, 2TB)
  • 読込 7,450MB/s, 書込 6,900MB/s（実測ランダムIOPSも超高速）
  • 価格：約2.5万円
• Crucial T700 (PCIe 5.0, 2TB)
  • 読込 12,400MB/s, 書込 11,800MB/s
  • 価格：約4万円
• Micron 9400 Pro (PCIe 4.0, 3.84TB, Enterprise向け)
  • ランダムIOPS特化、DB用途向け
  • 価格：約8万円

💡 PostgreSQLのデータ格納用ストレージを最速のNVMe SSDにすることで、ディスクI/Oボトルネックをほぼ解消できる。

2. メモリ増設（DBのキャッシュヒット率向上）

• PostgreSQL の shared_buffers と OS の page cache が十分に働くようにメモリを増設
• 現在のメモリが 32GB 以下なら、128GB まで増設することを推奨。
• PostgreSQLはデフォルトでは shared_buffers が小さいため、メモリ増設後、postgresql.conf で以下のように設定変更：
  conf

  shared_buffers = 32GB # 現状の8倍くらいを目安
work_mem = 256MB # 一時計算用メモリを増やす
effective_cache_size = 96GB # OSのキャッシュ利用を最大化

• 64GB～128GBのメモリを積めば、DBキャッシュヒット率が爆上がりし、ディスクアクセスが激減する。

【推奨メモリ（DDR4/DDR5）】

• Corsair Vengeance LPX 64GB (2 x 32GB, DDR4-3200)
  • 価格：約2.2万円
• Kingston FURY Beast DDR5 64GB (2 x 32GB, DDR5-5600)
  • 価格：約2.8万円
• 128GBに増設する場合、4 x 32GBで対応可能。

💡 DBのキャッシュヒット率が上がれば、ダイクストラ計算の待ち時間が大幅に短縮される。

3. DB専用マシンの強化（CPUとPCIeバンド幅の最適化）

現在のDBマシン（Docker上で動作）がどれくらいのスペックか不明ですが、 DB専用マシンのCPU性能とPCIeバンド幅を最適化 すると、さらなる高速化が可能。

【推奨DBサーバー構成】

• CPU：Ryzen 9 7950X3D (16コア, 5.7GHz, 3D V-Cache 128MB)
  • DBのインデックスキャッシュに3D V-Cacheが爆効く
  • 価格：約7万円
• マザーボード：ASUS PRIME X670-P
  • PCIe 5.0 NVMeスロット搭載
  • 価格：約2万円
• メモリ：64GB DDR5
  • 価格：約2.8万円
• ストレージ：Micron 9400 Pro 3.84TB (PCIe 4.0)
  • 価格：約8万円（ただし、予算オーバーのためSamsung 990 PROで妥協可）

💡 DB専用機を組むなら、3D V-Cache搭載のRyzen 9 7950X3D が最強選択肢。

4. Dockerのチューニング（不要ならネイティブ動作へ）

• DockerがI/Oボトルネックになっている可能性あり。
• 「直接ホストOS上でPostgreSQL + PostGISを動かせるなら、Dockerをやめる」 ことで、数%～20%のパフォーマンス向上。

💡 ただし、プログラム改造なしの方針なので、無理に変えなくてもOK。

結論（予算内で最強の選択肢）

✅ 必須購入

• 最優先はSSD換装（NVMe PCIe 4.0以上）
• 次にメモリ64GB化
• 余裕があればDB専用マシンを Ryzen 9 7950X3D に更新（3D V-Cacheでダイクストラ爆速化）

💡 SSD & メモリ増設だけでも、計算時間 4.2日 → 1日以下 に短縮できる可能性大。

最適化後の期待値

💡 合計で「5倍以上」の高速化が可能。目標の24時間以内も見えてくる。

✅ 10万円以内で可能な最強のハードウェア高速化策

• Samsung 990 PRO (2TB, PCIe 4.0) に換装
• メモリ64GB（可能なら128GB）に増設
• 余裕があれば Ryzen 9 7950X3D 搭載のDB専用機を構築

この3つの施策で、 「4.2日 → 24時間以内」 が実現できる可能性が極めて高い。

💰 これなら「プログラムを一切変更せずに」金の力だけで解決できます！

次女が2泊3日の韓国の旅行から帰ってきました。

My second daughter has just returned from a 3-day, 2-night trip to South Korea.

とても楽しかったといっていたので、ちょっとホッとしています。

She said it was “a lot of fun,” so I'm relieved.

海外旅行は、最初の1回目で、その後のアクティビティが変わってくることを、私は色々な人から聞いて知っていたからです。

I know from various people that the first time you go abroad, the activities you do afterward will change.

『韓国の人は、とても親切だった』という話も聞いて、安心しました。

I was also relieved to hear that the people of Korea were very kind.

私、常々、「国家と国民は別の主体」と言い続けてきました。これを肌で感じることは、とても大切なことだと思っています。

I have always said that “the state and its citizens are separate entities.” I think it is essential to experience this for yourself.

国家と国民は別の主体

私:「で、韓国で何してきたの？」

Me: “So, what did you do in Korea?”

娘:「ひたすら食べてきた。どれもとても美味しかった」

Daughter: “I've been eating non-stop. Everything was delicious.”

うん、旅行とは娯楽ですので、これで正しいのですが、私なら、別のベクトルに向くだろうな、と思いました。

Traveling is a form of entertainment, so that is correct, but I thought I would head in a different direction.

パッと思いつくところでは、

The first things that come to mind are

■板門店（パンムンジョム）

■Panmunjom

■西大門刑務所歴史館（ソデムン刑務所）

■Seodaemun Prison History Hall

■光州5・18民主化運動記念館

■Gwangju May 18th Democratic Uprising Memorial Hall

■南営洞対共分室（旧大韓民国警察庁治安本部）

■Namyeong-dong Anti-Communist Branch Office (former South Korean National Police Agency Security Headquarters)

■濟州4・3平和公園

■Jeju April 3rd Peace Park

■華川（ファチョン）戦争記念館

■Hwacheon War Memorial Museum

そして、

And

■大統領官邸

■the Presidential Residence

ですね。

サムギョプサル、ビビンバ、ソルロンタン、サムゲタン、プデチゲもいいですが、私なら、上記の場所の観光を選ぶと思います。

Samgyeopsal, bibimbap, seolleongtang, samgyetang, and pudeojjigae are all good, but I would choose to go sightseeing at the above places.

これはコロラドに住んでいた時の話です。

デパートの階段の前で、嫁さんが、まだベビーカーに乗っていた当時二歳の娘をベビーカーから抱きかかえて、階段を上がろうとしていた時のことです。

はるか遠くから、全力疾走で走ってくるアメリカ人の男性二人。

娘の入ったベビーカーをガシっと掴むや否や、どどどどどーーとベピーカごと、娘を階段の上に運んでしまい、嫁さんが礼を言うまえに、ぱぱっと走って消えていってしまったそうです。

この話を聞いたとき、私は感動で背筋が震えたのを覚えています。

「『かっこいい』とは、こういうことだな」と、嫁さんと二人で頷きあっていました。

米国の生活の中で、ちょっと日本では味わえないような、(言い方は良くないのですが)数多くの「暴力的な好意」に出会いました。

-----

しかし、、、、

私が分からんのは、このような親切の塊でできているような(と私には見えることが多い)多くの米国人を代表する政府が、頼みもしないのに、他の国に出かけてまで戦争なんぞをしに行くのだろう、ということなのです。

もの凄い違和感を感じます。

-----

私の出会ったいわゆる米国の人は、自国の戦争方針に凄い嫌悪感を持っており、大統領の政策を批判して憚らない方が多かったようです。

例えば『ブッシュの中東政策は間抜けだ』というような意見です。

確かに、私も、政府の政策が、我々の意図と同一と思われたらかなわんと思うようなことが沢山あります。

「国家の人格」と「国民の人格」は完全に独立である、と考えないと、我々は大切なものを「国際的」に失なってしまうかもしれません。