とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。 そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。 22.38% [kernel] [k] copy_pte_range 18.44% [kernel] [k] zap_pte_range 11.13% [kernel] [k] change_pte_range 3.58% [kernel] [k] page_fault 3.32% [kernel] [k] page_remove_rmap また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。 sudo strace -T -o/dev/stdo

ここ2、3年で目標としていた、IEEE Computer SocietyのFlagship Conferenceの一つとされているCOMPSAC 2020のメインシンポジウムに、ファーストオーサの論文がフルペーパーで採録されました。 送られてきたメールによると、今回のメインシンポジウムのフルペーパ採録は24%以下ということで、昨年の250本程度の投稿論文があることを考えると、全体のフルペーパ採録は60本程度になるかと予想できます。去年はCOMPSACのメインシンポジウムにショートペーパとしてファーストオーサの論文が1本採録、ラストオーサの論文がショートペーパで1本、併設ワークショップに1本という実績でした。 さらに、2年前は未だに当時のショックを覚えているぐらいに、メインシンポジウムでの査読でフルボッコの査読結果を頂き、なんとか気を持ち直してワークショップに通すことができた、ぐらいの実績で

研究アイデアや構想の公開 まつもとりースタイルとして、研究開発をしつつあいであがまとまってきたら公開しながらやっていくスタイルをとっていますので、国際会議などの延期に伴い、新しい研究をやり始めているのでそれをアイデアや構想ベースで公開します。 また、僕の研究のやり方として、まずはこのように考えて研究を組み立てているんだという紹介でもあります。是非ご笑覧下さい。 本研究のアイデア紹介 単一のOS環境に複数のテナントを配置するようなマルチテナント環境において、一般的に各テナント間での権限分離はプロセスのオーナやパーミッション情報を利用します。 一方で、Webホスティングサービスをはじめ、Webサービスにおいてもコンテナによって処理を担当するプロセスの権限分離が普及している状況において、データ処理に関しては、複数の異なるオーナのプロセスがデータベースのようなミドルウェアをネットワークを介して通信

自分がこれまでの人生で、自分では予期できないけれど、そのおかげで人生が大きく変わり今の自分がある、そして今もなおその流れに乗り続けられている、そんな「たったひとつの乗るべき電車」とはなんだっただろうか。 今月で自分は35歳になるわけだが、なんとなく自分の人生の折返し地点間近に来ているという感覚がある。 そこで、まだまだ35年という短い人生でありながらも、そこそこの今の自分がある、そのために自分が乗るべきだった「たったひとつの電車」について振り返ってみた。 小学3年生から漠然と中学受験の勉強の波に飲まれ、右も左もわからないまま、気がついたら大学に来ていたように思える。 その過程では、自分が乗るべき電車があったかどうかすら気がついていなかっただろうし、ひょっとすると何度か電車が来ていたかもしれないが、そのことすら気づかずボーッとしていたように思える。 ただ周りが勉強するから、親が勉強を促してく

本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。 現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。 2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。 レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やア

Webサーバのベンチマークをとるのが趣味になりつつあるmatsumotoryです。 Webサーバのベンチマークについては、abからはじまりwrk等を使っていたのですが、最近ではほぼh2loadを使っています。 h2loadはnghttp2というHTTP/2ライブラリのアプリケーションに含まれているツールですが、 HTTP/2（SPDYも）とHTTP/1.xに両対応している ベンチマーク側の同時スレッド数を増やせる TLS及びSNIもサポートしている 最小、最大、平均、標準偏差あたりもちゃんとでる ので、色々プロトコルを変えつつ同じベンチマークツールで、値の目安を出すにはとても重宝しています。 Nghttp2: HTTP/2 C Library - nghttp2.org 実行結果のサンプルは例えば以下、 $ h2load -c 100 -n 10000 https://localhost:

こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ

写真のような感じでRubyKaigi2018で登壇し、RubyKaigiを経て、ようやくngx_mrubyのv2をリリースしました。基本的にv1と互換性がありますので、今後はv2を開発していくことになります。 github.com ngx_mruby v2の目玉機能としては、Rubyスクリプトからノンブロッキングのsleepとhttp[s]クライアントを使えるようになったことです。実装的には、nginxのsub requestという機能をうまく使って、ノンブロッキングのhttp[s]クライアントを汎用的なsub_requestメソッドとして実現しています。 では、本エントリではそのノンブロッキングhttpクライアントがどの程度高速処理可能になったかを実験してみましょう。また最後には、RubyKaigi2018の感想も述べます。 実験 proxyサーバのblockingとnon-blocki

