OpenDolphin日記

owncloud を 10.9.0 にアップグレードしたところ、php 7.2 がサポートされなくなったというメッセージがでて、アクセスできなかった。php 7.4 をインストールして、設定しなおした。

• 必要な php モジュールをインストールする

  $ sudo aptitude install php7.4 php7.4-xml php7.4-intl php7.4-gd php7.4-curl php7.4-zip php7.4-mbstring
  

• apache2 再起動

  $ sudo a2dismod php7.2
  $ sudo a2enmod php7.4
  $ sudo service apache2 restart
  

xen domU で運用している自宅サーバの owncloud を ubuntu 18.04 にアップグレードした。これで全ての xenial を bionic にアップグレード完了。

1. 準備ˀ

   $ sudo aptitude update
   $ sudo aptitude upgrade
   $ sudo apt-get autoremove
   

2. postgres のデータベースをバックアップ

   $ pg_dump -Fc owncloud > owncloud.dump
   

3. owncloud を削除する

   $ sudo aptitude purge owncloud-files
   $ sudo rm -rf /var/www/owncloud/apps
   $ sudo rm -rf /var/www/owncloud/config
   $ sudo rm /etc/apt/sources.list.d/owncloud.list
   

4. postgres を削除する

   $ sudo aptitude purge postgresql-9.5 postgresql-client-9.5
   

5. do-release-upgrade

   $ sudo do-release-upgrade
   　：
   システムのアップグレードが完了しました。
   'Y' を選択すると再起動します。
   続行する[yN]
   

6. postgresql-10 のインストール

   $ sudo aptitude install postgresql
   

7. postgresql の設定

   $ sudo vi /etc/postgresql/10/main/postgresql.conf
   listen_addresses = '*'
   
   $ sudo vi /etc/postgresql/10/main/pg_hba.conf
   # IPv4 local connections:
   host    all             all             127.0.0.1/32            trust
   # IPv6 local connections:
   host    all             all             ::1/128                 trust
   

8. 古いまま残っている php モジュールを探して 7.2 にバージョンアップ

   $ aptitude search php | grep -e '^i'
   $ sudo aptitude install php-pgsql php-curl php-readline
   

9. php を a2enmod

   $ sudo a2enmod php7.2
   $ sudo systemctl reload apache2
   

10. データベースを dump から戻す

    $ sudo -i
    # su - postgres
    $ psql 
    postgres=# CREATE USER a_user WITH PASSWORD 'a_passwd';
    postgres=# CREATE DATABASE owncloud TEMPLATE template0 ENCODING 'UNICODE';
    postgres=# ALTER DATABASE owncloud OWNER TO a_user;
    postgres=# GRANT ALL PRIVILEGES ON DATABASE owncloud TO a_user;
    postgres=# \q
    $ pg_restore -Fc -d owncloud owncloud.dump
    

11. owncloud のレポジトリを設定する

    $ curl https://download.owncloud.org/download/repositories/production/Ubuntu_18.04/Release.key | sudo apt-key add -
    $ sudo sh -c "echo 'deb http://download.owncloud.org/download/repositories/production/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/owncloud.list"
    

12. owncloud のインストール

    $ sudo aptitude update
    $ sudo aptitude install owncloud-files
    $ sudo systemctrl reload apache2
    

13. config.php に memcache.local の設定

    'memcache.local' => '\OC\Memcache\APCu',
    

14. cron の設定

    $ sudo -u www-data sh -c "echo '7,22,37,52 * * * * php occ system:cron > /dev/null 2>&1' | crontab"
    

15. あとは，ブラウザからアクセスして，「アップデートを開始」をクリック。無事 ubuntu 18.04 + owncloud 10.3.1 にアップデートされた。

サーバの xen dom0 を ubuntu 18.04 にアップグレードした。16.04 の時と同じように do-release-upgrade した。

1. 準備と do-release-upgrade

   $ sudo aptitude update ; sudo aptitude upgrade
   $ sudo apt-get autoremove
   $ sudo do-release-upgrade
   　：
   アップグレードを開始しますか？
   3 個のインストール済みパッケージは Canonical によってサポートされなくなりました。ただしコミュニティからのサポートは受けることができます。
   6 個のパッケージが削除されます。 204 個の新規パッケージがインストールされます。 518 個のパッケージがアップグレードされます。
   合計 384 M をダウンロードする必要があります。 このダウンロードは約 3 分 かかります。
   アップグレードをインストールするのに数時間かかることがあります。ダウンロードが完了してしまうと、処理はキャンセルできません。
   続行する[yN]  詳細 [d]y
   　：
   アップグレードを完了するには再起動が必要です。
   'Y' を選択すると再起動します。
   続行する[yN] y
   

