勉強会, 小ネタ, 雑談

3月から定期的に部内勉強会を開催しています。
今年開催した勉強会のお題目は以下(開催日時順)。

  • DOM →関連記事
  • ベアメタルサーバの構築自動化
  • NTTグループとソフトバンクグループ
  • JSON
  • KVM
  • PerconaDB
  • CloudStack
  • 大規模メールシステム
  • Kibana + ElasticSearch + Fluentd
  • LVSクラスタの構成と動作原理
  • QFabric
  • 囲碁のお勉強 →関連記事
  • ネットショッピングシステムの仕組み
  • DNS勘所
  • フローコレクタ
  • RADB、IRR
  • ブレードシステム
  • JANOG34振り返り →関連記事
  • Javascript、CSS
  • 大規模障害の振り返り
  • MySQL
  • 小学生にもわかるSDN →関連記事
  • CentOS7
  • ガンダムの歴史 その1
  • GlusterFS
  • いけてないIPv6とどう付き合うか →関連記事
  • DMMコンテンツダウンロードシステム
  • ディズニーについて
  • oVirt

この中の

  • GlusterFS
  • DMMコンテンツダウンロードシステム
  • QFabric

などは、あまり他では使われていない技術なので、ちゃんとこのブログで発信しなきゃいけないとは思うのですが、記事を書くのをさぼっててすみません。

ただ、著作権の関係で資料を公開できないものもあるんですよね。このへんですね。

  • ガンダムの歴史 その1
  • ディズニーについて

ガンダムの歴史では、宇宙世紀の始まりから1年戦争の終結までにあったことを、アニメ、漫画、小説、ゲーム等の膨大な資料から引用しつつお勉強。
ジャブロー上陸作戦はジオンの特攻だったんですねえ。
来年は1年戦争以降から勉強すると思われます。

ディズニーのお勉強もディープでした。
TDRのあちこちで売っているチョコクランチの味は同じじゃない、とか知ってました?
缶の裏を確認すると製造メーカーがわかるんですよ。
実食もおいしかった。
来年も実食付きの勉強会があると良いなあ。

 

今後も勉強会を続けていきたいと思っています。
一緒に楽しく勉強したい方は是非join↓してくださいませ!!

DMM.comラボ採用情報
http://labo.dmm.com/recruit/

それと出張勉強会の要望があれば気軽に言ってくださいね。

hardware, linux, 小ネタ, 運用管理

艦これ」といえばDMMのゲームと言われるほどにまでなりましたが、「城コレ」が今度は控えているようです。約30万人の方が事前登録してくださったという嬉しい悲鳴がところどころで聞かれます。そしてツチノコ部隊も全体の安定稼働へ向けて色々と対応しています。ところで、こういうオンラインゲームは、可愛いキャラクターもさることながら、ブラウザの裏でインターネット越しに必死に動いている「黒子」のようなものたちがいます。いわゆる「ゲームサーバ」と呼ばれるものです。

ゲームサーバは、その基本構成としておおまかに「アプリ(フロント)サーバ」と「データベース(バックエンド)サーバ」に分かれます。今日はその中でも「データベースサーバ」についてのお話です。

DMMでは大抵のデータベースサーバにLinuxとMySQLを使っています。そのデータベースエンジンにInnoDBというのがありまして、設定項目としてメモリ上にバッファをするという設定を行うことができます。

例えば、メモリを128GB搭載したサーバでバッファ用に100GBのメモリを割り当てるとします。さて、実際のメモリの割当はどのようになるでしょうか。最近のXeonを搭載したサーバとして考えてみます。実はCPUの個数により、そのメモリの割り当てられ方が変わってきます。というのも、昔と違い今はメモリのコントローラがCPUに内蔵されているからなのです。

  • シングルCPU構成の場合

すべてのメモリがCPUと直接つながっているので、特に気にする事はありません。

  • マルチCPU構成の場合

