2020/03/16(月)さくらVPS v5と歴代VPSのベンチマーク比較

さくらVPSのv5がリリースされ、さくらVPS v3が機器老朽化メンテナンスで物理層が入れ替わったので、まとめてテストしてみました。

UnixBench Version 5.1.3 index

計測コマンドは「./Run -i 5 -c 2」(2コアで計測)。

項目自宅サーバ512 v11G v31G v3'2G v41G v51G v3X
Dhrystone 24853.84412.13724.83837.24916.66313.46194.3
Whetstone1508.91148.01037.61199.21625.21861.81866.3
Execl Throughput1321.71592.51764.51288.51310.52461.42037.8
File Copy 10242058.61063.41705.62014.11867.02794.92549.9
File Copy 2561391.3747.31255.51183.61214.51779.81605.3
File Copy 40963560.21631.23501.62669.03665.46356.15756.8
Pipe Throughput1070.5--1087.0896.53006.43066.7
Context Switching505.2--692.4128.61727.21693.4
Process Creation1168.9--809.8613.81788.31632.1
Shell Scripts (1)3304.0--1920.82897.03936.23623.5
Shell Scripts (8)3318.1--2472.13343.14357.93994.2
SysCall Overhead653.8--639.2443.92200.62337.6
トータルindex1662.9--1424.41313.92876.32713.3
  • OSは Debian 10 と 6。
  • VPS 512/VPS 1G v3(メンテ前)は2013年2月計測。
    • 「Pipe Throughput」以降は、OS Versionによる影響が大きいため除外。*1
  • 自宅サーバ: Core i3 530 / 2.93GHz 2コア4スレッド / RAM 4GB / SSD
  • 1G v3: 石狩リージョン
  • 1G v3': 2020年2月の設備老朽化メンテナンス1回目後
  • 1G v3X: 2020年3月の設備老朽化メンテナンス2回目(物理層入れ替え)後
    • v5と同じ物理層になったと思われる。
  • 2G v4: 東京リージョン。仮想3コア。

*1 : おそらくCPU脆弱性関連の影響だと思われる。

ディスク性能計測

hdparm -t /dev/vda4
dd if=/dev/vda4 of=/dev/null bs=1M count=2048 iflag=nocache
dd if=/dev/zero of=/tmp/test bs=1M count=2048 oflag=direct
単位 MB/s家サーバ1G v32G v41G v51G v3X
haparm260480-600200200200
dd 2G read271200-500210210210
dd 2G write247100210210210
  • 家サーバ: SSD TOSHIBA THNSNJ128GCSU 128GB
  • VPS 1G v3は2020年2月の老朽化メンテ1回目の後。
    • read性能の値変動がとても大きい。*2
  • /tmp のファイルシステムはいずれも ext4
  • v4/v5は計測性能が 1MB/s もずれないので、おそらく帯域制限がかかっていると思われる。
  • VPS 1G v3Xは2020年3月の老朽化メンテ2回目(物理層入れ替え)後。
    • v4/v5と同じディスクになった模様。

*2 : 単時短に大容量を転送すると、一時的に速度を下げているように思われる。

結論

  • v3老朽化メンテナンス後は、v5と同じ物理層になったと思われる。
  • v5はv3/v4よりも性能が良い。
  • v4以降はディスク性能にリミットがかかっている。

乗り換え検討

「v3」と「v5」が同じ物なのに値段が高いのをどうにかしてほしい。「v5」のほうが安いじゃん!

  • さくらVPS 1G v3 (石狩): 10,267円
  • さくらVPS 1G v5 (石狩): 8,800円

長く使うなら面倒でも乗り換えたほうがよさそう。石狩DCはネットワーク遅延から少しだけ不利で後悔したし、他のリージョンという手もあるけども、DC見学もしたので石狩継続かな。

2020/02/14(金)Raspberry Piで設定済システムをイメージ化する

Raspbian や Volumio などの設定済システムを、なるべく小さくディスクイメージ化するメモ。

お手軽に縮小する

# fdisk -l /dev/mmcblk0
Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 15554559 15022080  7.2G 83 Linux

8GB SD に Raspbian を入れた場合こんんな感じになります。下のパーティションが root ファイルシステムです。これを縮小します。

オンラインだと面倒なので、Linuxマシンを別に用意し、そこにラズパイ用のSDを入れて編集します。

# e2fsck -f /dev/sdd2
# resize2fs -P /dev/sdd
resize2fs 1.44.5 (15-Dec-2018)
Estimated minimum size of the filesystem: 470543

