internal がデフォルトで、特に問題もないしずっとこれにしていたが、h2o が再起動されるたびにキャッシュが消えるのではないか? どうせ memcached も起動してるのでそっちにストアすべきではないか? と思いはじめたので変えてみた。

まぁ弱小ウェブサイトだとそもそも resumption かかるようなことがぜんぜんないので意味ない。Google Bot も分散アクセスのせいか全く resumption しないし。

1. トップ
2. tech
3. h2o の ssl-session-resumption のストア先を memcached に

$ brew install libtiff
$ brew install --HEAD webp

~/Library/Application Support/Adobe/Lightroom/Export Actions

#!/usr/bin/env ruby

require 'logger'

logger = Logger.new('/tmp/webplog')
logger.info ARGV.inspect

begin
	ARGV.each do |f|
		dir = File.dirname(f)
		out = File.join(dir, File.basename(f, ".tif") + '.webp')
		logger.info "%s => %s" % [f, out]
		IO.popen([
			'/usr/local/bin/cwebp',
			'-metadata', 'all',
			'-preset', 'photo',
			'-q', '90',
			'-o', out,
			'--',
			f
		], :err=>[:child, :out]) do |io|
			while l = io.gets
				logger.info l.chomp
			end
		end
	end

rescue Exception => e
	logger.fatal e.inspect
end

1. トップ
2. tech
3. Lightroom で webp の一発書きだし

リバースプロキシとして使っている h2o で

proxy.reverse.url: http://localhost:5001/

みたいに書いていたら確率的に connection failure がでて悩んだ。結局

proxy.reverse.url: http://127.0.0.1:5001/

で解決

1. トップ
2. tech
3. h2o の proxy.reverse.url で localhost を指定していたら確率的に connection failure

start_server が listen してないポートは以下のようなエラーになる。

cp socket:(null):80 is not being bound to the server

h2o は SIGHUP で graceful restart が可能だが、listen するポートが変わった場合は実際にlistenしている親プロセス (start_server プロセス) の再起動が必要になる。

1. トップ
2. tech
3. h2o で listen するポートを増やしたときは master プロセスの再起動が必要

これまで HTTPS (443) だけ h2o で処理していたが、nginx に使ってるぶんのメモリ量がMOTTAINAIのでh2oだけでやるようにした。さようなら nginx。

複雑なことをしているホストは全くなかったので普通に書きかえていっただけ

1. トップ
2. tech
3. nginx をアンインストール

最初からアドレスついてたので意外とやることない。

ifconfig すると既に v6 のアドレスがついている。Scope:Global になっているやつがグローバルIPアドレス (正確にはグローバルユニキャストアドレス)

inet6 addr: 2001:e42:102:1807:160:16:210:51/64 Scope:Global

これを該当ドメインの AAAA レコードでひけるようにする。

server {
    listen   80; 
    listen [::]:80;
    ...
}

1. トップ
2. tech
3. さくらのVPSのウェブサーバでIPv6の接続をうける

どのぐらいまで生きていられるのか気になったので試してみる。wrk を使う (ab だとうまく高負荷にできなかった) wrk は brew で入る。

ベンチの際いくつか注意する

• Transfer/sec が十分に低いこと
  • 帯域を使いきってると負荷をかけきれない
• Non-2xx or 3xx responses がではじめたら限界
  • 発生しなかったときは表示されない

$ wrk -c 170 -d 10s -t 16 https://...
Running 10s test @ https://...
  16 threads and 170 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   164.27ms   64.53ms 852.22ms   80.26%
    Req/Sec    61.56     22.99   170.00     72.60%
  9278 requests in 10.10s, 44.31MB read
  Non-2xx or 3xx responses: 22
Requests/sec:    918.52
Transfer/sec:      4.39MB

日記システムは、これぐらいでCPUは使いきってちょいちょいエラーが発生する感じだった。

ヤフー砲が瞬間最大で100req/sec、継続的に30req/secぐらいらしいので、現実的にはこの日記が負荷で死ぬことはまずなさそう。他のサービスも同居してて相互に影響してる(バックエンドプロセスのワーカーを共有してる)けど。

1. トップ
2. tech
3. サイトの負荷のシミュレーション

サーバ移行のタイミングでつかいはじめた。監視をちゃんとするようにしようという感じ。loadavg5 と filesystem でひとまず監視。メトリクスの保存とグラフ化はフリープランだと1日だけなのであまり重視してない。