2. 再起動後に uname でカーネルを確認

   $ uname -r
   4.15.0-70-generic
   

   /etc/default/grub.d/xen.cfg を見ると，XEN_OVERRIDE_GRUB_DEFAULT=1 を設定しなくても xen でブートされるようになっていた

3. 起動時に Running /scripts/local-premount で 30秒間固まってしまう /etc/initramfs-tools/conf.d/resume のバグの workaround
   RESUME=UUID=xxxx を RESUME=noneに 書き換えて sudo update-initramfs -u する。

   $ cat /etc/initramfs-tools/conf.d/resume
   RESUME=none
   $ sudo update-initramfs -u
   

新しいサーバで速度比較してみた。新サーバ爆速。

CPU	i9-9900@3.6 NVMe	i7-3770@3.4 SSD	C2D E4500@2.2 SSD
大量カルテ読み込み	6.7秒	10.5秒	-
dolphin サーバのデータベースダンプ	4分22秒	10分36秒	-
orca レセプトチェック	43秒	1分57秒	2分53秒
orca レセプト作成	1分46秒	4分13秒	5分21秒

新サーバが速いのは NVMe の力がかなり大きいと思われる。技術の進歩に驚かされる。

左:HDD (3.5" - 320G)，右上:SSD (2.5" - 500G)，右下:NVMe (m.2 - 500G)

前回サーバの CPU を i7-3770K に更新してから既に6年以上経っていたことに気付いてしまい，気付いた以上仕方がないので 6年ぶりに CPU をアップグレードすることにした。今回 CPU は大分安くなってきた i9-9900K@3.6GHz，マザーボードは ASRock Z390M Pro4 (安心な日本語説明入り) を買ってきた。そして，前回と同じくそのままではネットワークが使えないことが判明した。orz

マザーボードの ether チップ (I219-V) が ubuntu 16.04 の e1000e ドライバ 3.2.6 だと対応していないのが原因で，最新の 3.4.2.1 に更新すると使えるようになる。前回の時もドライバ更新して対応はできたのだが，カーネルのアップグレードの度にドライバをコンパイルして更新するという面倒くさいことになってしまったため，on board LAN をあきらめてネットワークカードを買ってきたという経緯があった。

しかし，今回 web 検索で DKMS (Dynamic Kernel Module Support) なる機能を発見した。これを使うと，カーネルのアップグレードの際に自動的にドライバをコンパイルして更新してくれるようになる。

• I219-V のドライバのソースをダウンロード。
• 動いている ubunbu マシンで，インストーラのカーネルバージョンに合わせて make し，e1000e.ko を作る。

  $ LANG=C BUILD_KERNEL=4.4.0-142-generic make
  

• インストーラでインストール開始。なお，UNetbootin だと CD-ROM 検出のところでエラーが出て進めなくなってしまう。
  
• 言語選択画面でおもむろに option-F2 を押してコンソールに入る。
• e1000e.ko を入れた USB をマウントしてドライバをロードする。ptp が依存しているので先に modprobe する必要あり。(modinfo e1000e.ko | grep ^depends で確認)

  # modprobe ptp
  # insmod /mnt/e1000e-3.4.2.1/src/e1000e.ko
  # umount /mnt
  

• option-F1 でインストーラに戻ってインストールを続ける。

インストール完了後，恒常的に e1000e ドライバが読み込まれるように設定する。

• ドライバを home directory に持ってくる。
• build-essential が必要なので，とりあえずつながるようにしてからインストールする。

  $ sudo modprobe ptp
  $ sudo insmod ~/e1000e-3.4.2.1/src/e1000e.ko
  $ sudo apt-get build-essential
  

• インストール完了したらさっきのは削除。

  $ sudo rmmod e1000e
  

• ドライバをインストールする。

  $ cd ~/e1000e-3.4.2.1/src
  $ make
  $ sudo make install
  