ブロックサイズは4KBですので、470543ブロック×4KB=1.9GB程度まで縮小できることがわかりました。キリの良いところで2GBに縮小します。

# resize2fs -P /dev/sdd 2G
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/sdd2 to 524288 (4k) blocks.
The filesystem on /dev/sdd2 is now 524288 (4k) blocks long.

resize2fs は 1.5GB といった指定はできません。1536Mと指定する必要があります。

ファイルシステムを縮小したらパーティションを縮小します。fdiskでパーティションを削除してから、スタートブロックを揃えてパーティションを再生成します。

# fdisk /dev/sdd
Command (m for help): d
Partition number (1,2, default 2): 2

Command (m for help): n
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2048-15554559, default 2048): 532480
Last sector, +/-sectors or +/-size{K,M,G,T,P}: +2G

Created a new partition 2 of type 'Linux' and of size 2 GiB.
Partition #2 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: n

Command (m for help): p

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdd1         8192  532479  524288  256M  c W95 FAT32 (LBA)
/dev/sdd2       532480 4726783 4194304    2G 83 Linux

1セクタは512byteですので、「512×4194304 = 2147483648」と resize2fs の結果「524288×4096 = 2147483648」が等しいことを確認します。確認して問題なければ、最後に書き込んで終了です。

Command (m for help): w

これで縮小されたシステムがSDに構築されました。

ddでイメージ化

最後にこのSDイメージ化すれば完成です。このときは、2つめのパーティションのEndの値「4726783」に注目します。先頭からこのセクタまで保存すれば良いので、「(4726783+1)×512 = 2308MB」を保存します。

dd if=/dev/sdd of=./img.file bs=1M count=2308 status=progress

これでイメージが完成しました。

問題点

お手軽で良いのですが、ひとつ問題点がありまして、この手順では極限まで小さくしたイメージを作ることができません。出来上がったらイメージからRaspberry Piを起動するとこうなります。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       2.0G  1.3G  644M  66% /
/dev/mmcblk0p1  253M   52M  201M  21% /boot

このように800MBほど空いている領域があるわけです。またパーティションのスタートブロックも、8192から2048に減らすことで容量を削減できます。

限界まで縮小したイメージを作成する。

  1. パーティション1のファイルをどこかにコピーしておく。
  2. パーティション2の内容をどこかに「cp -rp」でコピーしておく。
  3. fdiskで表示される「Disk identifier:」の値をメモしておく*1
  4. fdiskで現存するパーティションを削除する。
  5. dosパーティション(パーティションタイプ"C"。100MB程度)とLinuxパーティションを作成する。このときのサイズは、「Used」のサイズ(コピーしたファイル全体のサイズ)を参考にする。
  6. 新しいディスクにコピーする場合、またはディスクを一度初期化した場合は、fdiskでDOSパーティションテーブルを作成し「Disk identifier」の値を書き換えます。fdiskで「x」「i」と入力したあと、3でメモした値を入力します。
  7. ファイルシステムを作成する*2
    mkdosfs -F32 -nBOOT /dev/sdd1
    mkfs -t ext4 /dev/sdd2
    

    「-nBOOT」はディスクラベルをBOOTにする設定です。DOS領域(vfat)のラベル名をBOOTにしないとラズパイが起動しません。後から変更する場合は、dosfslabelコマンドを使用します。

    dosfslabel /dev/sdd1 BOOT
    
  8. 作成したパーティションをマウントしてファイルを書き戻す。ext4領域は必ず「cp -rp」でコピーする。

これで作業完了です。SDラズパイに挿入して起動することを確認します。問題なければ、上と同様の手順でイメージ化します。

注意点

DOS領域のディスクラベルを「BOOT」にすることと、「Disk identifier」の値を保つことです。

fstabやカーネル起動オプションでは「PARTUUID」によってデバイスを指定しています。PARTUUIDはファイルシステムのUUIDではなく、パーティションにつけられたUUIDです。DOSパーティションテーブル(MBR)には存在せず、gptパーティションテーブルが持つものです。

DOSパーティションにはPARTUUIDの概念はないのですが、「(Disk identifier)-(パーティション番号)」をPARTUUIDの代わりとして使用するようになっています。ですから「Disk identifier」を維持する必要があります。

*1 : 忘れた場合はコピーしたシステムファイル中の /etc/fstab に書かれた「PARTUUID=」の値(ハイフンより手前)をメモする。

