新環境に移行していろいろ動作チェックをしていたら、jma-receview が立ち上がらないのに気付いた。x-server の関係かなといろいろ設定をいじってみたが動かない。ふと思いついて xclock を動かしたらちゃんと表示された。つまり、x-server の問題ではなく、jma-receview の問題だ。
ここで「こういうのってなんだろう、こういうのって前にもあったぞ」と、ぼやっと記憶がよみがえってきた。OpenDolphin 日記で jma-receview を検索したらヒットした。これだ。.config/user-dirs.dirs ファイルを作って、無事に立ち上がるようになった。なんでも記録しておくことは大事だなと思った。
環境一新に合わせて、ついでに新サーバを組もうと思って CPU を物色していたら、i5-12400F という CPU が、一体安かったので買ってしまった。マザーボードは ASUS PRIME/B660M-A/D4。この CPU はプロセッサーグラフィックスの付いていない CPU で、オンボードグラフィックは使えず、別にグラフィックボードを用意しないと画面表示ができないものだった。最初知らなくて、画面が表示されずに焦ったが、古い GeForce 7300 LE が院長室のがらくた箱で眠っていたので、それを刺して無事使えるようになった。GeForce 7300 LE も、まさか自分が再び使われる日がくるとは思ってなかっただろう。
早速、レセプト処理速度でベンチマークをしてみたら、開業以来最速と言われた 2019年の i9-9900 を上回る爆速であった。これは CPU の威力もさることながら、M.2 NVMe の進歩が大きいと思われる。
| CPU | データチェック | レセプト作成 |
|---|---|---|
| i7-3770@3.4G SSD |
6.2 | 4.7 |
| i9-9900K@3.6G NVMe |
17.0 | 13.2 |
| i5-12400F@2.5GHz NVMe |
26.7 | 25.3 |
自宅サーバに続いて、業務用マシンも ubuntu 20.04 の kvm 仮想マシンに移行した。そもそも、自宅サーバの ubuntu 18.04 + xen が、apt-get upgrade 後にネットワークがつながらなくなってしまったのがことの始まりであった。つまり、同じ構成で運用している業務用マシンも、次にレポジトリアップデートしたが最後、一体使えなくなるであろうということである。自宅サーバは、復活まで２週間を要しており、業務用マシンをアップデートする前に事態に気付いたのは不幸中の幸いであった。
当院の業務用サーバでは、orca サーバ、dolphin サーバ、文書を保存するファイルサーバの3台のサーバを仮想マシンで運用している。今回のインストールは完全リフレッシュしようと思って、全て新規に ubuntu 20.04 をインストールした。
文書サーバは samba で共有している。samba サーバの設定は、いつもつながらなくて苦しむ印象がある。今回もつながらなくて、かなりの時間苦しんだ。原因は単純に共有の大元のディレクトリの所有権の設定ミスだった。orz。このサーバでは、dzd100.rb も動いているので、設定を忘れてはいけない。
orca サーバはずっと release-upgrade でつないできたので、de novo でインストールしたのはほぼ10年ぶりである。インストールマニュアルと首っ引きでインストールした。標準インストールに続いて、pusher インストール、オン資インストールと進んだ。
orca はプリンタ設定が一体鬼門であると思う。以前インストールしていたBrother HL-5250DN Foomatic/pxlmonoはメニューに出なくなっていた。代わりにbrother-cups-wrapper-laserパッケージをインストールして、Brother HL5250DN for CUPSを選択した。さらに当院ではプリンタ関連で特殊な操作を行っていて、これも設定し直した。
オン資関連では、almex の保険証 OCR データを横取りして修正する自作スクリプトを導入していて、その設定も必要だった。
あと、MaxJobs 関連で rc.local を使っていたが、新規インストールの ubuntu 20.04 では rc.local はなくなっていた。ファイルを作れば呼ばれることは呼ばれるらしいが、cron の @reboot に設定を移した。OpenDolphin との連携で、orca にアクセスするために orca 側で postgresql.conf の listen_address と pg_hba.conf の設定が必要。これもすっかり忘れていて、OpenDolphin が立ち上がらなくて気付いた。
ubuntu 20.04 の orca 5.2 は 2025年 3月までサポート。またしばらくいじらなくてすみそう。
de novo インストールで、一番楽だったのは dolphin サーバだった。wildfly は dolphin ホームディレクトリで走っているので、postgres と java をインストールして、ホームディレクトリをコピーすれば、基本的に移行完了。
ゲストを作成するのには virt-install コマンドを使う。その際、--os-variant=ubuntu20.04 を指定すると、自動的に準仮想化で設定してくれる。--os-variant のパラメータは、libosinfo-bin をインストールして、osinfo-query で確認できる。
$ sudo aptitude install libosinfo-bin $ osinfo-query os | grep -i ubuntu
virt-install コマンドを入力後、vnc でアクセスしてインストールを進める。
$ sudo virt-install --name=template \ --os-variant=ubuntu20.04 --vcpu=2 --ram=2048 \ --graphics vnc,listen=0.0.0.0,port=5900,keymap=ja,password=pass \ --cdrom=/home/pinus/ubuntu-20.04.5-live-server-amd64.iso \ --network network=host-bridge --disk /dev/sda3,device=disk \ --check path_in_use=off WARNING グラフィックスが要求されていますが DISPLAY 変数が設定されていません。virt-viewer を起動できません 。 WARNING ゲストのコンソールがないため、デフォルト値 --wait -1 を適用します。 インストールの開始中... Domain installation still in progress. Waiting for installation to complete. --- ここで vnc でインストール作業 --- ドメインがシャットダウンしました。続けています。 仮想マシンの作成が完了しました。 ゲストを再起動しています。
ずっと自宅サーバーで ownCloud を運用していたが、今回環境変更にあたって、話題の Nextcloud をインストールしてみた。snap というのを使って簡単にインストールできる。
$ sudo snap install nextcloud nextcloud 25.0.2snap1 from Nextcloud✓ installed
インストール終了後、apache 設定しようと思ったら apache がなかった。service にないし /etc/apache2 もない。きつねに包まれたような気分になった。調べてみると、snap パッケージの場合、Nextcloud が使う専用の apache を snap 内で使っているらしい。時代は進んでいる。
/snap/nextcloud/current/conf/httpd.conf /snap/nextcloud/current/conf/ssl.conf /var/snap/nextcloud/common/nextcloud/data/user/files/ /var/snap/nextcloud/current/nextcloud/config/config.php
これでやっと自宅サーバが復活した。トラブル発生から復活まで2週間かかった。
1月中旬に Ubuntu 18.04 + xen + ownCloud で運用していた自宅サーバ (mac mini 2011) で、いつもどおりレポジトリの更新をインストールしたら、dom-u の owncloud のネットワークがつながらなくなった。（＊）
振り返ってみると、自宅サーバは debian squeeze で運用開始して、その後 ubuntu 11.04 に移行し、代々 release-upgrade を繰り返して環境を引き継いできたものであった。その間、インターフェースの名前は predictable に代わり、ネットワーク設定が netplan になり、自宅サーバは時代の変化に取り残された化石マシンになってしまっていた。
それが原因だろうと思い、predictable interface name にしてみたり、netplan にしてみたりしたが、結局つながらない。dom-u ではネットワークが up しており、dom-0 では vif1.0 が見えている、でもつながってないので、bridge のところで何かおきているらしい。web 検索で見つけた echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables というのも試してみたがつながらない。
数日あれこれ試行錯誤したがだめで、かなり悩んだが、そういえば ubuntu 18.04 はまもなくサポート終了だし、環境を一新するいい機会だと考えることにした。
当院開業の時、サーバを仮想環境で動かすに当たって、準仮想化の Xen と、コンテナ型の Linux-VServer、 OpenVZ を比較検討して、xen を採用したという経緯があった。
今の状況だと、検討するとしたら準仮想化の kvm かコンテナ型の docker ということになると思う。今回は kvm で構築することにした。機会があれば docker も試してみたい気はする。
$ sudo apt install qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager $ lsmod | grep kvm kvm_intel 282624 0 kvm 663552 1 kvm_intel
$ sudo systemctl enable --now libvirtd
$ systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
：
# /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. br_netfilter/etc/sysctl.conf
#added net.bridge.bridge-nf-call-iptables = 0
$ cat /proc/sys/net/bridge/bridge-nf-call-iptables 0
network:
ethernets:
enp2s0f0:
dhcp4: no
bridges:
br0:
interfaces:
- enp2s0f0
dhcp4: no
addresses:
- 192.168.1.100/24
nameservers:
addresses:
- 192.168.1.1
search: []
routes:
- to: default
via: 192.168.1.1
version: 2
$ cat br0.xml <network> <name>host-bridge</name> <forward mode="bridge"/> <bridge name="br0"/> </network> $ sudo virsh net-define br0.xml Network host-bridge defined from br0.xml $ sudo cat /etc/libvirt/qemu/networks/host-bridge.xml <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh net-edit host-bridge or other application using the libvirt API. --> <network> <name>host-bridge</name> <uuid>c8b61fe1-7602-3028-15f3-2954207391fa</uuid> <forward mode='bridge'/> <bridge name='br0'/> </network> $ sudo virsh net-list --all Name State Autostart Persistent -------------------------------------------------- default active yes yes host-bridge inactive no yes
$ sudo virsh net-start host-bridge Network host-bridge started $ sudo virsh net-autostart host-bridge Network host-bridge marked as autostarted $ sudo virsh net-list --all Name State Autostart Persistent ------------------------------------------------ default active yes yes host-bridge active yes yes
以上で、xen の dom-0 にあたる部分の設定が完了。
-----2020年9月にクラウドファンディングで手に入れた天体望遠鏡 eVscope が届いてから、天体観測が面白すぎてプログラムコードにほとんど触れていなかった。2年ぶりの運用まとめ。
dolphin=# select count(*) from d_patient; count ------- 38302 (1 row)
dolphin=# select count(*) from d_module; count --------- 1542061 (1 row)
Filesystem Size Used Avail Use% Mounted on udev 961M 0 961M 0% /dev tmpfs 199M 464K 199M 1% /run /dev/xvda1 46G 23G 21G 53% / tmpfs 993M 16K 993M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 993M 0 993M 0% /sys/fs/cgroup tmpfs 199M 0 199M 0% /run/user/1001
Filesystem Size Used Avail Use% Mounted on udev 3.0G 0 3.0G 0% /dev tmpfs 606M 1.2M 605M 1% /run /dev/xvda1 46G 20G 24G 46% / tmpfs 3.0G 16K 3.0G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.0G 0 3.0G 0% /sys/fs/cgroup ：
dolphin_db.dump.gpg 2,908,582,533 orca_db.dump.gpg 330,190,797
$ grep -c stampInfo stamp.xml 2168
Java 17 への完全移行が完了し、これで来るべき apple silicon 時代にも対応できるようになったと思う。
Hibernate 6 でデフォルトのプライマリキー採番方法が変更になって、hibernate_sequence からではなく、テーブル名_seq から採番するようになった。これまでの採番方式を維持するためには、persistent.xml に以下のように記載しなくてはならない。
<property name="hibernate.id.db_structure_naming_strategy" value="single" />
今回、これに気付かずに運用開始してやらかしてしまった。Hibernate 5 の時はテスト段階で警告が出てくれたので、hibernate.model.generator_name_as_sequence_name=false をセットして事なきを得たが、今回は警告も出ないし、テストでエラーも出なかったので、完全に油断していた。
木曜日から運用開始して、金曜日まで問題なし。そして土曜日、診療開始してしばらくしてからエラーが出るようになった。
2023-01-28 09:04:22,093 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-80) SQL Error: 0, SQLState: 23505 2023-01-28 09:04:22,093 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-80) ERROR: duplicate key value violates unique constraint "d_module_pkey" 詳細: Key (id)=(1070) already exists.
土曜日は患者さん多く、すぐに対応するのは不可能。全身から血の気が引いたが、何回か再送すると動くので、頑張って運用を続けた。再送2−3回で送らさったのが多かったが、最高10回再送でやっと通ったのもあった。そして、幸運にも何とか外来終了することができて、最後のカルテが保存できた時は、本当にほっとして力が抜けた。
トラブルの原因となったプライマリーキーの件は、土曜外来終了後に web 検索して判明した。多分、プライマリーキーの若い番号は ModuleModel には割当たってなかったので、最初の1000番くらいは空きがあったのだろう。それを食い尽くして、何とか隙間にねじ込むしかなくなったのが土曜日だったのだと思われる。次回はちゃんとマイグレーションマニュアル読もうと誓った週末であった。
ちなみに、Hibernate 6 の新しいデフォルトの採番は、テーブルごとにインクリメントしていくので、効率的に採番できてよい方法だと思う。当院のように hibernate_sequence を single で使ってしまっていると、bigint なので最大
public class JapaneseAnalysisConfigurer implements ElasticsearchAnalysisConfigurer {
@Override
public void configure(ElasticsearchAnalysisConfigurationContext context) {
context.analyzer("japanese").custom()
.tokenizer("kuromoji_tokenizer")
.charFilters("icu_normalizer", "kuromoji_iteration_mark")
.tokenFilters("kuromoji_baseform", "kuromoji_part_of_speech", "ja_stop", "kuromoji_number", "kuromoji_stemmer");
}
}
@Transient
@FullTextField(analyzer = "japanese") // hibernate search
private String fullText;
public void setBeanBytes(byte[] beanBytes) {
this.beanBytes = beanBytes;
// FullTextField を Index させるためのでっちあげ
if (Objects.nonNull(beanBytes)) { setFullText(beanBytesToString(beanBytes)); }
}
<property name="hibernate.search.backend.type" value="elasticsearch"/> <property name="hibernate.search.backend.hosts" value="localhost:9200"/> <property name="hibernate.search.backend.protocol" value="http"/> <property name="hibernate.search.backend.analysis.configurer" value="class:open.dolphin.JapaneseAnalysisConfigurer" />
新しい hibernate search では、検索方法も詳しく選べるようになっていて、通常の検索では phrase() サーチを採用し、simpleQueryString() サーチ、regexp() サーチもオプションできるようにプログラムした。
Listhits = searchSession.search(DocumentModel.class) .where(f -> f.bool(b -> { b.must(switch (spec.getType()) { case QUERY -> f.simpleQueryString().field("modules.fullText").matching(searchText); case REGEXP -> f.regexp().field("modules.fullText").matching(searchText); default -> f.phrase().field("modules.fullText").matching(searchText); }); ：
MassIndexer でインデックス条件を指定できるようになったので、STATUS_FINAL の DocumentModel だけインデックスするようにした。インデックス件数が 313,845件から 203,149件に減った。というか、今までは MassIndexer した分は、更新元の古いカルテも全部インデックスされてたということになる。
MassIndexer massIndexer = searchSession.massIndexer();
massIndexer.type(DocumentModel.class).reindexOnly("e.status = :status").param("status", IInfoModel.STATUS_FINAL);
なお、ここの e.status ... の前のハードコードされてる sql が jpa compliance に反しているらしく exception を吐く。persistent.xml で hibernate.jpa.compliance.query = false の設定が必要。
MassIndexer のインデックススピードを比較してみたところ、現在使用中の i9-9900 の dolphin サーバで 14.5 doc/sec だったのに対して、こないだ購入した m1 max の mac studio では 41.3 doc/sec だった。例えば OpenSearch を強いマシンで動かして、それを dolphin サーバから利用するようにすると、インデックススピードの改善が期待できる。しないけど。
OpenSearch が立ち上がってから WildFly を立ち上げる必要がある。お前が使っているのは Elasticsearch じゃないぞと怒られるが気にしない。
OpenSearch が立ち上がった時のメッセージ
[INFO ][o.o.c.m.MetadataCreateIndexService] [dolphin.local] [document-000001] creating index, cause [api], templates [], shards [1]/[1]
WildFly に怒られるところ
WARN [org.hibernate.search.backend.elasticsearch.dialect.impl.ElasticsearchDialectFactory] (MSC service thread 1-7) HSEARCH400085: Unknown Elast icsearch version running on the cluster: 'opensearch:2.4.1'. Hibernate Search may not work correctly. Consider updating to a newer version of Hibernate Search, if any.
$ curl 'http://localhost:9200/_aliases?pretty'
{
"document-000001" : {
"aliases" : {
"document-read" : {
"is_write_index" : false
},
"document-write" : {
"is_write_index" : true
}
}
}
}
$ curl -X POST 'localhost:9200/document-000001/_analyze?pretty' -H "Content-type: application/json" -d '{"analyzer": "kuromoji", "text": "カルテ記載のテスト"}'
{
"tokens" : [
{
"token" : "カルテ",
"start_offset" : 0,
"end_offset" : 3,
"type" : "word",
"position" : 0
},
{
"token" : "記載",
"start_offset" : 3,
"end_offset" : 5,
"type" : "word",
"position" : 1
},
{
"token" : "テスト",
"start_offset" : 6,
"end_offset" : 9,
"type" : "word",
"position" : 3
}
]
}
$ curl 'http://localhost:9200/document-000001/_search?pretty'
$ curl -X DELETE 'http://localhost:9200/document-000001?pretty'
{
"acknowledged" : true
}
$ sudo aptitude install openjdk-17-jre $ sudo update-alternatives --config java alternative java (/usr/bin/java を提供) には 3 個の選択肢があります。 選択肢 パス 優先度 状態 ------------------------------------------------------------ 0 /usr/lib/jvm/java-17-openjdk-amd64/bin/java 1711 自動モード 1 /usr/lib/jvm/java-17-openjdk-amd64/bin/java 1711 手動モード * 2 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081 手動モード 3 /usr/lib/jvm/java-8-oracle/jre/bin/java 1081 手動モード 現在の選択 [*] を保持するには、さもなければ選択肢の番号のキーを押してください: 0 update-alternatives: /usr/bin/java (java) を提供するために自動モードで /usr/lib/jvm/java-17-openjdk-amd64/bin/java を使います $ java -version openjdk version "17.0.5" 2022-10-18 OpenJDK Runtime Environment (build 17.0.5+8-Ubuntu-2ubuntu118.04) OpenJDK 64-Bit Server VM (build 17.0.5+8-Ubuntu-2ubuntu118.04, mixed mode, sharing)
$ cat /proc/sys/vm/max_map_count 65530 $ sudo vi /etc/sysctl.conf vm.max_map_count=262144 $ sudo sysctl -p vm.max_map_count = 262144
$ tar xvzf opensearch-2.4.1-linux-x64.tar.gz opensearch-2.4.1/ opensearch-2.4.1/LICENSE.txt opensearch-2.4.1/NOTICE.txt ： $ ln -s opensearch-2.4.1 opensearch
$ cd opensearch $ rm -rf plugins/*
$ vi ./config/opensearch.yml cluster.name: opensearch_dolphin path.data: /home/dolphin/opensearch/var/lib/opensearch path.log: /home/dolphin/opensearch/var/log/opensearch $ ./bin/opensearch WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by org.opensearch.bootstrap.OpenSearch (file:/home/dolphin/opensearch-2.4.1/lib/opensearch-2.4.1.jar) ：
$ ./bin/opensearch-plugin install analysis-kuromoji $ ./bin/opensearch-plugin install analysis-icu
$ cd ./opensearch/var/lib/opensearch $ tar cvzf opensearch-nodes.tgz nodes
