[DNS][Memcached][Redis][参考][自分用メモ] knot DNS resolverのバックエンドを変更して測ってみた。

先の記事でも書きましたが、自宅の実験場にCoreDNSが追加されたので賑やかになってきました。

以前から使用しているKnot DNS resolverですが、キャッシュするバックエンドとして、LMDBやmemcached、redisが選択できるのですが、どの程度性能に影響が出るのか、簡単にですが確認することにしてみました。

今回の環境：

Rock64

• Rockchip RK3328
• 4GB
• eMMCなし
• Ubuntu 16.04.3 aarch64

使用したソフト群：

$ dnsperf -h
DNS Performance Testing Tool
Nominum Version 2.1.0.0
$ redis-server -v
Redis server v=4.0.6 sha=00000000:0 malloc=libc bits=64 build=13a23188c1fd396d
$ memcached -V
memcached 1.5.3
$ kresd --version
Knot DNS Resolver, version 1.5.1

記事の時点で最新のものを使用しているつもりです。コンパイルでは特にチューニングなどはしていませんし、各ソフトウェアについても、特に最適化などもしていません。OS自体もkernerl tuningの余地が少ないので、こちらも性能に関わるような設定変更もありません。
また、NoSQLについては遅延の影響を避けるため、UNIXドメインソケットを使用しました。

Knot DNS resolver

modules = {
'resis',
'memcached',
}
-- Large cache size, so we don't need to flush often
-- This can be larger than available RAM, least frequently accessed
-- records will be paged out
cache.size = 2 * GB
-- embeded LMDB
-- cache.storage = 'lmdb:///var/knot-resolver'
-- memcached cache storage
-- cache.storage = 'memcached://--SOCKET="/var/run/memcached/memcached.sock"'
-- Redis cache storage
cache.storage = 'redis:///var/run/redis/redis.sock'

一番最後の設定を書き換えることで、バックエンドを切り替えていきます。

各NoSQLの特性やメリット・デメリットなどについては、色々とあるようなので皆様でご確認ください。

NoSQL – Wikipedia

memcachedについては、マルチスレッドで完全オンメモリ、ノードを増やせば性能はスケールする、redisについてはシングルスレッドだけど、persistent（永続化）にも対応、派生ソフトウェアを使用すればマルチマスタに対応、スレーブも増やせば読み込みはスケールする、みたいな感じのようです。

※このあたりの認識に間違いがあればご指摘ください。

Redis

Redis

デフォルトからの相違は以下の通り。

$ diff -u 6379.conf redis_6379.conf
--- 6379.conf 2017-12-14 21:54:16.195394443 +0900
+++ redis_6379.conf 2017-12-16 11:19:19.072503607 +0900
@@ -67,7 +67,7 @@
# IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES
# JUST COMMENT THE FOLLOWING LINE.
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-bind 127.0.0.1
+bind 127.0.0.1 ::1
# Protected mode is a layer of security protection, in order to avoid that
# Redis instances left open on the internet are accessed and exploited.
@@ -90,7 +90,7 @@
# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
-port 6379
+#port 6379
# TCP listen() backlog.
#
@@ -109,7 +109,7 @@
#
# unixsocket /tmp/redis.sock
# unixsocketperm 700
-unixsocket /run/redis/redis.sock
+unixsocket /var/run/redis/redis.sock
unixsocketperm 766
# Close the connection after a client is idle for N seconds (0 to disable)
@@ -136,7 +136,7 @@
# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
-daemonize no
+daemonize yes
# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
@@ -158,7 +158,7 @@
#
# Creating a pid file is best effort: if Redis is not able to create it
# nothing bad happens, the server will start and run normally.
-pidfile /var/run/redis_6379.pid
+pidfile /var/run/redis/redis_6379.pid
# Specify the server verbosity level.
# This can be one of:
@@ -171,7 +171,7 @@
# Specify the log file name. Also the empty string can be used to force
# Redis to log on the standard output. Note that if you use standard
# output for logging but daemonize, logs will be sent to /dev/null
-logfile /var/log/redis_6379.log
+logfile /var/log/redis/redis_6379.log
# To enable logging to the system logger, just set 'syslog-enabled' to yes,
# and optionally update the other syslog parameters to suit your needs.
@@ -186,7 +186,7 @@
# Set the number of databases. The default database is DB 0, you can select
# a different one on a per-connection basis using SELECT where
# dbid is a number between 0 and 'databases'-1
-databases 1
+databases 16
# By default Redis shows an ASCII art logo only when started to log to the
# standard output and if the standard output is a TTY. Basically this means