*2 : dosfstoolsが必要

パーティション領域の自動拡張

/boot領域(Windowsから見える領域)の「cmdline.txt」に「init=/usr/lib/raspi-config/init_resize.sh」をつけることで、初回起動時のパーティションの拡張を実行できます。

しかしこれだけだと、パーティションは拡張されますが、ファイルシステムは未拡張のままです。ファイルシステムの拡張は /etc/init.d/resize2fs_once というファイルで行われています。

#!/bin/sh
### BEGIN INIT INFO
# Provides:          resize2fs_once
# Required-Start:
# Required-Stop:
# Default-Start: 3
# Default-Stop:
# Short-Description: Resize the root filesystem to fill partition
# Description:
### END INIT INFO
. /lib/lsb/init-functions
case "$1" in
  start)
    log_daemon_msg "Starting resize2fs_once"
    ROOT_DEV=$(findmnt / -o source -n) &&
    resize2fs $ROOT_DEV &&
    update-rc.d resize2fs_once remove &&
    rm /etc/init.d/resize2fs_once &&
    log_end_msg $?
    ;;
  *)
    echo "Usage: $0 start" >&2
    exit 3
    ;;
esac

このファイルを作成し、実行権限をつけます。そして /etc/rc3.d/S01resize2fs_once からリンクを貼ります。

vi /etc/init.d/resize2fs_once
chmod +x /etc/init.d/resize2fs_once
cd /etc/rc3.d/
ln -s ../init.d/resize2fs_once S01resize2fs_once

これで初回起動時のパーティション&ファイルシステム自動拡張が有効になります。

Raspbian初回インストールメモ

/bootは、SDをWindowsから開いたときに見える中身と同一。

  • /boot に ssh ファイルを置くと、sshサービスを有効化できる。
  • /boot に以下のような wpa_supplicant.conf を置くと、自動で /etc/wpa_supplicant/wpa_supplicant.conf にファイルを移動してくれる(コピーではなく強制移動)。これにより無線LANに接続できる。
    • 複数のネットワークに接続する場合は、networkを複数記述すれば良い。
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=JP

network={
	ssid="SSID"
	psk="PASSWORD"
}

mjpg-streamerインストールメモ

apt-get install git cmake libjpeg-dev imagemagick
git clone https://github.com/jacksonliam/mjpg-streamer.git
cd mjpg-streamer/mjpg-streamer-experimental
make
sudo make install

mjpg_streamer -o "output_http.so -w ./www" -i "input_raspicam.so -fps 60"

2020/01/20(月)Debian10で Apache + php-fpm の正しい設定メモ

Apache + php-fpm 環境で Debian 9(jessie) から 10(buster) にアップデートしたら動かなくなったので、メモ。

概要

Debian付属のmod_phpはスレッドセーフではないため、Apacheを event_mpm や worker_mpm で運用している場合は使用できません(prefork専用)。

そもそも今どきmod_phpで動作させるのはナンセンスなので、FastCGIデーモンによるPHP環境 FPM/php を使用します。

Debian10での設定

  • Apache 2.4
  • PHP 7.3 (php7.3-fpm)
apt-get install php-fpm libapache2-mod-fcgid

php-fpmをインストールすることで自動的に「php-fpm7.3」サービスが起動します。

/etc/apache2/conf-available 以下に php7.3-fpm.conf が作られるので、これを有効にします。

cd /etc/apache2/conf-enabled
ln -s ../conf-available/php7.3-fpm.conf

proxy_fcgi_moduleが必要なのでこれも有効にします。

cd /etc/apache2/mods-enabled
ln -s ../mods-available/proxy_fcgi.load

この状態で、Apacheを再起動すれば有効になっているはずです。

php7.3-fpm.confの中身

# Redirect to local php-fpm if mod_php is not available
<IfModule !mod_php7.c>
<IfModule proxy_fcgi_module>
    # Enable http authorization headers
    <IfModule setenvif_module>
    SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>

    <FilesMatch ".+\.php$">
        SetHandler "proxy:unix:/run/php/php7.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <FilesMatch ".+\.phps$">
        Require all denied
    </FilesMatch>
    <FilesMatch "^\.ph(ar|p|ps|tml)$">
        Require all denied
    </FilesMatch>
</IfModule>
</IfModule>

以前使っていた古い設定

