以前、こちらの記事で書いたように、 OpenStreetMap のタイルサーバーをほそぼそと運用しています。
最近、Postgresql のDB容量が非常に大きくなって、ディスク容量不足で、地図データの更新ができなくなってしまいました。削除前は、 postgresql だけで 100GB 超えるディスク使用量でした。
mor@map:~$ sudo du -h -s /var/lib/postgresql/
108G /var/lib/postgresql/
mor@map:~$
ディスクの容量を増やそうか、これを機に EC2 などでの運用に切り替えようかいろいろと悩んだのですが、最終的には、
- ハードウェアおよび既存のインストールしてあるソフトウェアは、なるべく今あるものをそのまま利用する
- 地図データを再セットアップし、DB容量をスリムにする
という方針にして、地図データを再セットアップすることにしました。ということで、今回はタイルサーバーの地図データの再セットアップを行った際のメモをまとめておきます。
事前調査
最初にタイルサーバーをセットアップしたのが2017年12月頃だったので、ずいぶんと立ってます。なので、まず、以前にインストールしたものと最新版の比較をして、準備するべきことがないか確認します。
ソフトウェア |
セットアップ時(2017/12頃) |
現時点(2020/9頃) |
備考 |
Postgresql |
v9.5 |
v12 |
|
mod_tile & renderd (SomeoneElseOSM版) |
旧masterブランチ(現switch2osm) 7b284e9 |
現switch2osm ブランチ aa3d8ed |
ブランチ名に変更があった 更新スクリプト周りで若干コミットがある |
Mapnik |
v3.0.9 |
v.3.0.23 |
|
osm2pgsql |
v0.95.0-dev (da50b02) |
v1.3.0 |
リポジトリから最新版を利用 |
openstreetmap-carto |
v4.6.0 (ac7d4fb) |
v5.2.0+ |
+ はリリース版から進んでいることを示す リポジトリから最新版を利用 |
CartoCSS (carto) |
v0.18.2 |
v1.2.0 |
|
この中でも openstreetmap-carto が 2020/4/27 のコミットで、シェープファイルのダウンロードとその扱いを大きく変更しています(2019/3/31 のコミットでダウンロード先自体も切り替わってますし、その後も特定のファイルを使わなくなったりいろいろと変わってます)。
なので、 openstreetmap-carto については、最新版を使うようにして、その他は既存のままで運用しようと思います(openstreetmap-carto については CartoCSS が 0.18.0 以上, Mapnik が 3.0 以上であれば良さそうなので)。
今回は特に追加のライブラリ等はありませんでしたが、 openstreetmap-carto が v5.0.0 あたりで python3 ベースに切り替わっているので、必要があれば関連するライブラリ等もインストールしておきます。
再セットアップ作業
再セットアップは大まかに次のように進めます。
- 作業に先立ち準備
- 既存のデータベース(gis)を削除して、ディスク容量を回復
- 再度 gis データベースを作成
- 最新の openstreetmap-carto によるスタイルシートを作成
- 日本の地図データ(再セットアップ時の最新データ)を投入
- 最新の openstreetmap-carto によるシェープファイルを設定
- タイルサーバーを再起動
準備
まずは、作業時にトラブらないように、地図データの更新を停止します。
crontab を編集して、
osm@map:~$ crontab -e
コメントアウトしておきます。
crontab: installing new crontab
osm@map:~$
なお、 osm-tile-update-expire-w-mail は、内部で openstreetmap-tiles-update-expire スクリプトを呼び出し、エラーがあった場合はメールを送信するためのスクリプトです。
gis データベースの削除
次に、postgressqlのデータベースを削除し、再作成します。ですが、いきなり dropdb を実行してもできませんでした。
osm@map:~$ dropdb gis
dropdb: database removal failed: ERROR: database "gis" is being accessed by other users
DETAIL: There are 2 other sessions using the database.
osm@map:~$
なので、一旦 apache と renderd を止めます。
mor@map:~$ sudo service apache2 stop
mor@map:~$ sudo service renderd stop
もういちど、 dropdb を行います
mor@map:~$ su - osm
パスワード:
osm@map:~$ dropdb gis
削除できました。
ちなみに、削除前のテーブル構成はこんな感じでした。
osm@map:~$ psql -d gis
psql (9.5.23)
Type "help" for help.
gis=> \d
List of relations
Schema | Name | Type | Owner
--------+--------------------+-------+----------
public | geography_columns | view | postgres
public | geometry_columns | view | osm
public | planet_osm_line | table | osm
public | planet_osm_nodes | table | osm
public | planet_osm_point | table | osm
public | planet_osm_polygon | table | osm
public | planet_osm_rels | table | osm
public | planet_osm_roads | table | osm
public | planet_osm_ways | table | osm
public | raster_columns | view | postgres
public | raster_overviews | view | postgres
public | spatial_ref_sys | table | osm
(12 rows)
gis=>
postgres の場合、データベースを削除してもディスクがOSに戻されないようです。そいうときは、 vacuum をやるとよいようです。
mor@map:~$ sudo -u postgres -i
postgres@map:~$ vacuumdb --full
しかし、ディスク容量を見てもほとんど減ってない・・・
mor@map:~$ sudo du -h -s /var/lib/postgresql/
105M /var/lib/postgresql/
mor@map:~$
vacuumdb ではなく vacuum を試したり postgres のプロセスをいったん止めたりしても変わらずでした。とここで困ってしまいました。
postgres でディスク容量を回復するために
postgres 普段使ってないので、慌ててあれこれと調べてみると、下記の記事の方法を参考にしたら、データベース削除後でもなんとかディスク容量を回復できそうなことがわかりました。
おもっきり要約すると、バックアップを取り、データ保存のディレクトリを削除してから、再度初期化する、という方法のようです。
ただ、Ubuntu の Postgresql の場合は initdb コマンドが見つからない(こちらの記事などを参照)のと、直接ディレクトリを削除するのは抵抗あるな、と思っていろいろと調べていたら、下記記事に pg_dropcluster を使った postgres のデータ保管場所を変更する方法が載っていたので、
User:Ngt - OpenStreetMap Wiki
これを参考にして、 pg_dropcluster / pg_createcluster (Ubuntu の postgresql 用のコマンド)を使っての作業としてやってみました。
作業前に現在のクラスターの情報を表示してみます。
mor@map:~$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.5 main 5432 online postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log
mor@map:~$
上記の記事にもあるように念のためバックアップを取っておきます(結局、今回は使いませんでしたが)。バックアップ先は /home/osm/tmp/archive/ としてだれでも書き込めるようにしておきます。
mor@map:~$ sudo -u postgres -i
postgres@map:~$ pg_dumpall | gzip -9 > /home/osm/tmp/archive/all.dbs.gz
postgres@map:~$ exit
ログアウト
mor@map:~$ sudo ls -l /var/lib/postgresql/9.5/main/
合計 84
-rw------- 1 postgres postgres 4 12月 27 2017 PG_VERSION
drwx------ 6 postgres postgres 4096 9月 7 11:54 base
drwx------ 2 postgres postgres 4096 9月 7 14:32 global
drwx------ 2 postgres postgres 4096 7月 9 23:19 pg_clog
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_commit_ts
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_dynshmem
drwx------ 4 postgres postgres 4096 12月 27 2017 pg_logical
drwx------ 4 postgres postgres 4096 12月 27 2017 pg_multixact
drwx------ 2 postgres postgres 4096 9月 7 14:11 pg_notify
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_replslot
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_serial
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_snapshots
drwx------ 2 postgres postgres 4096 9月 7 14:11 pg_stat
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_stat_tmp
drwx------ 2 postgres postgres 4096 8月 20 14:42 pg_subtrans
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_tblspc
drwx------ 2 postgres postgres 4096 12月 27 2017 pg_twophase
drwx------ 3 postgres postgres 4096 9月 4 22:58 pg_xlog
-rw------- 1 postgres postgres 88 12月 27 2017 postgresql.auto.conf
-rw------- 1 postgres postgres 133 9月 7 14:11 postmaster.opts
-rw------- 1 postgres postgres 101 9月 7 14:11 postmaster.pid
mor@map:~$
mor@map:~$ sudo cp -p /var/lib/postgresql/9.5/main/postgresql.auto.conf /home/osm/tmp/archive/
mor@map:~$ mkdir /home/osm/tmp/archive/etc/
mor@map:~$ sudo cp -p /etc/postgresql/9.5/main/* /home/osm/tmp/archive/etc/
mor@map:~$
って感じです。
次はクラスターの削除です。
mor@map:~$ sudo -u postgres -i
postgres@map:~$ pg_dropcluster --stop 9.5 main
Warning: stopping the cluster using pg_ctlcluster will mark the systemd unit as failed. Consider using systemctl:
sudo systemctl stop postgresql@9.5-main
Warning: systemd was not informed about the removed yet. Operations like "service postgresql start" might fail. To fix, run:
sudo systemctl daemon-reload
postgres@map:~$ exit
ログアウト
mor@map:~$ sudo du -h -s /var/lib/postgresql/
12K /var/lib/postgresql/
mor@map:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 799M 27M 772M 4% /run
/dev/mapper/map--vg-root 138G 23G 109G 18% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda1 472M 161M 287M 36% /boot
tmpfs 799M 0 799M 0% /run/user/1000
mor@map:~$
無事にクラスターで使っていた領域が削除され、ディスク容量が空きました。
クラスターを再作成します。
mor@map:~$ sudo -u postgres -i
postgres@map:~$ pg_createcluster 9.5 main
Creating new cluster 9.5/main ...
config /etc/postgresql/9.5/main
data /var/lib/postgresql/9.5/main
locale ja_JP.UTF-8
socket /var/run/postgresql
port 5432
Warning: systemd does not know about the new cluster yet. Operations like "service postgresql start" will not handle it. To fix, run:
sudo systemctl daemon-reload
postgres@map:~$
warning があるように postgres がうまく再起動できていないので、手作業で再起動しておきます。
mor@map:~$ sudo service postgresql restart
この状態で、現在のデータベースを表示させると、
mor@map:~$ sudo -u postgres -i
postgres@map:~$ psql -l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
postgres | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 |
template0 | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(3 rows)
postgres@map:~$
となり、gis データベース削除前のセットアップ直後と同じになってました。
再作成したクラスターの情報も見ておきます。
mor@map:~$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
9.5 main 5432 online postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.5-main.log
mor@map:~$
削除前と同じですね。
これで最初の状態(postgresをインストールした直後の状態)に戻ったと思います(思いたいです)。
結局のところ、どうも postgres の場合は、データベースを消してからディスク容量を回復させるのではなく、データベースを消す前に一旦テーブルの中身を削除して、 vacuum full とかで容量を回復してから、データベースを消すのが比較的楽だったように思えます。もっとも、これもまだ試してないので、次回の機会に試すことにしたいと思います。
ちなみに、使用しているクラスターに他で利用しているデータベースとかがあると、気軽に再作成というわけにはいかないので、この方法だと難しいかもしれません。今回の場合は、 OpenStreetMap のタイルサーバー用のデータベースだけなので、比較的問題なく進めた印象です。
gis データベースの再作成
ここからはタイルサーバーのセットアップ方法に従って gis データベースを作っておきます。
db 用のユーザーが残っているか確認します。
mor@map:~$ sudo -u postgres -i
[sudo] mor のパスワード:
postgres@map:~$ psql
psql (9.5.23)
Type "help" for help.
postgres=
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
postgres=
ユーザーも消えてますね。クラスター毎削除しているので当たり前といえば当たり前ですかね。なので、ユーザーを作成するところからもう一度やります。
mor@map:~$ sudo -u postgres -i
postgres@map:~$
postgres@map:~$ createuser osm
postgres@map:~$ createdb -E UTF8 -O osm gis
postgres@map:~$ psql
psql (9.5.23)
Type "help" for help.
postgres=
You are now connected to database "gis" as user "postgres".
gis=
No relations found.
gis=
CREATE EXTENSION
gis=
List of relations
Schema | Name | Type | Owner
--------+-------------------+-------+----------
public | geography_columns | view | postgres
public | geometry_columns | view | postgres
public | raster_columns | view | postgres
public | raster_overviews | view | postgres
public | spatial_ref_sys | table | postgres
(5 rows)
gis=
CREATE EXTENSION
gis=
List of relations
Schema | Name | Type | Owner
--------+-------------------+-------+----------
public | geography_columns | view | postgres
public | geometry_columns | view | postgres
public | raster_columns | view | postgres
public | raster_overviews | view | postgres
public | spatial_ref_sys | table | postgres
(5 rows)
gis=
ALTER TABLE
gis=
ALTER TABLE
gis=
List of relations
Schema | Name | Type | Owner
--------+-------------------+-------+----------
public | geography_columns | view | postgres
public | geometry_columns | view | osm
public | raster_columns | view | postgres
public | raster_overviews | view | postgres
public | spatial_ref_sys | table | osm
(5 rows)
gis=
postgres@map:~$ exit
作業ごとにテーブルを表示しているのは、どんなものが作られているのか見てみたかったからですので、それ以上の他意はありません。
最新の openstreetmap-carto によるスタイルシートの作成
最新の openstreetmap-carto をインストールする前に、既存の openstreetmap-carto の退避しておきます。
osm@map:~/src$ mv openstreetmap-carto/ openstreetmap-carto.old/
最新のリポジトリを clone します。
osm@map:~/src$ git clone git://github.com/gravitystorm/openstreetmap-carto.git
Cloning into 'openstreetmap-carto'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 15162 (delta 1), reused 0 (delta 0), pack-reused 15156
Receiving objects: 100% (15162/15162), 14.99 MiB | 5.48 MiB/s, done.
Resolving deltas: 100% (10353/10353), done.
Checking connectivity... done.
osm@map:~/src$
スタイルシートを生成します。
osm@map:~/src$ cd openstreetmap-carto
osm@map:~/src/openstreetmap-carto$ carto project.mml > mapnik.xml
osm@map:~/src/openstreetmap-carto$
最新の地図データの投入
改めて、今日(2020/9/7)時点の、日本の pbf ファイルをダウンロードします。
osm@map:~$ cd data/
osm@map:~/data$ mv japan-latest.osm.pbf japan-latest.osm.pbf.20171227
osm@map:~/data$ wget https://download.geofabrik.de/asia/japan-latest.osm.pbf
地図データを db へインポートします。前回の記事とほとんど同じですが、メモリとプロセッサ数を多く割り当ててます。
osm@map:~$ osm2pgsql -d gis --create --slim -G --hstore --tag-transform-script ~/src/openstreetmap-carto/openstreetmap-carto.lua -C 7500 --number-processes 4 -S ~/src/openstreetmap-carto/openstreetmap-carto.style ~/data/japan-latest.osm.pbf
osm2pgsql version 0.95.0-dev (64 bit id space)
Using lua based tag processing pipeline with script /home/osm/src/openstreetmap-carto/openstreetmap-carto.lua
Using projection SRS 3857 (Spherical Mercator)
(中略)
node cache: stored: 191123228(100.00%), storage efficiency: 52.57% (dense blocks: 6600, sparse nodes: 154735389), hit rate: 100.00%
Osm2pgsql took 12846s overall
osm@map:~$
今回は3時間半ぐらいでした。
新しい openstreetmap-carto によるシェープファイルの設定
openstreetmap-carto のスクリプトを利用して、必要なシェープファイルをダウンロードします。前回のセットアップ時とはこの部分が異なっています。
osm@map:~/src/openstreetmap-carto$ ./scripts/get-external-data.py
/home/osm/.local/lib/python3.5/site-packages/psycopg2/__init__.py:144: UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip install psycopg2-binary" instead. For details see: <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.
""")
INFO:root:Checking table water_polygons
INFO:root:Checking table icesheet_outlines
INFO:root:Checking table simplified_water_polygons
INFO:root:Checking table ne_110m_admin_0_boundary_lines_land
INFO:root:Checking table icesheet_polygons
osm@map:~/src/openstreetmap-carto$
これで、地図データの再セットアップが完了したはずです。
動作確認
早速、動作確認します。
renderd および apache2 を起動します。
mor@map:~$ sudo service apache2 start
mor@map:~$ sudo service renderd start
テスト用に接続してみます。
問題なく地図データが表示されることが確認できました。
地図データの再セットアップ後のディスク容量としては、
mor@map:/var/lib/postgresql$ sudo du -h -s ./*
[sudo] mor のパスワード:
40G ./9.5
mor@map:/var/lib/postgresql$
ずいぶんと減りました。
地図データの更新設定
以前行ったタイルサーバーの更新設定の記事を参考にして、 mod_tile/openstreetmap-tiles-update-expire を利用した地図データの更新を有効にします。
今回も更新間隔は、以前と同じく hourly にします。ちなみに、更新間隔はそんなに頻繁でなくてもいいと思うので、実は一度 daily にして試したのですが、処理途中でメモリが足りなくてきちんと終了できなかったので、諦めました。
なお、タイルサーバーの更新設定の記事の中で参考にしていた更新手順の説明へのリンクが切れています。いまだと、下記のURLなどがまとまっているようです。
Keeping the local database in sync with OSM | OpenStreetMap Carto Tutorials
mod_tile リポジトリの更新
mod_tile のリポジトリをみると、スクリプトがいくつか更新されているので、最新にしておきます。
osm@map:~/src/mod_tile$
osm@map:~/src/mod_tile$ git branch --all
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/zoom
osm@map:~/src/mod_tile$ git fetch
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Total 56 (delta 35), reused 35 (delta 35), pack-reused 21
Unpacking objects: 100% (56/56), done.
From git://github.com/SomeoneElseOSM/mod_tile
+ 7b284e9...e25bfdb master -> origin/master (forced update)
* [new branch] switch2osm -> origin/switch2osm
* [new branch] typos_etc -> origin/typos_etc
140bedc..7fe2f03 zoom -> origin/zoom
osm@map:~/src/mod_tile$
osm@map:~/src/mod_tile$ git branch --all
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/switch2osm
remotes/origin/typos_etc
remotes/origin/zoom
osm@map:~/src/mod_tile$
そのうえで、リモートブランチ switch2osm に切り替えます。
osm@map:~/src/mod_tile$ git checkout -b switch2osm origin/switch2osm
M debian/renderd.init
Branch switch2osm set up to track remote branch switch2osm from origin.
Switched to a new branch 'switch2osm'
osm@map:~/src/mod_tile$
これは、以前の記事の時点だと、 master ブランチからcloneしていたのが、switch2osmブランチからcloneするように変わっているのに対応するためです。
必要に応じて openstreetmap-tiles-update-expire のスクリプトを修正しておきます。修正内容は、タイルサーバーの更新失敗で対応した記事の通りです。
設定ファイルの修正
次に、どこまでの差分が反映されているかの設定ファイル(state.txt)を再作成します(やり方は以前行ったタイルサーバーの更新設定の記事に準じています)。
今回の地図データは 2020/9/7 時点のデータをダウンロードしていたので、 2020/9/6 時点の state.txt を取得し作成します。
osm@map:~/src/mod_tile$ cd /var/lib/mod_tile/.osmosis/
osm@map:/var/lib/mod_tile/.osmosis$ wget https://planet.openstreetmap.org/replication/hour/000/070/000.state.txt
--2020-09-08 11:36:23-- https://planet.openstreetmap.org/replication/hour/000/070/000.state.txt
planet.openstreetmap.org (planet.openstreetmap.org) をDNSに問いあわせています... 130.117.76.10, 2001:978:2:2c::172:a
planet.openstreetmap.org (planet.openstreetmap.org)|130.117.76.10|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 84 [text/plain]
`000.state.txt' に保存中
000.state.txt 100%[=================================================================================================>] 84 --.-KB/s 時間 0s
2020-09-08 11:36:24 (11.6 MB/s) - `000.state.txt' へ保存完了 [84/84]
osm@map:/var/lib/mod_tile/.osmosis$ cat 000.state.txt
sequenceNumber=70000
timestamp=2020-09-06T23\:00\:00Z
osm@map:/var/lib/mod_tile/.osmosis$ mv 000.state.txt state.txt
設定ファイルのほうは変更ありません(一応、設定内容を掲載しておきます)。
osm@map:/var/lib/mod_tile/.osmosis$ cat configuration.txt
baseUrl=https://planet.openstreetmap.org/replication/hour
maxInterval = 14400
osm@map:/var/lib/mod_tile/.osmosis$
補足
なお、上記では欲しい日時の state.txt を直接取得していますが、下記のURLを呼び出せば、wgetで取得しなくても、state.txtの内容を得ることができます。
replicate-sequences
また、 openstreetmap-tiles-update-expire スクリプトを 日付の引数付き(yyyy-mm-dd の形式で与える)で呼び出しても、初期化の過程で引数のstate.txtを作成してくれます。
例えば、こんな感じになります。
osm@map:~/tmp/mod_tile$ ./openstreetmap-tiles-update-expire 2020-09-07
--2020-09-08 13:41:24-- http://replicate-sequences.osm.mazdermind.de/?2020-09-07T00:00:00Z
replicate-sequences.osm.mazdermind.de (replicate-sequences.osm.mazdermind.de) をDNSに問いあわせています... 188.68.50.52, 2a03:4000:6:d080::1
replicate-sequences.osm.mazdermind.de (replicate-sequences.osm.mazdermind.de)|188.68.50.52|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 301 Moved Permanently
場所: https://replicate-sequences.osm.mazdermind.de/?2020-09-07T00:00:00Z [続く]
--2020-09-08 13:41:25-- https://replicate-sequences.osm.mazdermind.de/?2020-09-07T00:00:00Z
replicate-sequences.osm.mazdermind.de (replicate-sequences.osm.mazdermind.de)|188.68.50.52|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 332 [text/plain]
`/home/osm/tmp/jm//.osmosis/state.txt' に保存中
/home/osm/tmp/jm//.osmosis/state.txt 100%[=================================================================================================>] 332 --.-KB/s 時間 0s
2020-09-08 13:41:26 (42.1 MB/s) - `/home/osm/tmp/jm//.osmosis/state.txt' へ保存完了 [332/332]
osm@map:~/tmp/mod_tile$
スクリプトで指定した作業ディレクトリ(この例では ~/tmp/jm/.osmosis/ )が作られ、その中には
osm@map:~/tmp/jm$ ls -laF .osmosis/
合計 20
drwxrwxr-x 2 osm osm 4096 9月 8 13:41 ./
drwxrwxr-x 4 osm osm 4096 9月 8 13:41 ../
-rw-rw-r-- 1 osm osm 253 9月 8 13:41 configuration.txt
-rw-rw-r-- 1 osm osm 253 9月 8 13:41 configuration_orig.txt
-rw-rw-r-- 1 osm osm 0 9月 8 13:41 download.lock
-rw-rw-r-- 1 osm osm 332 9月 8 13:41 state.txt
osm@map:~/tmp/jm$
といくつかのファイルができています。configuration.txt と state.txt を見ると下記のようになっていました。
configuration.txt の URL は minutely のものになっています。
osm@map:~/tmp/jm/.osmosis$ cat configuration.txt
baseUrl=https://planet.openstreetmap.org/replication/minute
maxInterval = 3600
osm@map:~/tmp/jm/.osmosis$
state.txt は引数で与えた日付けに対する minutely のファイルになります。
osm@map:~/tmp/jm/.osmosis$ cat state.txt
sequenceNumber=4184319
txnMaxQueried=3010675683
txnActiveList=
txnReadyList=
txnMax=3010675683
timestamp=2020-09-06T23\:59\:02Z
osm@map:~/tmp/jm/.osmosis$
これらを使って初期化するのもありかと思います。
テスト
一度、マニュアルで実行します
osm@map:~/src/mod_tile$ ./openstreetmap-tiles-update-expire
osm@map:~/src/mod_tile$
特にエラー等が表示されず、ログファイルにもエラーが記録されていなければ、問題ないと思います。
問題なければ、 crontab を編集して、定期的に実行するようにします。
6 */1 * * * /home/osm/bin/osm-tile-update-expire-w-mail > /dev/null 2>&1
postgres の autovacuum を設定
恥ずかしながら、今回の作業時まで、 postgres の場合は削除とか更新の際に、古いデータが消されずに追記されるということを知りませんでした。
データベースの動作がこれを前提にしているので、ディスク容量が過剰に増えないように、自動的に不要領域の回収を行う機能もついてるようです(自動バキューム)。
デフォルトでも有効という情報もちらほら見かけますが、念のため、設定ファイルでこれを有効にしたいと思います。
/etc/postgres/9.5/main/postgresql.conf
track_counts = on
(中略)
autovacuum = on
再起動します。
mor@map:/etc/postgresql/9.5/main$ sudo service postgresql restart
プロセスを見ると autovacuum というがあるので、これで動いているということなのかな?
mor@map:/etc/postgresql/9.5/main$ ps aux | grep postgres
postgres 10211 0.4 0.3 294616 24544 ? S 14:38 0:00 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf
postgres 10213 0.0 0.0 294616 3972 ? Ss 14:38 0:00 postgres: checkpointer process
postgres 10214 0.0 0.0 294616 3972 ? Ss 14:38 0:00 postgres: writer process
postgres 10215 0.0 0.0 294616 3972 ? Ss 14:38 0:00 postgres: wal writer process
postgres 10216 0.0 0.0 295064 6652 ? Ss 14:38 0:00 postgres: autovacuum launcher process
postgres 10217 0.0 0.0 149748 4208 ? Ss 14:38 0:00 postgres: stats collector process
mor 10232 0.0 0.0 13972 892 pts/0 S+ 14:38 0:00 grep --color=auto postgres
mor@map:/etc/postgresql/9.5/main$
しばらくこれで様子見したいと思います。
雑感
ディスク容量について
上記でもどこかで触れたように、実は今回の作業を通じて、そもそも postgres では削除や更新の場合に、前のデータを消すわけではなく、常に追記していくということがわかりました。なるほど、そりゃあディスク容量が足りなくなりますね。
一応、 autovacuum の動作設定をしましたが、デフォルトで既に有効になっているという記述も見かけたので、今回のディスク容量不足は autovacuum では解決できない可能性もあります。
OpenStreetMap の Wiki を見ていたら、DB容量が肥大化する理由の一つとして、更新の際に削除された不要なノードへのリンクを持ったデータの存在があるようです。
HowTo minutely hstore - OpenStreetMap Wiki
今回は試しませんでしたが、次にディスク使用量が増えてきた時は試してもよいかもしれません。
EC2 での運用について
実は、ディスク容量不足が発覚した後、ついでにサーバー自体をクラウドに持っていこうとして、 EC2 (t3a.medium, 2vCPU, 4GB メモリ, 80GB SSD) 上に Ubuntu 20.04 ベースでタイルサーバーを構築したのですが、いかんせん処理が遅いのが気になりました。(計ってはないですが)今ある古い物理サーバーの処理よりも遅い印象です。まったくの推測ですがメモリが効いているのかな?
これ以上のスペックのインスタンスに切り替えると、お試し用に小遣いの範囲で運用している身としては結構つらくなってくるので今回は諦めました。
ちなみに、 Ubuntu 20.04 ベースだと、こちらにあるように osm2pgsql のインストールが apt でできるので、その分作業が減って楽になってましたよ。
まあ、今だと Docker で簡単にタイルサーバーを立ち上げることもできるので、新たに試すならこれを使うのもいいかもしれませんね。
なんにせよ、これでまた当面タイルサーバーを運用していきたいと思います。