CPU0とCPU1…とにそれぞれメモリがつながっています。例えば先ほど128GBとしたメモリが2CPU環境にあるとしましょう。そうするとCPUにごとに64GBのメモリがつながっている事になります。標準ではLinuxはプロセス毎にそのプロセスが動いているCPUにつながったメモリを利用しようとします。つまり、先ほどの100GB割り当てが、MySQLのプロセスが動いている片方のCPUに偏ってしまうのです。その結果、片方のメモリがMySQLに食いつぶされ、そこにもともといたデータがSWAPに吐き出されます。もう片方のCPUにつながっているメモリに空きがあっても、です。

少し詳しい話にしましょう。最近の共有型のマルチプロセッサシステムアーキテクチャは、NUMA(Non-Uniformed Memory Access)というものです。これは、CPUとメモリのまとまりを「ノード」と呼びます。先の例では、CPUと64GB分のメモリのまとまりが”ノード”です。

Linux OS上でプロセスが起動すると、そのプロセスはCPUに割り当てられます。CPUとメモリがまとまっているので、プロセス自体のデータは同じNUMAノードのメモリに置かれます。
先の例の2CPUの環境MySQLが起動したあとメインスレッドがCPU0に割り当てられたとして、そのCPUにぶら下がる64GBのメモリにMySQLのデータが置かれます。しかし、バッファデータのサイズだけで100GBあるので、NUMAノードの64GBをいずれ食いつぶします。そうなると、同じNUMAノード上にある他プロセスのデータがメモリから溢れます。他NUMAノードのメモリはデフォルトではOSが割り当てをしない状態になっているため、あふれたものはスワップへ送られます。もともと64GBのメモリ上にあるものなのでスワップアウトするデータ量も大きくなる傾向があります。なので実際のところスワップが埋まってしまう可能性が非常に高いです。

では、どうすればこの偏りやスワップアウトを抑えることができるのか。

NUMAをOSからコントロールするnumactlというコマンドがあります。
–interleaveオプションは割り当てるNUMAノードを指定します。上記の例では”all”となっているため、すべてのNUMAノードに割り当てを行うことを意味します。

こちらのコマンドで、NUMAに対するプロセスの状況が見られます。
とはいえ、見るのは大変なので、下記のページを参考に、Perlスクリプトを使ってみましょう。
http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
numa-maps-summary.pl というスクリプトです。って、実はこれ2010年の記事なんですよね。知りませんでした。

実際にスワップアウトしてスワップを喰い潰してしまったサーバがこちら

同じサーバで、numactlを設定したのがこちら

設定前はNUMAノード分の64GBに近く偏っていたものが、設定後は分散されているのがわかります。
上記のようにプロセスがどかっと大きなメモリを割り当てることでスワップアウトしてしまう現象を”Swap Insanity”といいます。
そして先のブログ記事にもありますが、mysqldのinitスクリプトを改造して、numactlを埋め込んでしまうという手を使うことで、回避ができます。

インフラ全般, 小ネタ

はじめまして。3月に入社した年寄りの新人です。

小ネタとしてツールを作ってみましたので紹介します。

Webサーバの応答がちょっと遅いな?とか思ったときにどこで引っかかっているのか大まかにでもわかると切り分けの役に立つと思います。muninのプラグインとしてすでにhttpingプラグインがありますが、もっと細かな情報が知りたいこともありますよね?今回はcurlの-wオプションを使ってmuninのプラグインを作ってみました。curl の-wオプションは以下のように使います。

$ curl -s -o /dev/null -w “%{time_namelookup}\n” http://www.dmm.com

とすると名前解決にかかった時間を表示してくれます。詳しくはマニュアルを参照して頂くとして使える変数と大まかな意味を図示するとこんな感じです。

これClipboard01

コマンドで返される値を使ってmuninのプラグインを作りました。作成にあたっては先ほどのhttpingプラグインを参考にさせていただきました。大変感謝しております。このプラグインを使い色々なページのレスポンスを見てみるとどこに時間がかかっているかわかります。(チェックは5分に1回なので許してね)。こちらは比較的軽いページの結果です。

www.dmm.com

こちらは上に比較すると画像データが多く、表示に少々時間のかかるページです。

www.amazon.co.jp

いかがでしょう?プラグインのソースは以下のようなものです。

