helen's blog

ずっとおもしろいことしてたいな。

mackerel-plugin-varnishのグラフを読めるようになりたい

Varnishをやっていて悩むことがよくあって
mackerel-plugin-varnishを使ってみようと思い立ってすぐ入れたけど
あまりリファレンスややってみた記事がヒットしなかったのでざっくりまとめました😁

キャッシュサーバやVarnishを自分で構築するのも監視するのも初めてなので
お手柔らかにお願いします...🙏

今回使った環境

  • CentOS7.5
  • mackerel-agent 0.56.0
  • Varnish 6.0
  • プロキシ先は同ホストに立てたPHPのWebアプリケーション
    • 今回はあまり重要ではないので詳細は割愛します

Varnishとは?

Varnish HTTP Cache — Varnish HTTP Cache

キャッシュするHTTPリバースプロキシ(直訳)で
6.0.0は2018年3月にリリースされたものです
語り始めると長いのでVarnishについては気が向いたら別で書きます

mackerel-plugin-varnish

github.com

VarnishにはvarnishstatというVarnishのパフォーマンスを見れる便利ツールがあり
mackerel-plugin-varnishはvarnishstatの出力した結果をMackerelへ投稿してくれます
varnishstatはVarnishをインストールすると一緒にインストールされます

varnishstatを実行するとこのような画面になります
引数に-1で今の瞬間のデータ表示、つけない場合は最新のものが常に表示されます
※長いので関係する箇所だけ抜粋しました

# varnishstat -1
MAIN.client_req           103036        10.97 Good client requests received
MAIN.backend_req              10         0.00 Backend requests made
MAIN.backend_conn              4         0.00 Backend conn. success
MAIN.backend_unhealthy         0         0.00 Backend conn. not attempted
MAIN.backend_busy              0         0.00 Backend conn. too many
MAIN.backend_fail              0         0.00 Backend conn. failures
MAIN.backend_reuse             6         0.00 Backend conn. reuses
MAIN.backend_recycle          10         0.00 Backend conn. recycles
MAIN.backend_retry             0         0.00 Backend conn. retry
MAIN.client_req           103036        10.97 Good client requests received
MAIN.cache_hit            103025        10.97 Cache hits
MAIN.cache_hit_grace           0         0.00 Cache grace hits
MAIN.cache_hitpass             0         0.00 Cache hits for pass.
MAIN.cache_hitmiss             0         0.00 Cache hits for miss.
MAIN.n_object                  3          .   object structs made
MAIN.n_objectcore            153          .   objectcore structs made
MAIN.n_objecthead            153          .   objecthead structs made
MAIN.n_expired                 7          .   Number of expired objects
SMA.s0.c_req                  30         0.00 Allocator requests
SMA.s0.c_fail                  0         0.00 Allocator failures
SMA.s0.c_bytes            368834        39.28 Bytes allocated
SMA.s0.c_freed            196382        20.92 Bytes freed
SMA.s0.g_alloc                15          .   Allocations outstanding
SMA.s0.g_bytes            172452          .   Bytes outstanding
SMA.s0.g_space         268263004          .   Bytes available

これを目で追うのが大変だけど、
Mackerelを使うとデータを蓄積して
見やすく表示して監視してくれるのが本当にありがたいです

プラグインを実行すると上記の出力がこうなります

# mackerel-plugin-varnish
[SMA.s0.g_alloc s0 g_alloc]
varnish.requests.requests	13020.000000	1534141634
varnish.requests.cache_hits	13020.000000	1534141634
varnish.backend.backend_req	0.000000	1534141634
varnish.backend.backend_conn	0.000000	1534141634
varnish.backend.backend_fail	0.000000	1534141634
varnish.objects.n_object	1.000000	1534141634
varnish.objects.n_objectcore	151.000000	1534141634
varnish.objects.n_objecthead	151.000000	1534141634
varnish.objects_expire.n_expired	0.000000	1534141634
varnish.busy_requests.busy_sleep	0.000000	1534141634
varnish.busy_requests.busy_wakeup	0.000000	1534141634
varnish.sma.g_alloc.s0.g_alloc	5.000000	1534141634
varnish.sma.memory.s0.allocated	57231.000000	1534141634
varnish.sma.memory.s0.available	268378225.000000	1534141634