しかし、さくらのVPSはホスト不具合で落ちるってことは滅多にないので、やりたいことはサーバ自体の死活というよりウェブサーバの監視になる。このへんはプラグインでごにょごにょやってみている。パフォーマンス(応答時間のパーセンタイル値とか)とエラー数あたりでアラートが出せればいいかなという感じ。

1. トップ
2. tech
3. Mackerel つかいはじめた

高誘電体 MLCC は容量が時間経過で減少していくが、約125度(キュリー温度)まで加熱すると容量が回復する特性がある、らしい。

エージングで容量が減っていくというのはいいとして、一定より温度をあげると回復するというのを知らなかったのでびっくりした。

PS3/PS4 の修理方法でとにかくホットブローするみたいなのがあるけど、はんだクラックだけではなくて容量回復するという意味合いもあるのだろうか。

1. トップ
2. tech
3. チップコンデンサ(MLCC)の容量回復

さくらのVPSにMongo Rescueのリストアができなかった (未解決) | tech - 氾濫原 の続きで、結局クリーンインストールした。さっき DNS を切り替えたので様子見。一応 DNS の TTL 時間はとっくにすぎたので、変な BOT 以外はいまのところ旧サーバにアクセスない。

どうやったかのメモはまた別にかく

一通り移行できたつもりだけど、元々雑多なサーバ内容かつ長期運用していたのでよくわからない。外形監視を自宅 Raspi からやっておくべきだったかなあ。

プランは東京 2GB SSD にした。前がだいぶ古い大阪 1GB HDD プランだったので SSH で繋いで体感できるぐらいパフォーマンスあがった。ウェブ側も早くなってて Google からの評価があがるといいんだけどな〜

1. トップ
2. tech
3. サーバー移行

現状のサイト応答速度 - 氾濫原 と同じように測ったつもり。しかしなんか RTT が 7〜9ms になってて根本的にぜんぜんちがう。。

1. トップ
2. tech
3. 現状のサイト応答速度

カスタムOSインストールガイド - Ubuntu 16.04 – さくらのサポート情報 を見ながらインストールまでやる。

旧サーバと同じホスト名にしてDNSをふりかえたいが、DNS やホスト名まわりは最後にやる。

$ ssh-copy-id user@ufhostname

$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
UsePAM no
$ sudo /etc/init.d/ssh restart
# 別のターミナルを開いて ssh できることを再度確認

sudo ufw default deny
sudo ufw allow 80
sudo ufw allow 443
sudo ufw allow 22
sudo ufw allow 60000:61000/udp

sudo ufw enable

sudo apt-get install zsh gcc libncurses5-dev language-pack-ja git daemontools daemontools-run mysql-server ca-certificates cpio curl dnsutils imagemagick imagemagick-common irssi libcairo2-dev libcurl4-openssl-dev mime-support   nginx nginx-common nginx-full ntp ntpdate optipng pkg-config  rsync shared-mime-info w3m wget xz-utils xml-core zip libxml2-dev libtiff5-dev libssl-dev libsqlite3-dev libreadline-dev libpng12-dev  libpango1.0-dev libopenjpeg-dev libmysqlclient-dev libjpeg8-dev libgif-dev libfreetype6-dev libffi-dev cmake screen ruby-dev rrdtool libdb-dev postfix unattended-upgrades

sudo ln -s /etc/service /service

$ sudo vi /etc/sudoers.d/rsync
Defaults    env_keep += "SSH_AUTH_SOCK"
Defaults!/usr/bin/rsync    !requiretty
cho45    ALL=(ALL)       NOPASSWD: /usr/bin/rsync
 ||<

>||
## dry-run 
sudo rsync --dry-run -auvz -e 'ssh -i /home/cho45/.ssh/id_ecdsa' --rsync-path='sudo rsync'  --progress  /home/cho45/ cho45@160.16.210.51:/home/cho45/

/srv
/etc/nginx
/etc/postfix
# /etc/mysql 変更点がなかった。。。あらためて見直そう
/etc/letsencrypt
# /var/lib/mysql mysqldump でやった
# /service 手動でやる

cd ~/project/h2o
git clean -f
cmake -DWITH_BUNDLED_SSL=on .
make
sudo make install

sudo mkdir /var/log/h2o

