シミュレータの対象人数が増えると、シミュレータがフリーズしてしまう、という問題が生じたので、まずは、手っ取り早く、Dockerコンテナのメモリとスワップを倍にしてみる処理をしてみた。
起動開始までの時間が恐ろしく長い(5分以上。なんでだ?)が、とりあえず、シミュレーション人数500人(実行時間4分弱)→3000人(22分)→4000人(16分? なんで減っている)→での稼動を確認。
しかし、5000人は失敗、4500人も失敗。では、メモリをもう2G増量。
そこで、6GBまで上げてみた。
うん、こうしても、4500人は落ちるなぁ。
websocketコネクション数の問題かなぁ?
それより、多分、これは私のPCの物理メモリが16GBしかないので、Dockerの設定を大きくしても効果が出てこないのだろう、と推測しています。
ならば、逆に6GBで設定してしたままにしておいて、コンテナの方でメモリ制限するというのは、どうかな、と思いやってみました。
以下、docker-compose.ymlで改造した部分。今回は、controlのコンテナだけメモリ増量できれば良い(それ以外のコンテナは1GBで縛る)、という方針としました。
# docker-compose のバージョンversion: '3'# 各コンテナの情報services:# postgres サービスpostgres:image: pamtrak06/postgis-pgrouting-osm:latest# コンテナの名前# container_name: postgres_db# Dockerfile のディレクトリパスbuild:context: .dockerfile: ./docker/postgres/Dockerfile# postgres 設定environment:- POSTGRES_HOST_AUTH_METHOD=trust- POSTGRES_USER=postgres- POSTGRES_PASSWORD=XXXXXXX- POSTGRES_DB=XXXXXXvolumes:- db_data- ./control:/go/src/work # マウントディレクトリ指定expose:- 5432 # 兄弟コンテナから5432でアクセスできるようにするports:- "8910-8911:5432"tty: true # コンテナの起動永続化mem_limit: 1g # メモリを1Gに制限db_data:image: busyboxvolumes:- /data/dbmem_limit: 1g # メモリを1Gに制限app_control: # service名build: . # ビルドに使用するDockerfileがあるディレクトリ指定tty: true # コンテナの起動永続化volumes:- ./control:/go/src/work # マウントディレクトリ指定expose:- 8900ports:- "8900-8901:8900"image: control_agent# container_name: control_agent_app# restart: always # ログイン時に自動起動# ここだけメモリの制限をしないapp_user: # service名build: . # ビルドに使用するDockerfileがあるディレクトリ指定tty: true # コンテナの起動永続化volumes:- ./user:/go/src/work # マウントディレクトリ指定expose:- 8920ports:- "8920-8921:8920"image: user_agent# container_name: user_agent_app# restart: always # ログイン時に自動起動mem_limit: 1g # メモリを1Gに制限app_bus: # service名build: . # ビルドに使用するDockerfileがあるディレクトリ指定tty: true # コンテナの起動永続化volumes:- ./bus:/go/src/work # マウントディレクトリ指定expose:- 8930ports:- "8930-8931:8930"image: bus_agent# container_name: bus_agent_app# restart: always # ログイン時に自動起動mem_limit: 1g # メモリを1Gに制限
5000人は失敗したけど、4500人まで増やすことに成功しました。
それと、controlコンテナのスピードが物凄く上がっているような気がします(比較計測できませんが)。