カスタムメトリック

pluginを読み込ませるだけで7個のグラフが生成されます
対象のvarnishstatのフィールド名と合わせて表にしました

Varnish Backend

BackendはVarnishがリクエストを受け取ったあとの転送先です
今回用意した環境で言うと「PHPのWebアプリケーション」がそれにあたります

Metrics 説明 varnishstatのフィールド名
Conn fail Backendとのコネクション失敗数 MAIN.backend_fail
Conn Success Backendとのコネクション成功数 MAIN.backend_conn
Requests Backendへのリクエスト数 MAIN.backend_req

このRequestsはアクセス数ではなくBackendへのアクセス数なので
サイトのアクセス数とは一致しません
クライアントのリクエスト数はMAIN.client_reqです
MAIN.backend_failが上がってくるようだと、
BackendのアプリケーションかVarnishとアプリケーションの疎通に問題がある可能性が高いです

f:id:heleeen:20180813190455p:plain

これはキャッシュをオフにしたときのグラフです
キャッシュをオフにするとRequestが増え、Conn Successがすこしだけ増えます

Varnish Busy Requests
Metrics 説明 varnishstatのフィールド名
wakeup sleep listから取り除かれたリクエスト数 MAIN.busy_wakeup
sleep Busy状態のオブジェクトがあるのでsleepさせたリクエスト数 MAIN.busy_sleep

Varnishでは、リクエストがバックエンドに到達するとbusyオブジェクトが生成されます
この処理中に新しいリクエストが同じページに来たときに
Varnishがbusyオブジェクトがある(同じページへのアクセスが処理中)と判断すると
そのリクエストを一度Waitingリストへ登録します
そして、最初のリクエストが処理されたときに
Waitingリストに登録されていたリクエストたちにもレスポンスします

つまり、Varnishは同じページへのリクエストがあるときは
最初の1つをBackendへ流し他は待機させておいて、
最初のリクエストが処理された後に、そのキャッシュを待機させていたリクエストに返すという動作をしています

その監視をしているのがBusyとWakeupです

Varnish Client Requests
Metrics 説明 varnishstatのフィールド名
Hit キャッシュヒット数 MAIN.cache_hit
Requests リクエスト数 結果 MAIN.cache_hit ?

HitがRequestsに近ければ
Varnishがキャッシュをユーザに返してくれていて
そのリクエストは裏のアプリケーションに到達していないことになります

f:id:heleeen:20180814152356p:plain

キャッシュをオフにした状態のグラフです
オフにしてもデフォルトのキャッシュである程度Hitはします
Hit率が低い場合、キャッシュ条件を見直すと高速化する可能性があります

f:id:heleeen:20180813160621p:plain

キャッシュ設定してこれくらいでした
特定ページへのabなのでHitsとRequestsが一致しちゃっておもしろくないですが
Hit率が高いので調子は良さそうですね😅
cache_hitpass(キャッシュしないキャッシュ)も見れるとうれしいけど
Mackerelのメトリックとしてないってことは見なくていいのかな?🤔

Varnish Objects
Metrics 説明 varnishstatのフィールド名
objecthead キャッシュ内でハッシュが異なるものの数 MAIN.n_objecthead
objectcore キャッシュ内のメタデータの数 MAIN.n_objectcore
object キャッシュしたオブジェクト数 MAIN.n_object

hashはここではキャッシュのKeyです
Varnishで"オブジェクト"というといろんな種類があり
その中のobjectcore, objectheadがモニタリングされています

f:id:heleeen:20180814153621p:plain

キャッシュをオフにした状態でのグラフです

Varnish Objects Expire
Metrics 説明 varnishstatのフィールド名
expire 期限切れしたオブジェクト数 MAIN.n_expired

f:id:heleeen:20180813190140p:plain