• インストールされたので，modprobe でドライバが有効になる。

  $ sudo modprobe e1000e
  

• バージョン確認。

  $ sudo modinfo e1000e
  filename:       /lib/modules/4.4.0-142-generic/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
  version:        3.4.2.1-NAPI
  　：
  

dkms でカーネルアップグレード後に自動的にドライバがインストールされるようにする。

• dkms をインストール，/usr/src にドライバのソースをコピーする。

  $ sudo apt-get install dkms
  $ sudo cp -r ~/e1000e-3.4.2.1 /usr/src/
  

• /usr/src/e1000e3.4.2.1/dkms.conf の作成。/lib/modules/${kernelver}/updates/dkms/ にドライバがセットされる。

  PACKAGE_NAME="e1000e"
  PACKAGE_VERSION="3.4.2.1"
  BUILT_MODULE_LOCATION=src
  BUILT_MODULE_NAME[0]="e1000e"
  DEST_MODULE_LOCATION[0]="/updates"
  AUTOINSTALL="yes"
  MAKE[0]="BUILD_KERNEL=${kernelver} make -C src CFLAGS_EXTRA=-DDISABLE_PM"
  CLEAN[0]="make -C src clean"
  REMAKE_INITRD=yes
  

• ドライバを dkms に登録，ビルド，インストールする手順。

  $ sudo dkms -m e1000e -v 3.4.2.1 add 
  $ sudo dkms -m e1000e -v 3.4.2.1 build 
  $ sudo dkms -m e1000e -v 3.4.2.1 install 
  

xen のインストール

• xen-hypervisor-amd64 のインストールで bridge-utils，xen-utils もインストールされる。

  $ sudo aptitude install xen-hypervisor-amd64
  

• balooning の設定。

domU で運用している自宅サーバの owncloud を ubuntu 16.04 にアップグレードした。

1. autoremove

   $ sudo apt-get autoremove
   

2. postgres のデータベースをバックアップ

   $ pg_dump -Fc owncloud > owncloud.dump
   

3. owncloud を削除する

   $ sudo aptitude purge owncloud
   $ sudo rm /etc/apt/sources.list.d/owncloud.list
   

4. do-release-upgrade

   $ sudo do-release-upgrade
   　：
   設定ファイル '/etc/apache2/sites-available/default-ssl.conf'
    ==> これはインストールしてから (あなたかスクリプトによって) 変更されています。
    ==> パッケージ配布元が更新版を提供しています。どうしますか? 
   → N
   　：
   廃止されたメジャーバージョン 9.3
   既存のクラスタがアップグレードされた後に、postgresql-9.3 および postgresql-client-9.3 パッケージを削除する必要があります。
   → <了解>
   　：
   設定ファイル /etc/postgresql-common/createcluster.conf の新しいバージョン(/tmp/postgresql-common.4RBMXy) が利用可能ですが、現在インストールされているバージョンは、ローカルで変更されています。変更された設定ファイル createcluster.conf について何を行いたいですか? 
   → パッケージメンテナのバージョンをインストール
   　：
   システムのアップグレードが完了しました。
   'Y' を選択すると再起動します。
   続行する[yN]
   

5. postgresql-9.3 の削除と 9.5 のインストール

   $ sudo purge postgresql-9.3 postgresql-client-9.3
   $ sudo aptitude install postgresql
   

6. postgresql の設定

   $ sudo vi /etc/postgresql/9.5/main/postgresql.conf
   listen_addresses = '*'　←コメントを解除し、''内を * に修正
   
   $ sudo vi /etc/postgresql/9.5/main/pg_hba.conf
   # IPv4 local connections:
   host    all             all             127.0.0.1/32            trust
   # IPv6 local connections:
   host    all             all             ::1/128                 trust
   

7. カーネルアップグレード，再起動

   $ sudo apt-get install linux-generic
   

8. データベースを dump から戻す

   $ sudo -i
   # su - postgres
   $ psql 
   postgres=# CREATE USER a_user WITH PASSWORD 'a_passwd';
   postgres=# CREATE DATABASE owncloud TEMPLATE template0 ENCODING 'UNICODE';
   postgres=# ALTER DATABASE owncloud OWNER TO a_user;
   postgres=# GRANT ALL PRIVILEGES ON DATABASE owncloud TO a_user;
   postgres=# \q
   $ pg_restore -d owncloud owncloud.dump
   