先にも書いたとおり、Redisはシングルスレッドなので、プロセスを複数立ち上げたほうが良いという記述もありましたが、先に書いたとおり、そのあたりのノウハウが無いので設定していません（ベンチマークならやれよという感じですが・・・）。

$ dnsperf -s 192.168.1.3 -p 9953 -e -c 100 -d ./queryfile-example-current -l 60
Statistics:
Queries sent: 13607
Queries completed: 13174 (96.82%)
Queries lost: 433 (3.18%)
Response codes: NOERROR 9898 (75.13%), SERVFAIL 117 (0.89%), NXDOMAIN 2979 (22.61%), REFUSED 180 (1.37%)
Average packet size: request 49, response 105
Run time (s): 64.710378
Queries per second: 203.584037
Average Latency (s): 0.298131 (min 0.000801, max 4.940053)
Latency StdDev (s): 0.455891

memcached

memcached – a distributed memory object caching system

追加した設定は以下になります。

PORT=11211
USER=memcached
MAXCONN=1024
CACHESIZE=2048m
OPTIONS="-C -v -s /var/run/memcached/memcached.sock -a 0666 -P /var/run/memcached/memcached.pid"

Statistics:
Queries sent: 12184
Queries completed: 11776 (96.65%)
Queries lost: 408 (3.35%)
Response codes: NOERROR 8847 (75.13%), SERVFAIL 94 (0.80%), NXDOMAIN 2672 (22.69%), REFUSED 163 (1.38%)
Average packet size: request 49, response 104
Run time (s): 64.551540
Queries per second: 182.427871
Average Latency (s): 0.343974 (min 0.000747, max 4.936886)
Latency StdDev (s): 0.496537

LMDB (Lighting Memory-Mapped Database)

Lightning Memory-Mapped Database – Wikipedia

オブジェクトを生成するものだから、sqliteのたぐいかと思ったら、こちらも組み込み向けのKVSなんですね。もとはOpenLDAP向けだったとか。

Statistics:
Queries sent: 12333
Queries completed: 11918 (96.64%)
Queries lost: 415 (3.36%)
Response codes: NOERROR 8949 (75.09%), SERVFAIL 97 (0.81%), NXDOMAIN 2707 (22.71%), REFUSED 165 (1.38%)
Average packet size: request 49, response 105
Run time (s): 64.873066
Queries per second: 183.712606
Average Latency (s): 0.336492 (min 0.000611, max 4.782788)
Latency StdDev (s): 0.496369

ザックリとした結果：

とりあえずQPSだけに着目するとRedisが若干性能が良いようです。というか気になるのはMemcachedとLMDBの差がないことですかね・・・　iowaitとか見ても0%のままでしたし、%usrとかみても多くて70%程度だったので、そもそもSBCの性能の限界として見たほうが良いんでしょうか。

ARMなSBCだと性能としては貧弱なので差が出やすいかなぁと思ったのですが、それ自体が裏目に出たような気がします。

resperfを使用して、問い合わせを増やしていったときにレイテンシがどの程度変化していくか見たほうが良かった気がしますので、これについては次回の宿題にしたいと思います。
いやいや、こうした方が良いんじゃないの？などの意見がありましたら、是非頂きたいと思います。