サーバ

2019年5月31日 (金)

ベンチマーク

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

CPUi9-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)

Img_0555

2019年5月30日 (木)

サーバの CPU アップグレード

Img_0540 前回サーバの 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 検出のところでエラーが出て進めなくなってしまう。
    Img_0445
  • 言語選択画面でおもむろに 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 の設定

2018年1月12日 (金)

domU の owncloud サーバを ubuntu 16.04 にアップグレード

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 にアップデートされた。

2018年1月11日 (木)

サーバの dom0 を ubuntu 16.04 にアップグレード

サーバの 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

2015年4月15日 (水)

サーバの dom0 を ubuntu 14.04 にアップグレード

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

不要なカーネルの削除

アップデート前に,たまった不要なカーネルを削除する。アップグレードの度にきちんと削除していればよかったのだが,めんどくさいのでそのままにしていたら,結構な数の古いカーネルが /boot にたまってしまっていた。 apt-get autoremove をすると初代と最新2つを残して,不要なカーネルを削除してくれる。
$ 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 起動時に一緒に起動するようになった。

2013年10月 1日 (火)

ownCloud 導入

これまで自宅サーバーを 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) あった。最初これを全部クライアントソフトで管理しようとしたが,更新検出のための1回のスキャンだけで,ローカルで 〜200 sec,リモートで 〜2,700 sec(45分)かかってしまった。これでは,更新検出のためだけに1日中コンピューターが回り続けることになってしまい実用的ではない。そこで,active に使う 1,709 ファイル(容量 406 MB)を選んで,これをクライアントで管理し,その他はこれまで通り WebDAV で管理することにした。
  1. サーバにユーザーを2つ作る。1つはクライアント同期用,もう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 を作るためのスキャンで少し時間がかかるが,それができてしまえば,その後は更新確認のためのスキャンは1回1秒以下で終了するようになった。

使用感

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

2013年4月 4日 (木)

CPU 数割り当て

サーバの 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 4個で動かすことにした。

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

2013年3月29日 (金)

ネットワークカード購入

CPU をアップグレードして性能はアップしたのであるが,on board LAN (Realtek 8168) のドライバで,めんどくさいことになってしまっていた。結局,ネットワークカードを別に購入して対応することにした。購入したカードは「インテル Gigabit CT Desktop Adapter EXPI9301CT」というもの。lspci によると 82574L というチップらしい。

  1. on board LAN を使うために設定した内容を,すべて元に戻す。
  2. ネットワークカードを装着。
  3. BIOS で on board LAN を disable する。
  4. 起動。

何も設定しなくても ether がつかえるようになった。安いマザーボードを選んだばっかりに「安物買いの・・」になってしまったが,ネットワークカードは今後マザーボードを変えてもずっと使えるだろうからよしとする。

2013年3月27日 (水)

ベンチマーク

新しいサーバで速度比較してみた。i7-3770 激速。

CPUi7-3770@3.4
SSD
C2D E7200@2.53
SSD
C2D E4500@2.2
HD
大量カルテ読み込み6.8秒9.1秒-
dolphin サーバのデータベースダンプ3分43秒6分9秒-
orca データチェック27秒49秒1分16秒
orca レセプト作成1分17秒2分14秒2分51秒

orca も 4.6 より,4.7 の方が速くなっているようだ。

2013年3月26日 (火)

サーバの CPU アップグレード

CPU(Core i7-3770 @3.40G) とマザーボード(ASUS P8B75-M)を買ってきて,サーバマシンをアップグレードした。マザーボードは一番安いものを買ってきたのであるが,そのままでは ether が使えないことが判明した。調べてみたら web に ubuntu 関連のトラブル報告がたくさん上がっており,事前によく調べておけばよかったと後悔した。

 P8B75-M の ether チップは,realtek RTL8111/8168B というものであるが,ubuntu で用意されている r8169 というドライバが対応しておらず,メーカーからドライバをダウンロードして,自分でコンパイルする必要がある。

  1. 使えない r8169 をブラックリストに登録する。/etc/modprobe.d/blacklist.conf に r8169 の1行を加える。
  2. Realtekからドライバ(LINUX driver for kernel 3.x and 2.6.x and 2.4.x version 8.035.00)をダウンロードする。
  3. 展開する。
    $ tar xvjf r8168-8.025.00.tar.bz2
    
  4. コンパイル,インストール。これで,/lib/modules/3.2.0-xx-generic/kernel/drivers/net/ethernet/realtek/ にドライバ r8168.ko がインストールされる。
    $ cd realtek8168/r8168-8.035.00
    $ make clean modules
    $ sudo make install
    
  5. /etc/modules/etc/initramfs-tools/modules に r8168 の1行を加える。
  6. depmod する。
    $ sudo depmod -a
    
  7. initramfs のアップデート
    $ sudo update-initramfs -v -u -k `uname -r`
    
  8. リブートする。
  9. r8168 が eth0 でアップせず eth1 になっている場合は,/etc/udev/rules.d/70-persistent-net.rules の対応行を削除してリブートする。

aptitude upgrade して,カーネル 3.2.0-xx の xx が変わった場合,コンパイルから再度設定する必要がある。めんどくさいことになってしまった。