9. owncloud のレポジトリを設定する

   $ curl https://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/Release.key | sudo apt-key add -
   # echo 'deb http://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/ /' > /etc/apt/sources.list.d/owncloud.list
   

10. owncloud のインストール

    $ sud aptitude update
    $ sudo aptitude install owncloud-files
    

11. maintenance モードに設定

    $ sudo vi /var/www/owncloud/config/config.php
     'maintenance' => true,
    

12. php のインストール

    $ sudo aptitude install php php7.0-pgsql php-bz2 php-curl php-gd php-imagick php-intl php-mbstring php-xml php-zip libapache2-mod-php
    

13. owncloud.conf の有効化と apache2 のリロード

    $ sudo a2enconf owncloud
    $ sudo service apache2 reload
    

14. maintenance モードを解除

    $ sudo vi /var/www/owncloud/config/config.php
     'maintenance' => false,
    

15. あとは，ブラウザからアクセスして，「アップデートを開始」をクリック。無事 ubuntu 16.04 + owncloud 10.0.4 にアップデートされた。

サーバの dom0 を ubuntu 16.04 にアップグレードした。14.04 の時と同じように do-release-upgrade した。efi インストール (mac mini) も試してみたが，xen をインストールすると起動途中で固まってしまい，断念した。

$ sudo apt-get autoremove
$ sudo do-release-upgrade
　：
SSH経由で実行していますが、続けますか？
続行する[yN] y
　：
アップグレードを開始しますか？
続行する[yN]  詳細 [d] y
　：
システムのアップグレードが完了しました。
再起動が必要です
アップグレードを完了するには再起動が必要です。
'Y' を選択すると再起動します。
続行する[yN] y

再起動後に uname でカーネルを確認してみると

$ uname -r
3.13.0-137-generic

なぜかカーネルが古いままになっていた。そこで，

$ sudo apt-get install linux-generic

これでカーネルも最新バージョンになった。

$ uname -r
4.4.0-109-generic

xen の balooning を止める設定
/etc/defaults/grub

GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=512M,max:512M"

/etc/xen/xl.conf

autoballoon=0

しかる後に update-grub と reboot

勢いで，サーバを ubuntu 12.04 から 14.04 にアップグレードした。

不要なカーネルの削除

アップデート前に，たまった不要なカーネルを削除する。アップグレードの度にきちんと削除していればよかったのだが，めんどくさいのでそのままにしていたら，結構な数の古いカーネルが /boot にたまってしまっていた。 apt-get autoremove をすると初代と最新２つを残して，不要なカーネルを削除してくれる。

$ sudo apt-get autoremove

この時，1つカーネルを削除する毎に，update-grub 処理が入るので，その度に mac os x や xen domU が入っている全てのパーティションをスキャンしに行って，ものすごい時間がかかってしまった。これを避けるには /etc/default/grub に

GRUB_DISABLE_OS_PROBER="true" 

を追加するとよい。

アップデート方法

最近の OS 起動は，MBR ではなく GPT （GUID Partition Table）+ UEFI (unified extensible firmware interface) というシステムに変わってきているらしく，ubuntu 14.04 は新規インストールだと UEFI ブートでインストールすることができる。自宅サーバの mac mini (mid 2011) は UEFI の起動パーティションを持っており，UEFI ブートに対応できる。

$ sudo mount -t msdos /dev/sda1 /mnt
$ ls -l /mnt/efi
合計 1
drwxr-xr-x 4 root root 512  7月  9  2011 apple/

試しに ubuntu 14.04 を新規インストールしてみたら，確かに rEFIt を使わなくてもそのまま ubuntu を起動することができた。しかし，Xen をインストールしたところ，ACPI BIOS Error というのが出て，CPU のコアが 1つしか認識されなかったり，USB が使えなかったりした。

[    0.000000] ACPI BIOS Error (bug): A valid RSDP was not found (20140424/tbxfroot-211)

$ lsusb
unable to initialize libusb: -99

どうやら，ubuntu 14.04 では Xen の UEFI ブートはまだちゃんとサポートされていないらしい (Upstream Linux Kernel will have Xen dom0 EFI support from 3.17-rc1)。当面はMBR 起動で使うことにして， do-release-upgrade でアップグレードすることにした。