第二回Web System Architecture研究会で、タイトルの内容について発表してきましたので、そのスライドと予稿を以下に公開します。 speakerdeck.com 英文タイトルは以下の通り。 Fast Scheduler for a Cloud Platform to Relocate Containers at Each HTTP Request クラウドサービスの普及に伴い，個人のWebサイトでもクラウドサービスに類する機能を利用して，突発的なアクセス集中に耐性があり，かつ，利用したリソース使用量に応じて課金するサービスの提供が求められている． 我々はその要求に応じるために，Webサイトをコンテナ上に構築し，コンテナの起動や停止，複製やリソース割り当てといった状態の変更を素早く実行できるコンテナ管理アーキテクチャFastContainerを提案した． 一方で，単一のコンテ

今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ

ある日、今年は研究開発活動を国際化していくぞ、と意気込んで出した国際会議のreject通知が届いた。そして、その内容も4人の査読者からフルボッコであり、特に英語がなっていないということをかなり強い言葉で指摘されていた。そんな通知をもらった僕は、かつてないほどの悔しさと後悔を感じたのであった。過去に何度か国際会議通していたこともあり、これぐらいでいいだろうとタカをくくって舐めていた、手を抜いていた面もあったからだ。 その1週間後の4/10に、国際会議のワークショップ締め切りがあり、指摘を直してそれに出してみてはどうかとreject通知に書かれていたのだが、その4/10は自分の別の論文1本と共著の2本の合計3本の論文締め切りと同じ日であり、これは流石に無理だと諦めたのであった。きつい。 精神的にも落ち込んでいたし、今年は国際化やっていくぞ！と思っていた矢先の出来事で、なかなか立ち直れなかった。

僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた

2018年4月にngx_mrubyのノンブロッキングHTTPクライアントとノンブロッキングsleep相当のメソッドに対応させてngx_mruby v2.0.0をリリースするという目標を立てた— 松本 亮介 / まつもとりー (@matsumotory) 2018年2月13日 ngx_mrubyのv2の4月リリースに向けて、HTTPリクエスト単位で実行されるRubyのコードを、FiberとProcで包んだオブジェクト経由で実行する実行方式に実装しなおしています。これまでのngx_mrubyのv1系は、Rubyのコードをnginx起動時にstruct RPocにコンパイルしておき、リクエスト毎にそのバイトコードを実行していました。 一方v2では、nginx起動時にコンパイルされたstruct RProcを、HTTPリクエスト時にprocオブジェクトに変換した上で、そのprocオブジェクトをca

以前、メール送信（SMTP）サーバの振る舞いを制御するために、mrubyで機能拡張できるpmilterというMilterプロトコルベースのミドルウェアを作りました。 hb.matsumoto-r.jp その流れで、メール受信（POPやIMAP）サーバの振る舞いも同様に制御することによって、トータルでメール送受信システムの流量制限だけでなく、アクセス制御や不正な認証の検知、DoSのようなアクセスや大量メールの送受信をうまくプログラマブルな設定を書くことによって解決していきたいと思いはじめ、昨日からpmilterだけでなくメール受信サーバの開発にも取り組みはじめました。 それらのメール系ミドルウェアを組み合わせることにより、既に使われているメールの定番ミドルウェア（Postfixやdovecot）はそのままに、平易に導入できて、性能を落とすことなく自由にRubyで拡張ができるようになる基盤を作

単純に特定のURLに対してミドルウェアの性能を計測したい場合などには、今でもabやwrk、h2loadのようなシナリオベースではないシンプルなベンチマークはとても有用です。 一方で、最近ではgatlingやtsungといった、豊富な機能やリッチな計測結果を取得できるベンチマークソフトウェアも豊富になってきました。 ただ、例えば、単に「Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測したい」時に、僕のようなめんどくさがりの人間はcliで適当にオプションを渡して1回の実行でシュシュシュっと取りたいものですが、それができるツールが見当たらず、うーむ、gatlingやtsuningでやるかなぁとおもっていたところ、なんとApache Bench(ab)で簡単にシュシュシュっとできてしまうことに気づいたのでした。 ということでその方法を紹介します。例えば以下のような要件の時に

Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