これはキャッシュをオフにして30秒おきにアクセスしたグラフです
キャッシュを作ってもすぐexpiredになっていまうので上がって下がってを繰り返します

MAIN.n_lru_nuked(新しいキャッシュのために強制削除されたキャッシュ)が
カスタムメトリックにはないのはなぜなのかが気になった
n_lru_nukedが起こるということはキャッシュ用メモリサイズがあっていないのかも?っていう監視は不要なものなのかな

Varnish SMA Allocations

SMAとはキャッシュのために確保したメモリ(MAlloc Stevedore counters)のことです

SMFやSMUなどがあるのですが
ここではMackerelが収集対象としているSMAのみにフォーカスします
端的にいうとキャッシュを何に保存しているか?です

Varnishの起動時に指定します
今回は検証なので

VARNISH_STORAGE="malloc,256M"

RAM使用の256MiBとしました
256MのMはmebibytesです
またオブジェクトごとに1 KiBを内部構造用に使用します

指定はMiBなのにvarnishstat -1したときはByteで表示される罠があります😂

Metrics 説明 varnishstatのフィールド名
num 未処理のストレージ割り当て数 SMA.s0.g_alloc

f:id:heleeen:20180814164411p:plain

キャッシュをオンにしてアクセスして放置すると
このように増えたり減ったりしてました

Varnish SMA Memory
Metrics 説明 varnishstatのフィールド名
Available ストレージの残りバイト数 SMA.s0.g_space
Allocated 割り当て済みバイト数 SMA.s0.g_bytes

使われれば使われるほどAvailableが減っていって
Allocatedが上限になります

グラフはByte表示されます

f:id:heleeen:20180814164656p:plain

キャッシュ対象が少ないため全然使われてないですが
きっとこれからAvailableとAllocatedが戦いを繰り広げてくれるでしょう!

参考サイト

Varnishと戦い始めての感想は、6系は特に実践記事は少なく、
数年前の記事にVarnishは対応していないので・・って書いてあっても
実はもうその機能実装されてたりするので、ひたすらリファレンス見てTryErrorしてます
その合間もMackerelが見ててくれるのはモチベーションにもなりますね💪

はてなブログ映えのために何度かabコマンド叩いてるけど怒られないといいなぁ😅

vagrant vbguestはもう打ちたくなかったんだ

Versions

vagrantでsynced_folderしたくてvbguestを入れたはずなのに
reloadするとまた

# 抜粋
Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3` vagrant /vagrant
mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant` vagrant /vagrant

The error output from the last command was:

mount: unknown filesystem type 'vboxsf'

が出るを何度も繰り返して発狂しそうでした

起動ログを見るとguest additionsが入ってないって言われている

# 抜粋
==> boxName: Machine booted and ready!
==> boxName: Checking for guest additions in VM...
    boxName: No guest additions were detected on the base box for this VM! Guest
    boxName: additions are required for forwarded ports, shared folders, host only
    boxName: networking, and more. If SSH fails on this machine, please install
    boxName: the guest additions and repackage the box to continue.
    boxName:
    boxName: This is not an error message; everything may continue to work properly,
    boxName: in which case you may ignore this message.

どうやらcentos/7はデフォルトでGuestAdditionsが入っていないようだ
なんでだろう🤔

普段vagrantコマンドでしか操作しなくてGUIに戸惑ったのでログ残します

GuestAdditionインストール

対象のisoイメージを探す

Index of http://download.virtualbox.org/virtualbox から自分のバージョンのものを探して
GuestAddition.isoをダウンロード

対象のBoxにボリュームを追加してドライブとして選択

f:id:heleeen:20180713183810p:plain

GUIからVMを起動して諸々のバージョンを合わせる

合ってないとのちのち悲しい気持ちになります

$ sudo su -
# yum update -y
# reboot

## login

# yum install gcc kernel-devel kernel-header

# reboot

## ここで↓2つのバージョンが一致することを確認しておく
# uname -r
# yum list installed | grep kernel