$ sudo do-release-upgrade
　　：
SSH経由で実行していますが、続けますか？ ...
続行する[yN] y
　　：
予備のsshdを開始します...
続けるには [ENTER] キーを押してください
　　：
アップグレードを開始しますか？...
続行する[yN]  詳細 [d] y
　　：
Configuring libc6...
Restart services during package upgrades without asking?
<Yes>
　　：
変更された設定ファイル...
設定ファイル /etc/default/xen の新しいバージョンが利用可能ですが、現在インストールされているバージョンは、ローカルで変更されています。 
パッケージメンテナのバージョンをインストール                                
　　：
grub-pc を設定しています ...
現在インストールされているローカルバージョンを保持
(GRUB_DISABLE_OS_PROBER の設定の違いのみなので「ローカルバージョンを保持」)
　　：
サポートが中止された（あるいはリポジトリに存在しない）パッケージを削除しますか？
 続行する[yN]  詳細 [d] y
　　：
システムのアップグレードが完了しました。
再起動が必要です

無事アップグレードされた

$ uname -a
Linux ubuntu 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

xen の変わったところ

• xm コマンドが xl コマンドに変わった。

  $ sudo xl list
  Name                                        ID   Mem VCPUs	State	Time(s)
  Domain-0                                     0  7878     8     r-----     120.6
  

• これまでは /etc/grub.d の番号を変えて xen を優先起動していたが /etc/default/grub.d/xen.cfg で xen の優先起動ができるようになった。

  XEN_OVERRIDE_GRUB_DEFAULT=1
  

• cfg ファイルの disk の書き方が変わった。
• /etc/xen/auto に cfg ファイルのリンクを入れておくと，dom0 起動時に一緒に起動するようになった。

これまで自宅サーバーを WebDAV で運用していたが，クラウド時代に合わせて，ownCloud を導入してみた。

　

サーバ設定 (ubuntu 12.04 にインストール)

1. apt-line の追加

   deb http://download.opensuse.org/repositories/isv:ownCloud:community/xUbuntu_12.04/ /
   

2. keyring の追加

   $ wget http://download.opensuse.org/repositories/isv:ownCloud:community/xUbuntu_12.04/Release.key
   $ sudo apt-key add Release.key
   

3. インストール：データベースはデフォルトで sqlite3 を使うようになっているが，何だか遅いので，使い慣れた postgres を使うことにする

   $ sudo aptitude update
   $ sudo aptitude install postgresql
   $ sudo aptitude install php5-pgsql
   $ sudo aptitude install owncloud 
   

4. インストールしたバージョン

   $ aptitude show owncloud
   パッケージ: owncloud
   バージョン: 5.0.11-0
   

5. ssl 設定

   $ sudo a2enmod
   　：
   Which module(s) do you want to enable (wildcards ok)? 
   ssl
   
   $ sudo a2ensite
   Your choices are: default default-ssl
   Which site(s) do you want to enable (wildcards ok)?
   default-ssl
   

6. /etc/apache2/sites-enabled/ssl-default を編集，オレオレ証明書を設定

   SSLCertificateFile    /etc/ssl/certs/server.pem
   SSLCertificateKeyFile /etc/ssl/private/server.key
   SSLCACertificateFile  /etc/ssl/cacert.pem
   

7. /etc/apache2/conf.d/owncloud.conf でアクセス制限

   <Directory /var/www/owncloud/>
     Order deny,allow
     deny from all
     allow from 192.168.1.0/24
     allow from xxx
   </Directory>
   

8. cron の設定：キューに積まれた job を一定時間毎に実行する必要があるらしい

   $ sudo crontab -l
   # owncloud: execute cron.php every one minute
   *          *  *   *   *   php -f /var/www/owncloud/cron.php > /dev/null 2>&1
   

9. データベース作成

   $ sudo -i
   # su - postgres
   $ psql 
   postgres=# CREATE USER username WITH PASSWORD 'password';
   postgres=# CREATE DATABASE owncloud TEMPLATE template0 ENCODING 'UNICODE';
   postgres=# ALTER DATABASE owncloud OWNER TO username;
   postgres=# GRANT ALL PRIVILEGES ON DATABASE owncloud TO username;
   postgres=# \q
   

10. /etc/postgresql/9.1/main/postgresql.conf で fsync = off に設定：信頼性より速度優先

    fsync = off     # turns forced synchronization on or off
    

    $ sudo service postgresql restart
    

