AWSのDNSスロットリングの対応
overview
上記の事象に遭遇したため忘備録です。
ドキュメントにも
DNS quotas Each EC2 instance limits the number of packets that can be sent to the Amazon Route 53 Resolver (specifically the .2 address, such as 10.0.0.2) to a maximum of 1024 packets per second per network interface. This quota cannot be increased. The number of DNS queries per second supported by the Amazon Route 53 Resolver varies by the type of query, the size of response, and the protocol in use. For more information and recommendations for a scalable DNS architecture, see the Hybrid Cloud DNS Solutions for Amazon VPC whitepaper.
1 ENI あたり 1024 パケット/秒 と記述がある。
そのため、dnsmasq を利用し、（ネットワーク経由で DNS リゾルバーを利用せずに）ローカルキャッシュ（ttl=60s）を利用して応答するように対応した。
五等分の花嫁を読んで印象的だった言葉とシーン
友人の薦めの五等分の花嫁を読んだので、個人的に印象に残った言葉を記録してみる。
心に響くようなシーンが多かったが個人的には、人が頑張ったことを素直に認めてあげるこの言葉が特に印象に残った。
「お前達5人は、おそらく元は同じ身体能力だったろ、五つ子だし。だったらあの運動能力は、四葉が後天的に身につけたものだ」 「遊びで何言ってんだって話だけどさ、その努力を否定したくない」 「全員平等もいいが、そこに至るまでを否定しちゃいけない。平等じゃなく、公平にいこうぜ」
先程のツイートに、誤字があったのでもう一度ツイートします！五等分の花嫁で、心に残った言葉をリプで教えてください！自分はフータローの言った「平等じゃなく公平にいこうぜ」です！いいねやリツイートしてくれると嬉しいです！ #五等分の花嫁好きな人と繋がりたい #拡散希望RTお願い致します pic.twitter.com/cu4kPbQXhL
— ドラクエウォークに目覚めたバカです (@Nino_Pippy) 2019年8月27日
でも良く考えるとおかしいこと言っていて
足の早い四葉に荷物を持たせるハンデは、公平 にあたる行為で、平等 ではない。
平等 であれば全員同じ荷物を持たせることになる。
なので最後の 「公平 にいこうぜ」は、四葉に荷物を持たせるなどのハンデを強いるってこと？（言いたいことが逆だと思うが...）名言なだけに少し残念。
あとは、間違えられないように付けていたリボンから開放されるシーンは救われた感じがして本当に良かったTT
〈ネタバレ注意〉
— あんたい (@anneentai) 2020年2月18日
風太郎に見分けてもらうためにつけたリボンを自分から捨てる。
四葉も成長したな。#五等分の花嫁 pic.twitter.com/FbyJ2XYIdH
初回ヒロインだと思っていた子が参戦しないとか難聴系主人公ブレーカーなど斬新で面白かった。
二乃さん、難聴系主人公ブレイカーになった代わりに自分が難聴系ヒロインになってしまう()#五等分の花嫁 pic.twitter.com/77ODGM3tWH
— ゴ ロ (@goro_012345) 2019年7月16日
今日でイベント最後だったけどもう少し早く漫画を読んでいれば行きたかったな。
apache confのallowの後ろにコメントを書くと逆引きされる
overview
掲題の通りなので、apache confのallow/denyの後ろにコメントを書くとパフォーマンス劣化に繋がる。
内容
以下のようにconfを書いたとしても「Allow」のディレクティブが複数の値を取得する過程で、コメントをホスト名として扱ってしまう。
allow from 10.0.0.0 # comments
正しくコメントを残したければ以下のように設定する必要があった。
# comments allow from 10.0.0.0
Directives in the configuration files are case-insensitive, but arguments to directives are often case sensitive. Lines that begin with the hash character "#" are considered comments, and are ignored. Comments may not be included on the same line as a configuration directive. White space occurring before a directive is ignored, so you may indent directives for clarity. Blank lines are also ignored.
ドキュメントにも「#」で始まる行はコメントとして見なされ無視されると書いている。 パフォーマンス劣化を起こさないためにもコメント一つとっても気をつけないといけない。
以下、参考にした記事。
IPC::Open3 / system()の挙動
Whitespace and IPC::Open3 / system() When using IPC::Open3 or system, if you provide a string as the command argument, it is assumed to be appropriately escaped. You can use the QUOTE constant to use as a portable quote character (see above). However, if you provide an array reference, special rules apply:
制約で引数をスカラで与えた時と、リストで与えた時の処理が変わってしまう。
LIST に複数の引数がある場合、または LIST が複数の要素からなる配列の場合、 リストの最初の要素で与えられるプログラムを、リストの残りの要素を引数として 起動します。 スカラの引数が一つだけの場合、引数はシェルのメタ文字をチェックされ、もし あればパースのために引数全体がシステムコマンドシェル (これは Unix プラットフォームでは /bin/sh -c ですが、他のプラットフォームでは 異なります)に渡されます
そのため、リストの場合はシングルクォートなどで囲まないと意図した動作にならない。
cmd -o 'mode arg' -o 'fuga'
dentry_cacheの肥大化によるメモリ圧迫
Overview
dentry_cache が徐々に肥大化していきslab cacheを肥大化させメモリを圧迫していた。
内容
アラート対応でメモリ逼迫の原因調査を行なった。
サーバのメモリがcacheで占有されていることを確認した。 slabtopでキャッシュサイズ順にソートしdentryが上位の殆どを占めていることを確認した。
$ slabtop --once --sort=c | head -n 12 Active / Total Objects (% used) : xxxxxx / xxxxxx (97.3%) Active / Total Slabs (% used) : xxxxxx / xxxxxx (100.0%) Active / Total Caches (% used) : 96 / 181 (53.0%) Active / Total Size (% used) : xxxxxx / xxxxxx (98.3%) Minimum / Average / Maximum Object : xxxx / xxxx / xxxx OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME xxxxxx xxxxxx 99% xxxx xxxx 20 xxxx dentry xxxxxx xxxxxx 96% xxxx xxxx 4 xxxx ext4_inode_cache xxxxxx xxxxxx 95% xxxx xxxx 37 xxxx buffer_head xxxxxx xxxxxx 95% xxxx xxxx 7 xxxx radix_tree_node xxx xxx 100% xxxx xxxx 1 xxxx kmem_cache
dentryについてよく知らなかったため調べてみると
ファイル名やディレクトリの階層構造の管理を行い、それらの情報をキャッシュ管理してくれるとのこと。
記事上での性能テストだとdentryキャッシュがあることで、ファイル検索などの実行時間が200倍以上変わるとのことで、かなりパフォーマンスに影響があることがわかる。 （メモリに問い合わせるか、HDDに問い合わせるかでだいぶ変わるため）
今回はこれらのキャッシュ情報は一時的に解放して問題なかったためdentryを解放することで対応を行なった。
$ sudo sh -c 'echo 2 > /proc/sys/vm/drop_caches'
その後freeコマンドでメモリ使用量が空いたことを確認した。