このプラグインはmunin-nodeから実行されます。

  • チェック対象のURLはhttp://www1.example.co.jp/, http://www2.example.co.jp/
  • muninのプラグインの置き場所は/usr/share/munin/plugins/以下
  • muninの設定ファイルは/etc/munin/以下

という条件では以下の設定で使えるようになります

  1. プラグインの置き場所の/usr/share/munin/plugins/に 上のプラグインをhttpresp_curl_ のような名前で置いて実行属性を与えておく
  2. /etc/munin/plugin-conf.d/httpresp_curl というファイルを作る。内容は以下の通り
  3. /etc/munin/plugins/ 以下にプラグインへのシンボリックリンクを作る。シンボリックリンクの名前はhttpresp_curlで[ ]の中に記述した名前にする。

以上です

コマンド, 小ネタ

pingでsearchをかけるといろいろと出てくるpingライクなコマンド

みんなどんな役割を持っているんだろうか。

いわずと知れたpingのように各プロトコルで応答の確認を行うコマンドであり、

fping,httpingなど監視ツールと組み合わせて利用されることも多いんだと思いますが、

普段使いできそうなコマンドはあるのでしょうか。

さっそく、調べてみました。

fping:
複数のipにping
ioping:
簡易的なディスクレイテンシーモニタリング
omping:
マルチキャストとユニキャストで応答確認
hping:
icmp,udp,tcpなどいろんなパケットを生成し応答確認
arping:
イーサネットレベルの応答確認
2ping:
特定の2ホストでどちら側のホストに問題があるのか確認できる。
httping:
httpレスポンス詳細が確認できる。

結果、下記の三つのコマンドは覚えておいても損はないかなと思いました。

一つずつ確認していきます。

  1. httpingはウェブサーバで遅延しているときにどの部分で遅延が発生しているのかが確認できる。
  2. arpingはipバッティングがないかどうかの確認ができる
  3. iopingは実運用下の中でディスクのレイテンシーの悪化状況を確認できる。

1.httping

名前解決が完了するまでの時間
+サーバへ接続するまでの時間
+リクエストがサーバに受け付けられるまでの時間
+サーバが最初のデータをスタートするまでの時間
+データの転送が完了しコネクションがクローズされるまでの時間
=合計

がわかります。

これでどこの部分で遅延が発生しているのかが具体的にわかるようになります。

2.arping

このようにIPのconflictの確認が可能です。

このコマンドを運用に組み込んでIPバッティングを防いだりできます。


3.ioping

このように実稼働環境においてレイテンシーの変化を確認し増強のタイミングを見極めることができます。

ちなみに、pong2というOpenGLを利用した3Dゲームがあります。

3Dのピンポンゲームです。aptでサクっと入ります。画面はこんな感じ^^

pong2

linux, コマンド, 小ネタ, 運用管理

ifconfigを含むnet-toolsが非推奨になって久しいようですが、

rhel7系からnet-toolsはおさらばとなります。
※手動で入れれば使えますが。

今思えば、ifconfig君

あなたと出会ってからこの十数年、あなたを打たなかった日はありません。

雨の日も風の日もいつも一緒だったね。

あなたがいつもいてくれたから私も輝けたんだといます。

これから私は新しいiproute2君と歩んでいくことになりますが、あなたのことは決して忘れることはないでしょう。

ifconfig君に幸あれ

P.S.
ついつい ifco[tab]ってやっちゃうのはご愛嬌です。

ということでnet-toolsとiproute2の対応表一覧です。自分の備忘録として残しておきます。

net-tools iproute2
ifconfig ip l (ip link)
ifconfig -a ip a show (ip addr show)
ifconfig eth0 up ip link set eth0 up
netstat ss
netstat -i ip -s link
netstat -l ss -l
netstat -r ip r (ip route)
route [add|del] ip route [add|del]
route -n ip route show
arp -n ip n (ip neighbor)

heartbeat+pacemakerなどで利用する仮想IPはipaddr2を利用しています。

そもそもifconfigではこのコマンドで設定されたIPは表示されません。rhel6系であってもip addr showで確認しなくてはいけません。

開発、オペレーションする側みんながこの違いを認識し共有することがミスを防ぐことになります。

PAGE TOP