11. apache2 リスタート

    $ sudo service apache2 restart
    

12. あとは，https://server-address/owncloud にアクセスするとブラウザで設定ができる。
    • 「ユーザー名」と「パスワード」を入れて，「詳細設定」をクリック，データベースとして postgres を選択して，データベース情報を入力する。
    • 「管理者」メニューから「常に HTTPS を使用する」と「Cron」の設定をする。
13. この時点で WebDAV サーバが立ち上がっており，Mac OS X から ⌘-K で マウントすることができる。

    https://user_id@host-address/owncloud/remote.php/webdav
    

クライアントソフト

ownCloud クライアントソフトを導入すると，ローカルの ~/ownCloud フォルダに対して行った変更が，バックグランドで自動的にサーバと同期されるようになる。

1. web 画面の右上の IDメニューから，「個人」を選択すると，「Get the apps to sync your files」が出るので，そこからクライアントがダウンロードできる。
2. 起動するとメニューバーにアイコンが出る。
3. 初期設定ファイルは「~/Library/Application Support/ownCloud」に入る。

ファイルの同期

自宅の WebDAV サーバで管理しているデータ量は，ファイル数 262,767（容量 17.2 GB） あった。最初これを全部クライアントソフトで管理しようとしたが，更新検出のための１回のスキャンだけで，ローカルで 〜200 sec，リモートで 〜2,700 sec（45分）かかってしまった。これでは，更新検出のためだけに１日中コンピューターが回り続けることになってしまい実用的ではない。そこで，active に使う 1,709 ファイル（容量 406 MB）を選んで，これをクライアントで管理し，その他はこれまで通り WebDAV で管理することにした。

1. サーバにユーザーを２つ作る。１つはクライアント同期用，もう１つは WebDav アクセス用。
2. サーバの /var/www/owncloud/data/user_id/files にそれぞれデータを持っていく。
3. サーバに認識させるために，スキャンする。完了まで 23分かかった。

   # cd /var/www/owncloud
   # php console.php files:scan --all
   

4. クライアントに，同期用のデータと同じものをコピーして持っていって，~/ownCloud に入れる。
5. ownCloud client を立ち上げて，必要な情報を入力する。完了すると同期が始まるが，動作が安定するまでは，バックグランドで何しているか分かるように，作業内容をログに書き出す設定にするとよい。

   $ /Applications/owncloud/Contents/MacOS/owncloud --logfile /path/to/LOGFILE &
   $ tail -f /path/to/LOG FILE
   

6. 最初，.scync_journal.db を作るためのスキャンで少し時間がかかるが，それができてしまえば，その後は更新確認のためのスキャンは１回１秒以下で終了するようになった。

使用感

Mac OS X では，マウントした WebDAV 内のファイルを直接編集できるのだが，編集後の保存に結構時間がかかるので，動作がもっさりしていた。ownCloud のクライアントを使うと，保存は一瞬で，あとはバックグランドでサーバと同期してくれるので，もっさりが解消された。

サーバの CPU を i7 にアップグレードしたが，この CPU は 4コア＋HT で，8 個の CPU として認識される。

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
　：
processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
　：
　：
processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
　：

このあり余る CPU を dolphin サーバ，orca サーバにどう割り当てたらよいか実験してみた。

CPU数 時間 1 11.3秒 2 6.4秒 4 5.1秒 8 5.1秒

dolphin サーバの JBoss 起動時間 JBoss 起動時間は CPU 数を増やす毎に速くなった。 JBoss  の起動プロセスは，複数の CPU を上手に利用するようになっているようだ。

CPU数 時間 1 9.1秒 2 8.6秒 4 8.8秒 8 8.9秒

大量カルテ読み込み時間 カルテ読み込み時間は CPU 数には無関係だった。 複数 CPU を生かすようなプログラミングってできるんだろうか。

CPU数 時間 1 1分40秒 4 1分41秒 8 1分42秒

orca サーバでレセプト作成 orca のレセプト作成も CPU 数は関係ないようであった。

当院業務では CPU 数による大きな差はないようだった。
とりあえず，dolphin サーバ，orca サーバとも CPU ４個で動かすことにした。

結論：この CPU は当院業務には明らかにオーバースペックである。