/var/log/h2o/*.log {
    daily
    missingok
    rotate 90
    compress
    delaycompress
    notifempty
    create 0640 www-data adm 
    sharedscripts
    postrotate
        svc -h /service/h2o
    endscript
}

perlbrew install perl-5.22.2 --as perl-5.22

mysqldump -uroot --routines --all-databases --flush-privileges | ssh cho45@160.16.210.51 'mysql -uroot'

160.16.210.51 www.lowreal.net
160.16.210.51 lowreal.net
160.16.210.51 cho45.stfuawsc.com
160.16.210.51 coqso.lab.lowreal.net
160.16.210.51 no-real.net
160.16.210.51 block.lab.lowreal.net

crontab -l > crontab.user
sudo crontab -l > crontab.root

crontab crontab.user
sudo crontab crontab.root

net.core.somaxconn = 50000
net.ipv4.tcp_max_syn_backlog = 30000
net.core.netdev_max_backlog = 5000

net.ipv4.ip_local_port_range= 1024 65535

1. トップ
2. tech
3. Ubuntu 16.4 LTS クリーンインストールして引越

キャッシュの持ちかたを変えて、圧縮 (gzip) して持つように変えた。キャッシュを返すときは gzip ずみのをそのまま返すように。

gzip 非対応ブラウザでおかしくなる気がするけど、昨今そんなブラウザは聞いたことがないので現実的には問題なかろうという気がする。

これによりキャッシュ用のDBファイル(SQLite)のサイズが劇的に減ったので、ファイルキャッシュに乗りやすくなったはず……

1. トップ
2. tech
3. このサイトのキャッシュ

誤り訂正や、超解像技術みたいなのを前提とした圧縮方法に興味がある。なんとなく面白い感じがする。本来存在していたデータを意図的に削って送って、受取側の「経験」みたいなものを信用する感じが面白い。

画像圧縮も、CPU速度と帯域を比べたときに帯域で律速されるぐらいに高解像度になると、ディープラーニングによる高解像度化や、自動色付けを前提とした画像圧縮アルゴリズムが産まれても不思議ではない。

つまりこれは「おい」と言うとお茶がでてくるみたいなシステム。これがコンピュータで実現すると面白い。送信側の「意図」みたいなものを最大限推論してデータを復元し、転送データを最小限にできる。

1. トップ
2. tech
3. 「おい」と言うとお茶がでてくるみたいな圧縮アルゴリズム

前まで webp のアップロードはできなかった気がするんだけど、最近試したらできるようになっていた。

Google Photos はいつからかブラウザによって webp が落ちてくるように変わったけど、そのタイミングでアップロードも変わったのかな?

ちなみに JPEG 2000 や JPEG XR はあいかわらずアップロード不可能

1. トップ
2. tech
3. Google Photos の webp 対応

いままでハマったことがなかったのだけど、ついにハマってしまった。
補助グループ権限もつけてくれるsetuidgidのようなもの - (ひ)メモ を読んで、どうするかな〜と思いつつsetusergroupsを試してみたが、Unix::Groups がデフォルトで入っておらずちょっと困ったので python で以下のようにした。

#!/usr/bin/python

import os
import sys
import pwd

if len(sys.argv) < 3:
    print >> sys.stderr, 'Usage: setusergroups user program'
    sys.exit(1)


pw = pwd.getpwnam(sys.argv[1])
pw_name = pw[0]
pw_uid = pw[2]
pw_gid = pw[3]
pw_home = pw[5]

os.environ['HOME'] = pw_home
os.initgroups(pw_name, pw_gid)
os.setgid(pw_gid)
os.setuid(pw_uid)
os.execvp(sys.argv[2], sys.argv[2:])

エラると例外で落ちてトレースバックがでて十分なので特にエラー処理してな

1. トップ
2. tech
3. daemontoolsのsetuidgidが補助グループ (supplementary groups) 権限をつけてくれない問題 (python)

ありがとうございました。

1. トップ
2. tech
3. builderscon tokyo 2016 で「 Bluetooth キーボードの作りかた」を喋りました

16:40〜 自作キーボードの話を1時間ぐらいする予定です。なんか1日の最後なのでゆるめでやりたいという気持ちはあります。

おおむね、事前のトーク概要と変わらない内容で話せそうです。

資料つくってます…… 話がまとまらない……

ref. builderscon - Discover Something New

1. トップ
2. tech
3. builderscon tokyo 2016 でしゃべります