あとはイメージをマウントしてrunして
できたイメージをpackageしてaddしちゃえばもう困ることはないね!

Appendix

but compiler support broken.
arch/x86/Makef i le:96: stack-protector enabled but compiler support broken arch/x86/Makef ile : 166: *** CONFIG RETPOLINE=y, but not supported by the compiler . Compiler update recommended.. Stop. make: *** [vboxguest] 
Error 2 Creating user for the Guest Additions, Creating udev rule for the Guest Additions kernel module.

gccをインストールする

unable to find the sources of Linux kernel.
Creating user for the Guest Additions. 
Creating udev rule for the Guest Additions kernel module. 
tmp/vbox.O/Makefile.include .header:97: *** 
Error: unable to find the sources of your current Linux kernel. 
Specify KERN_DIR=<directory> and run Make again.

kernelのライブラリとカーネルのバージョンが一致してなかった

めも

ちなみにvbguestしたときのログでも若干怪しいことは言われてました

$ vagrant vbguest

...

Complete!
Copy iso file /Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso
Mounting Virtualbox Guest Additions ISO to: /mnt
mount: /dev/loop0 is write-protected, mounting read-only
Installing Virtualbox Guest Additions 4.3.40 - guest version is unknown
Verifying archive integrity... All good.
Uncompressing VirtualBox 4.3.40 Guest Additions for Linux............
VirtualBox Guest Additions installer
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox non-DKMS kernel modules[  OK  ]
Building the VirtualBox Guest Additions kernel modules

調べるととりあえずvbguestすればいいって出てくるけど根本解決にはならないみたい

nwdiagでただサンプルを動かすまでが長かった

nwdiagというMarkdownでネットワーク図を書ける素敵ツールを見つけたので
さくっと書こうと思ったらなぜか半日かかった苦しみを残します
だからpipは苦手なんだ...

nwdiag

Markdownを書けばネットーワーク図、パケットヘッダなどGenerateできる優れもの

http://blockdiag.com/en/nwdiag/index.html

インストール方法
pip install nwdiag

http://blockdiag.com/en/nwdiag/introduction.html

実行
nwdiag simple.diag

http://blockdiag.com/en/nwdiag/nwdiag-examples.html

みたいなのがさくっとできる

