第7回コンテナ型仮想化の情報交換会の発表資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。(2015-06-25スライド更新しています)
![今さら聞けない Linux コンテナの基礎 (2015-06-20)](https://cdn-ak-scissors.b.st-hatena.com/image/square/4d5c671fb553a068aa14feed539134e424a3422b/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F11de7a54c3da48afa3485b0546835e9e%2Fslide_0.jpg%3F4969473)
ここではBoostライブラリのビルド方法について説明します。 Windowsとそれ以外に分けて説明します。また、LinuxではBoostライブラリがディストリビューションによって提供されていることがありますが、ここではビルド方法のみを扱います。 1.47.0からbjamだけではなく、b2も生成されるようになりました。また、公式がbjamからb2での説明に切り替わっています。なので、こちらもそれに合わせることにします。 ダウンロード 現在の最新バージョンは、以下からダウンロードできます: http://www.boost.org/users/download/#live 開発バージョンは、Githubから取得できます: https://github.com/boostorg Github から clone する場合、具体的には boostorg/boost を clone し、実際の Boo
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題(クエリ)を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ(アプリケーションの設計者)に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
本サイトではより多くの方に快適に利用して頂ける様に、アクセシビリティ面を充分に考慮したコンテンツの提供を心がけております。その一環として、閲覧対象コンテンツのすべてにスタイルシートを使用して制作しております。現在閲覧に使用されているブラウザには、当方制作のスタイルシートが適用されておりませんので表示結果が異なりますが、情報そのものをご利用するにあたっては問題はございません。
1. 概要 プロセスがファイルへの書き込みを行うと、カーネルは通常はページキャッシュ(ディスクキャッシュ)に書き込むだけで一旦処理を完了する(ディスクヘの書き込みは行わない)。このデータが書き込まれたページキャッシュは、ディスク上のデータと内容が不一致になっていることを示すためDirty状態になる。Dirty状態のページキャッシュはカーネルスレッドpdflushによって、遅延してディスクに書き込まれる。この処理をWriteBack処理と呼ぶ。 2. WriteBack処理の動作 2.1 WriteBack処理の起動 WriteBack処理はカーネルスレッドpdflushによって実行される。カーネルスレッドpdflushを起動するには、wakeup_pdflush()、balance_dirty_pages_ratelimited()が使われる(図1)。 wakeup_pdflush()はt
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
Linuxのブートプロセスを追うときに見るべきファイル(x86_64編)のarm64版のようなもの。 ブートストラップ linux/Documentation/arm64/booting.txt によると、現在のarm64用カーネルは、x86_64用カーネルが持つようなブートストラップの機能が存在しない。実際、arch/arm64/boot/以下にはx86_64のようなソースコード(head_64.S等)が存在しない。ブートローダがハードウェアの最低限の初期化をして、解凍された生のカーネルイメージ(ELFではない)を配置、エントリポイントにジャンプしてやらないといけない。カーネルに実行を移すときの要件も、booting.txtに書かれている。 ブートローダとしては、ubootやUEFIが使えると思われる。(Boot Wrapperというのも使えるみたいだが、今も使えるかは分からない。) a
シェルスクリプトとアーカイブをくっつけて自己解凍できるやつ。 Unixのインストーラでこういうのありますよね。 こういう技は素晴らしいですね。しかもお手軽だし。 http://stackoverflow.com/questions/20758981/self-extracting-script-in-sh-shell スクリプトを作成。perlでもpythonでもshでもなんでもいいです。 スクリプトの最後だという識別子を入れておきます。ここでは#EOF#という識別子を書いています。 #!/bin/sh num=0 sed '1,/^#__EOF__#$/d' $0 | zcat - | tar xvf - 2>&1 |\ while read mod do num=`expr $num + 1` echo -ne "$num : $mod\r" sleep 0.1 done echo "
Flask にはエラーハンドラという機構がある。 これは Web アプリケーションの中でハンドルされなかった例外を HTTP のレスポンスに変換するというものだ。 つまり、どれだけ呼び出しの深い場所にいてもエラーが起こったときには例外さえ上げればクライアントに適切なレスポンスが返るという便利な仕組み。 同様の機構は、他の Web アプリケーションフレームワークでも JAX-RS (Java) の例外マッパーや Pyramid (Python) の例外ビューとして見られる。 今回はその便利なエラーハンドラについて書いてみる。 まずは何はともあれ Flask をインストールする。 $ pip install flask 最初のサンプルコードは 404 エラーをレスポンスに変換するというものだ。 エラーハンドラが登録されていない場合はデフォルトのエラーメッセージが HTML で返ることになるが、
※前回記事にてトラブルシューティング実施にあたって準備しておきたいこと(作業ログの取得方法など)を記載しておりますので、本記事では割愛します。 はじめに 前回の記事の続きとなります。 新米エンジニア(アプリ・インフラエンジニア問わず)に知っておいてほしいトラブルシューティング入門 はじめの一歩編 前回に記事を書いたあと、現場でも意外と基礎を押さえた切り分けができない人が多いのではと思い、よりいろんな方に読んでいただきたくタイトルをかえてみました。 前回の記事では、トラブルシューティングの前に実施しておきたい事や心構えについて記載しました。 今回はそれを受けて実際にトラブルが起きた際の簡易的な切り分け方法についてまとめてみます。 本記事の対象と扱う範囲 前回記事と同様に、初めてエンジニアとして働くことになった方々向けです。 本記事のゴールが「○○できないですのですが、、」といった事象に対して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く