Debian 9(jessie)でも全く同じ設定で動作するのですが、以前は古い設定を使っていました。その設定を書いておきます。

  • php-fpm7.0
  • libapache2-mod-fastcgi (Debian9までしか提供されず)

Apache2の libapache2-mod-fastcgi(libapache2-mod-fcgidではダメ)を有効化してから、sites-available/000-default.conf 等に以下の設定を行います。

<IfModule mod_fastcgi.c>
        AddHandler      fastcgi-script  .fcgi
        AddHandler      php7.0-fcgi     .php
        Action          php7.0-fcgi     /usr/sbin/php-fpm7.0
        FastCgiExternalServer   /usr/sbin/php-fpm7.0 -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
        FastCgiConfig           -maxClassProcesses 100

        <Directory /usr/sbin>
                <Files php-fpm7.0>
                        Require all granted
                </Files>
        </Directory>
</IfModule>

何が変更になったのか

外部プログラムを呼び出して、そこから php-fpm サーバに接続するという形式が無効になったようです。上に書いた古い設定は多くの新しいLinuxディストリビューションで無効になっているようです

この古い設定を行った場合、エラーログ等はなく「404 Not Found」と言われ白紙のページが出るだけなので混乱します。

現在は Apache に直接組み込んだ FastCGIのProxyのモジュール(proxy_fcgi_module)から、直接php-fpmに接続するようになりました。このほうが遥かに効率的です。

メモ

  • php-fpmを利用する場合、SuEXECと併用できない。
  • php-fpmデーモン(設定ファイル)を権限(ユーザー)ごとに分ける必要がある。

2019/10/19(土)JNBのカード型トークンを分解してみる

ジャパンネットバンク銀行(JNB)が発行しているカード型トークン(セキュリティキー)を分解してみました。

jnb-token_01.jpg

ネットバンクの操作に必要なワンタイムパスワードを表示する機械で、今では一般的になりましたけど、JNBが最初だったんんじゃないかな。他行では乱数表が一般的だったと思います。

厚さなんと0.8mm。上にシート(約0.15mm)がついているのでこれを慎重に剥がします。

jnb-token_02.jpg

結構しっかりと融着されているので剥がすのは大変です。個体によるのかもしれませんが、特に左上(「電池」の赤字があるところ)は強固に融着されていました。剥がしたあとの厚みはたったの0.65mm。このサイズに回路が入っていて、しかも10年持つというのは驚きです。

余談

分解したものは壊れたトークンです。壊れた場合、電話しなくてもWebから再発行を依頼できたらしい。カードに電話番号しか書いてないので、電話必須だと思ってしまった……。

jnb-token-web.png

ちなみに故障の症状は以下のものでした。参考にしてください。

  • ONにした瞬間「EEEEEE」表示がされ、その後数字が出る。
  • 1分以上経ってもその数字が消えない。
  • 何度ON/OFFしてもその数字が変わらない。

2019/03/29(金)温度調整機能付き はんだごての比較

gootのPX-201とHAKKO(白光)FX-600の比較。

性能比較

元々、PX-201を使っていたのですが、持ち手部分が太く手に馴染まなかったため、FX-600を新たに購入しました。

soldering_iron.jpg

PX-201

asin:B001PR1KLK

  • ヒーター 70W
  • 調整温度 250~450℃
  • 持ち手部分が太い
  • こて先もやや太い
  • 使っているうちに持ち手カバーがずれて通電ランプが見えなくなる。

FX-600

asin:B006MQD7M4

  • ヒーター 50W
  • 調整温度 200~500℃(切り替え式)
  • 持ち手部分が細め
  • 持ち手が滑りやすい
  • こて先もやや細め

感想

持ち手部分の太さは明らかに違います。こて先も白光FX-600が少し細めです。この角度のちょっとした差で使いやすさが違うのです。

soldering_iron-2.jpg

一番下は久冨のこて先です。リンク先ではM-30LTとなってますね。中学生の頃、久冨は授業で作ったはんだごてですが、手に馴染んでいて長年使っていました。細めの芯が便利なのですよね……。

PX-201を購入して乗り換えましたが、こて先も太くて困っていました。「細いこて先」を買えよという声が聞こえてきそうです。もちろんPX-2RT-SBを購入して試したのですが、このこて先は細すぎて熱伝導効率が悪く使いにくいのです。*1

さて白光のこて先はどうか。

また本格的に使用したら記事をアップデートします。

*1 : 鋭利なため基板やICの足を傷つけてしまいやすいのも問題でした……