Symbol not found: _clock_gettime
nwdiag simple.diag
Traceback (most recent call last):
  File "/usr/local/bin/nwdiag", line 7, in <module>
    from nwdiag.command import main
  File "/usr/local/lib/python2.7/site-packages/nwdiag/command.py", line 18, in <module>
    import nwdiag.builder
  File "/usr/local/lib/python2.7/site-packages/nwdiag/builder.py", line 18, in <module>
    from nwdiag.elements import (Diagram, DiagramNode, DiagramEdge,
  File "/usr/local/lib/python2.7/site-packages/nwdiag/elements.py", line 17, in <module>
    import blockdiag.elements
  File "/usr/local/lib/python2.7/site-packages/blockdiag/elements.py", line 19, in <module>
    from blockdiag.utils import images, unquote, urlutil, uuid, XY
  File "/usr/local/lib/python2.7/site-packages/blockdiag/utils/images.py", line 20, in <module>
    from PIL import Image
  File "/usr/local/lib/python2.7/site-packages/PIL/Image.py", line 60, in <module>
    from . import _imaging as core
ImportError: dlopen(/usr/local/lib/python2.7/site-packages/PIL/_imaging.so, 2): Symbol not found: _clock_gettime
  Referenced from: /usr/local/lib/python2.7/site-packages/PIL/.dylibs/liblzma.5.dylib (which was built for Mac OS X 10.12)
  Expected in: /usr/lib/libSystem.B.dylib
 in /usr/local/lib/python2.7/site-packages/PIL/.dylibs/liblzma.5.dylib

pipでインストールするときって
うまくいくと大喜びするくらいうまくいかない..

エラーメッセージがおっしゃる通り、使ってるMacは10.11.6で
10.12で入る何かが足りないらしい

github.com

同じようなissueは見つかるけど
OSアップデートするのは嫌だし
brew update や brew upgrade, prune試しても変わらなかった

ライブラリのバージョンを下げる

github.com

$ pip list
Package         Version
--------------- --------
Pillow          5.1.0 # アウツ

$ pip install 'pillow!=5.1.0'

$ pip list
Package         Version
--------------- --------
Pillow          5.0.0 # 下げた

$ nwdiag simple.diag # Success!

pipでハマると普通に半日吹き飛んでつらいなぁ😥

terratestで遊んだけど明日になったら忘れてるのでメモするよ

github.com

ちょっとGoを書くだけでTerraformのテストができるよっていうツール

かなり初期までのa tour of goしかやってない自分でも
さっくりできてびっくりした

準備

  • 壊れても良い環境しかないようなAWSアカウント用意
  • terraform planまでは通るTerraform書く
  • Goのインストール

いいところ

はまったところ

フォルダ構成がだめ
provider.aws: no suitable version installed

# all logs
go test terraform_test.go
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 retry.go:64: Running terraform [destroy -force -input=false -lock=false]
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:52: Running command terraform with args [destroy -force -input=false -lock=false]
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: Plugin reinitialization required. Please run "terraform init".
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: Reason: Could not satisfy plugin requirements.
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: Plugins are external binaries that Terraform uses to access and manipulate
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: resources. The configuration provided requires plugins which can't be located,
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: don't satisfy the version constraints, or are otherwise incompatible.
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: 1 error(s) occurred:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: * provider.aws: no suitable version installed
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95:   version requirements: "(any version)"
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95:   versions installed: none
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: Terraform automatically discovers provider requirements from your
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: configuration, including providers used in child modules. To see the
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95: requirements and constraints from each module, run "terraform providers".
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:95:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:99:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:99: Error: error satisfying plugin requirements
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:99:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 command.go:99:
TestTerraformHttpExample 2018-05-18T20:16:10+02:00 retry.go:72: Returning due to fatal error: FatalError{Underlying: exit status 1}
--- FAIL: TestTerraformHttpExample (0.04s)
	destroy.go:11: FatalError{Underlying: exit status 1}
FAIL
FAIL	command-line-arguments	0.045s

エラーメッセージと全然結びついてないけど
testコードが見に行くTerraformを1つのディレクトリにまとめたらいい感じに動いてくれました

# ng: 平置きがだめ
- testcode_test.go
- terraform_resources
- main.tf
- sample.tfvars

# ok: test.goにTerraformのリソースの入ったディレクトリを参照させる
- testcode_test.go
- terraform_code/
実行上限にひっかかる
*** Test killed with quit: ran too long (10m0s).

S3 + Cloudfrontなstaticホスティング構成立ててhttpリクエストさせてのテストがタイムアウトした・・・
なんかあかんみたいね・・・
明日なおそ・・・・

Rspecみたいに実行状況を何も書かなくても吐いてくれたらいいのになって思ったのと
エラーがまだ人間に優しくないのかも(ドキュメントを読んでなさすぎるのも大いに有りすぎると思う)と思いました。

テストにそれなりに時間がかかるけどちゃんと書けば楽しそう
ちゃんと書けばね!

dentryキャッシュ対応に悩まされた話

原因は完全にこれ↓で

tools.knetik.io

要約すると、余裕がある時はめっちゃcurlしてキャッシュするっていう機能があって
放置するとmemoryをどんどん使っていくので
nss-softokenを3.16以上にしてオプション有効にしようね、という話

Bug 1044666 – Can curl HTTPS requests make fewer access system calls?
でも報告されていて、NSS_SDB_USE_CACHEをYESかNOにすると
sdb_measureAccessを呼ばなくなるらしい

自分のところではswap領域を使わないまま
約24時間でusedが7GB弱増えていました

export NSS_SDB_USE_CACHE=YES

を/etc/sysconfig/httpdに追加して経過観察してたけど全然効き目がなく
適当に設定をNOにしてみたり無意味に大文字小文字を変えてみたりの無駄な手順を試したけど当然効かず
でも放置するわけにもいかないので毎日dentryキャッシュを削除していました

f:id:heleeen:20180223021506p:plain

↑ キャッシュを削除する日々の図
最初はアラートで呼ばれたので対応して、
次の3回くらいはアラートを飛ばさないためにキャッシュ削除しただけで
その後は設定を入れてもうまくいかない戦いです
すごい徒労感があるね!

諸々のバージョン

$ httpd -V
Server version: Apache/2.4.25 (Amazon)

$ sudo yum list nss-softokn
nss-softokn.x86_64              3.16.2.3-14.4.39.amzn1 

$ curl -V
curl 7.51.0 (x86_64-redhat-linux-gnu) libcurl/7.51.0 NSS/3.28.4 

やってたこと

NSS_SDB_USE_CACHE=yesが効きそうか見る

access回数が減るので効果はあるはずなのに
apacheを再起動して数時間待つとなぜかメモリ消費してた
See. アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog

$ strace -fc -e trace=access curl 'https://www.google.com' > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000065           0      1626      1622 access # ここがおかしい
------ ----------- ----------- --------- --------- ----------------
100.00    0.000065                  1626      1622 total

$ NSS_SDB_USE_CACHE=yes strace -fc -e trace=access curl 'https://www.google.com' > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0        32        30 access # 効いてる
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                    32        30 total

# noでもこれくらい
$ NSS_SDB_USE_CACHE=no strace -fc -e trace=access curl 'https://www.google.com' > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   272  100   272    0     0   1786      0 --:--:-- --:--:-- --:--:--  1789
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0        58        56 access
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                    58        56 total

オプションをつけずにcurlすると何度もaccessされるのがわかる

$ strace -e trace=access curl 'https://www.google.com' > /dev/null
...
access("/$HOME/.pki/nssdb/cert3.db", F_OK) = -1 ENOENT (No such file or directory)
access("/$HOME/.pki/nssdb/cert2.db", F_OK) = -1 ENOENT (No such file or directory)
access("/$HOME/.pki/nssdb/key3.db", F_OK) = -1 ENOENT (No such file or directory)
access("/$HOME/.pki/nssdb/key2.db", F_OK) = -1 ENOENT (No such file or directory)
access("/$HOME/.pki/nssdb/secmod.db", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/pki/nssdb/.3550898456_dOeSnotExist_.db", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/pki/nssdb/.3550898457_dOeSnotExist_.db", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/pki/nssdb/.3550898458_dOeSnotExist_.db", F_OK) = -1 ENOENT (No such file or directory)
...
設定反映されてないのかな

環境変数を見ると入っているのになぁ・・って思ってました

$ sudo od -S1 -An /proc/4057/environ # httpd
TERM=xterm
PATH=/sbin:/usr/sbin:/bin:/usr/bin
PWD=/
LANG=C
SHLVL=2
NSS_SDB_USE_CACHE=YES # ここ
_=/usr/sbin/httpd
直線で増加していくのっておかしくない?

httpdが原因ならアクセス数に比例するはずなのに
直線で増加していくのっておかしくない?ってようやく気づきました

内部でずっと動いてくれているものにすごく心当たりがあって・・・
出来心で/etc/sysconfig/mackerel-agentにも同じ内容追加して
エージェント再起動したのがこちら

f:id:heleeen:20180223153718p:plain

キャッシュ増加が止まったのがはっきりわかって
嬉しくて思わずslackにも流してしまったやつ

最初のブログにもhttpd以外にも必要なら入れてね!って書いてあったのに!!
逆にhttpdからその環境変数外すとどうなるんだろうと思って外したら
増加の仕方はとてもゆっくりという結果になりました・・
アプリケーションの負荷ェ.....

他のメトリックにも特に影響は見られなかったので
ひとまずは解決で良さそうだけど
特定プロセスに対してしか設定してないから
たとえばサーバ内でcurlされるとキャッシュは増加するまんま・・・(。ŏ﹏ŏ)
他にそういうツールとかいれたらまた同じことが発生するなぁ・・