サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
blog.etsukata.com
はじめに Memcached を運用中に、Request の傾向は変わっていないにもかかわらず、徐々に Item 数が増加し始め、 ある時を境に Item が 一切 Eviction/Expire されなくなり、Memory が枯渇し Slab OOM Error が起こる、という不具合に遭遇しました。不具合の原因については特定し、1.4.29 で修正がマージされました (Pull-Request: fix zero hash items eviction , ReleaseNote1.4.29) 。不具合が発生する条件、原因、回避策を簡単にまとめておきます(Pull-Request にはより詳しく書いてあります)。 不具合が発生する条件 Memcached Version : 1.4.19 から 1.4.28 SET した Key を GET しない場合がある Item を入れ替える C
はじめに 会社で PB 級の Hadoop クラスタを運用していますが、ある日から Datanode の CPU system (Kernel 内での CPU 使用率) が高騰し、Job が遅延するという症状が発現しました。Hadoop で CPU system 高騰というと、 Transparent HugePage 設定が有名ですが、そちらについては既に特定し、対策済みでした。 THP と Hadoop に関係については下記 Blog が詳しいです。 Transparent Huge Pages and Hadoop Workloads 今回は THP ではなく、 "zone_reclaim_mode" の設定による性能劣化について、現象から原因特定に至るまでの経緯と、推奨する設定について解説します。 現象 観測された現象について簡単に箇条書きします。 CPU user が 5% 程度
完全順列(撹乱順列とも)とは順列を置換と見た場合、不動点をもたない置換のことをいいます。順列の要素数を無限大にした極限をとったとき、完全順列の個数(モンモール数)とすべての順列の個数(n!)の比が1:e(eは自然対数の底)になり、世の中の物好きを惹きつけています。 前回のN-Queens問題につづいてlist monadを利用して関数型言語のHaskellで完全順列を生成するコードを書いてみましょう。 *Main> derangement ['c','o','n','s'] >>["ocsn","onsc","oscn","ncso","nsco","nsoc","scon","snco","snoc"] こんな感じになって欲しいのです。順列を生成した後にfilterを掛けるのは非効率的なのでやめておきます。 書いてみると以下のようになりました。 import Data.List dera
はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。
はじめに Linux にはブロックするシステムコールとノンブロックなシステムコールがあります。さて、システムコールが「ブロックする」とはどういうことでしょうか。よく、ブロックするシステムコールとは「処理が完了するまでプロセスの動作が中断され待たされること」という説明を見ますが、より詳細に、どういう処理の場合に待たされるのか、整理してみましょう。 「ブロックする」とは Linux において、システムコールがブロックするとは、「プロセスが、システムコール呼び出しの延長で待状態(TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE) に遷移し、CPU時間を消費せずにあるイベントが完了するのを待つようになる」、ことを指します。ブロックするシステムコールのうち代表的なものと、完了待ち対象イベントをまとめると、以下のようになります。 システムコール待ち対象イベント re
はじめに Docker はコンテナ型仮想化技術を使ってOSレベル仮想化を実現するコンテナ管理ソフトウェアです。類似のコンテナ管理ソフトとしては、Docker の他にも libvirt、 lxc-tools などがありますが、 Docker には以下の大きな特徴があります。 Infrastructure as Code の思想に基づき、コンテナをコード(Dockerfile) で管理できる docker index で、コンテナイメージを手軽に取得、共有できる Docker は上記のような特徴を持つため、アプリケーションのポータビリティを大きく向上させることができると期待されています。 参考:Naoya Ito 氏 "Dockerアプリケーションのポータビリティを考える" 大変便利な Docker ですが、Docker によるコンテナ管理は、実は数多くの Linux Kernel の機能に
以前、Docker をビルドしていて、以下の事実に気づきました。 事実: Docker は自身をビルドするのに Docker を用いてコンテナ内でビルドしている 実際、ソースコード直下に、以下の Dockerfile が置いてあります。中を参照すると、ubuntu のコンテナイメージをベースに、依存するソフトウェアを apt-get したり、git clone で取得したりしています。make コマンドで、依存するソフトウェアをインストールしたコンテナ内で、hack/make.sh を実行し、バイナリを作成します。生成したバイナリをコンテナから取り出してビルド終了となります。 Docker は Golang で書かれていますが、その理由の一つに、Golang の優れたポータビリティ (libc が入っている環境であればどこでも動作するバイナリを手軽に生成できること)があります。これにより、
Erlang の実行環境である BEAM の動作を理解するため、BEAM のスレッド構成を調査しました。 BEAM は SMP(マルチコア) 環境と非 SMP 環境では動作が大きくことなります。SMP環境と非SMP環境に分けてスレッド構成を記載します。 調査対象の OTP のバージョンは R16B03-1です。 非SMP環境 Erlang Interactive Shell を起動する際に、オプションとして '-smp disable' を付与すると、CPUはSMPでも、BEAMとしては非SMPモードで起動できます。 'erl -smp disable' で起動すると、11個のスレッドが見つかりました。11スレッドの内訳は以下のようになります。 スレッド名関数名個数 Main Threadprocess_main1 Async Threadasync_main10 Main Thread
Netperf は iperf と並ぶ多機能ネットワークベンチマークソフトです。 Netperf を使って latency(RTT: Round Trip Time) を測定する方法についてまとめました。 omni-test による latency 測定 最近の netperf は "omni-test" による測定を行うのが一般的のようです。 omni test で latency を測定しましょう。 ここで、latency とは送信サーバと受信サーバでパケットが往復するのにかかる時間(RTT)のことを言うとします。 まずは受信側で受信準備します。 # netserver 送信側で UDP で RTT を測定するコマンドを発行します。 # netperf -t omni -H localhost -- -d rr -T UDP -k MIN_LATENCY,MEAN_LATENCY,P9
はじめに Erlang/OTP で開発したアプリケーションは、通常 BEAM (Erlang VM)と呼ばれる仮想マシン上で動作させます。BEAMに関する資料は、今のところ世の中にあまり多くないようです。BEAMの情報が得やすくなるよう、ここにまとめておきます。 BEAM(Erlang VM) 参考資料 Hitchhiker’s Tour of the BEAM Erlang Solutions Ltd. の Robert Virding 氏による BEAM の概要解説。Scheduler, Memory 管理, GC, Async Threads について小気味よくまとまっています。 The evolution of the Erlang VM 同氏による Erlang VM の歴史解説。Erlang VM ごく初期のProlog Interpreter や JAM(Joe's Abst
"writeback" と "unsafe" ではブレが非常に大きくなっています。これは Host の Page cache の影響です。 "directsync" と "writethrough" では、oflag=direct 時に著しく性能が落ちています。これは qemu が write 毎に fdatasync を発行するためです。 Cache mode の選定 さて、cache mode には色々あり、性質も大きく異なりますが、結局どの mode を選べば良いのでしょうか。指標としては、"メモリ消費量"、"性能"、"安全性" が挙げられます。 "メモリ消費量" で mode に大小をつけると以下のようになります。 directsync = none < writethrough = write back = unsafe "directsync" と "none" では Host
はじめに 仮想環境での Live Migration というと、仮想マシン移行元と移行先ホストでディスクを共有した上で行うのが一般的です。Live Block Migration は、共有ディスクが無い場合でも、仮想ストレージを移行させることにより Live Migration を実現する技術です。VMWare においては、Storage vMotion と呼ばれています。今回は、Qemu/KVM 環境において virsh を使った Live Block Migration の使い方をご紹介します。検証環境は Fedora 19です。 Live Block Migration には、仮想マシンの仮想ストレージすべてをコピーする Full モードと、Backing File との差分のみコピーする Incremental モードがあります。下記でそれぞれを紹介します。 Live Block
はじめに blktrace は block IO の発行をトレースする有名なツールです。blktrace で集めたトレースデータを解析する btt には、ディスク上での block IO の分布を可視化する bno_plot.py というツールが付属しています。bno_plot.py を使うと、gnuplot を用いて下記のような図を生成できます。 図では、x軸が時間、y軸が Block Number、z軸が Block per IO になっています。これから、いつ頃に、どのセクタに、どのくらいのIOが発行されたかがわかります。 使い方 bno_plot.py の使い方をご説明します。 blktrace と gnuplot をインストールします。 # yum -y install blktrace gnuplot blktrace でトレースを収集します。 # blktrace -w 30
はじめに iostat は IO の出力速度や待ち時間の計測によく使われるコマンドです。"-x" オプションをつけると、平均待ち時間(await)やリクエストキュー長(avgqu-sz)、サービスタイム(svctm)などの詳細な情報を出力することができ、とても便利です。データベースをはじめとし、各種アプリケーションのパフォーマンスを計測するための重要な指標となります。 今回は、これらの出力結果について、より詳細かつ正確な意味を、Linux Kernelのソースコードを読んで理解しましょう。かなり長くなってしまったので、意味を把握したい方は下の方の "iostat -x 出力結果まとめ" をご覧ください。 iostatの挙動 まず、iostatの挙動を調べます。iostatは、read_sysfs_file_stat()で指定したインターバルごとに /proc/diskstats の情報を読
はじめに Qemu/KVM 環境において、ホストゲスト間でのファイル共有ができると、とても便利です。例えば、開発中の Linux Kernel をテストする時には、ホストのコンパイル済み Kernel ソースディレクトリをゲストでマウントし、Kernel のインストールができると捗ります。ファイル共有方法には NFS、CIFS、SSHFS などがありますが、Qemu にはより効率的な "VirtFS" という仕組みがあります。 VirtFS は、ゲストの Linux マシンと virtio-9p デバイスを通じてファイル共有する仕組みです。ゲストホスト間で共有するリングバッファへの読み書きでデータをやり取りするため、他のネットワークファイルシステムなどより効率が良いのです。 今回は virt-manager での VirtFS を使ったファイル共有設定方法についてご紹介します。 Fedor
はじめに 仮想マシン上で頻繁に環境構築・破壊を繰り返す場合、仮想マシンのスナップショットを利用し、素早くディスク状態をもとに戻せると便利です。libvirt, Qemu/KVM は仮想マシンのスナップショット機能を実装しており、とても有用です。今回は virsh コマンドでのスナップショットの扱い方をご紹介します。検証環境は Fedora 18です。 スナップショットの種類 libvirt, Qemu が実装している仮想マシンスナップショットの種類には、以下の2種類がありあます。 - 1. 内部スナップショット - 2. 外部スナップショット 1. 内部スナップショットは仮想マシンのスナップショットを一つの qcow2 ファイルで管理する方式です。スナップショット取得中は仮想マシンは一時停止状態になります。仮想マシンのディスクのスナップショットのみならず、RAM 状態やデバイス状態などの仮
はじめに VXLAN は VMware、Cisco、Redhat などが推進している VLAN に替わるネットワーク論理分割のための規格です。従来、IaaSなどのクラウド環境において、マルチテナントを実現するためには 802.1Q VLAN を用いるのが一般的な解決策でしたが、この VLAN には VLAN ID が 12bit しかないため、最大 4096 セグメントの分離しかできない、という問題があります。 VXLAN はこの問題を解決します。VLAN ID に対応する VNI(VXLAN Network Identifier) に 24bit を設け、 1,677万セグメントの論理分割を実現します。 VXLAN 類似の技術には Microsoft、Intel、Dell などが推進している NVGRE(Network Virtualization using Generic Routi
SystemTapはスクリプトで気軽にLinux Kernelの動作を調査できる素敵なツールです. この記事は,SystemTapで関数の呼び出し元を取得する方法についてのメモです. Tapset Referenceを参考にし,Context Functionsのfunction:callerを使用します. 最も簡単なものだと,このような形になります. probe kernel.function("schedule").return { printf("caller : %s", caller()) } 出力はこんな感じ.Kernel内のschedule()関数を呼び出した関数名と,アドレスが出力されます. [eiichi@fedora]~/work/stap% sudo stap schedule.stp caller : cpu_idle 0xffffffffc04023d0 call
NIST により2013/5/14 に、 RHEL6.1 - 6.4 をはじめとする Linux ディストリビューションに、perf のバグをついて権限昇格される脆弱性があることがアナウンスされました。 Vulnerability Summary for CVE-2013-2094 影響範囲が大きいと思いますので、情報をまとめておきました。 Exploit Code:semtex.c 手元のCentOS 6.4 で試したところ、rootを取ることが出きました。 Does CVE-2013-2094 affect Red Hat Enterprise Linux and Red Hat Enterprise MRG? 解決策として、Systemtap スクリプトを guru モードで動作させ、動的にパッチを当てる手法が掲載されています。 RedHat Bugzilla CVE-2013-20
サーバーサイドでのWebページレンダリングについて調べていたらいつの間にかつくっていました。Base64形式でサムネイルを出力してくれるものは今のところ見当たらなかったので、便利かな。 こちらです! ※負荷がかかった場合にうまくリクエストを捌けないバグがあり、うまく動いていないかもしれません。申し訳ないです。対策中です。 こんな感じのものが撮れます。 使い方 URLをテキストボックスに入力して、Sendボタンを押してしばらく待つと、テキストエリアに何か出力されます。エラーメッセージっぽい場合は無視してください。正しそうならテキストエリアをまるごとコピーしてHPなりブログなりに貼り付けると、うまく画像が表示されるはずです。 内部仕様 使用しているブラウザ : Firefox4 beta7 (en) フラッシュプラグイン : Adobe Flash Player 10.2 beta どんな
2010/10/27にCanvas共有Websocketサーバーを作動させて以来、サーバーがのべ三度にわたりダウンするという問題が発生していました。原因の究明を進めていたところ、一部ダウンする状況の再現及び対処法を突き止めましたのでご報告申し上げます。なお、ダウン中にアクセスされ、Canvas共有を体験なさることが出来なかった読者の方々には深くお詫び申し上げます。これからもダウンの折には早急な原因の解明と対処に努めますので、どうか今後ともよろしくお願いいたします。 サーバーダウン時のエラー出力の内容 node.js:63 throw e; ^ Error: ECONNRESET, Connection reset by peer at Stream._readImpl (net:304:14) at IOWatcher.callback (net:454:24) at node.js:76
友人のhidekiyさんにNode.jsというこれから流行りそうなおもちゃを紹介してもらったので遊ぼうと思います。 Node.jsはV8 JavaScriptエンジン上でイベント化された入出力を扱うフレームワークです。 Node.jsを用いて簡単な落書き板のようなものをつくりました。Websocketサーバーに接続して、みんなでリアルタイムにCanvasを共有し、書き込むことができます。接続時に、サーバーに落書きデータがある場合はそれをダウンロードしてクライアントのCanvasに書き加えます。 クライアントサイドもサーバーサイドもJavaScriptで書けるって、やっぱり気持ちいいです。 対応ブラウザはSafariとChromeです。 Port:8888 をWebsocketの通信に使用しています。ウイルス対策ソフトのブロッキングやプロキシ環境下においては通信できない可能性がありますのでご
Memcached を運用中に、Request の傾向は変わっていないにもかかわらず、徐々に Item 数が増加し始め、 ある時を境に Item が 一切 Eviction/Expire されなくなり、Memory が枯渇し Slab OOM Error が起こる、という不具合に遭遇しました。不具合の原因については特定し、1.4.29 で修正がマージされました (Pull-Request: fix zero hash items eviction , ReleaseNote1.4.29) 。不具合が発生する条件、原因、回避策を簡単にまとめておきます(Pull-Request にはより詳しく書いてあります)。 Memcached Version : 1.4.19 から 1.4.28 SET した Key を GET しない場合がある Item を入れ替える Command (APPEND,
Google App Engineを用いてマンデルブロ集合を描画してみました。 目的はpure JavaScriptで時間のかかる処理をGAEにまかせてしまえば高速に描画できるのではないかと思ったからです。GoogleMapみたいにフラクタル世界をスイスイしたかったのです。 処理内容 1.サーバーサイドで各点の発散を調べ、ループ回数を返します。 2.クライアントサイドでCanvasに色付けします。 問題点 自分の環境だと残念ながらscaleがある程度大きくない限り、ほぼ似たような処理時間になってしまいました。Canvasへのピクセル操作に時間がかかってしまうのです。 JSONのパースに時間がかかるのかと思い、ランレングス圧縮したシリアライズ方式でもやってみましたが、同様の時間がかかてしましました。Canvasのピクセル操作がネックになっているのでどうしようもないんでしょうか...?救いは無
以前友達とプリクラを撮ったのですが、その写真の加工の仕方にかなり驚くと同時に興味をもちました。 どうやらプリクラ機体では顔を認識し、目をデカくしてパッチリさせたり、多少露骨な美白処理を行っているようです。 そういう処理をWEBでやってみたいと思っていたところ、折よくWEBで顔認識APIを公開しているところがあったので、夏休みの工作がてらつくってみたというわけです。 2013/3/31 追記:飽きたので停止しました使い方 syame@mail.etsukata.com 1.上記のメールアドレスに、顔の写った写真を添付して送る 2.うまく顔認識できた場合上記のアドレスから、加工した写真が添付されてくる。顔認識できなかった場合はエラーメッセージが返信される。 ※パソコンでも携帯でも大丈夫です。 ※サポートしている写真の形式はjpg, jpeg, png, gifです。 ※写真は一度に何枚添付して
このページを最初にブックマークしてみませんか?
『Etsukata blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く