タグ別アーカイブ: カーネル

Googleは10億個のファイル・20億行のコード・合計86TBでできている – GIGAZINE

Googleのエンジニアリング・マネージャーであるレイチェル・ポートヴィンさんが、「The Motivation for a Monolithic Codebase」と題した講演の中で、Googleのシステムが86TB(テラバイト)でできていることを明かしました。

Google Is 2 Billion Lines of Code—And It’s All in One Place | WIRED

http://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/

講演ムービーはコレ。話は5つのテーマに分けて行われていて、Googleのリポジトリについての話は1番目、3分過ぎから始まります。

The Motivation for a Monolithic Codebase Why Google Stores Billions of L – YouTube

2015年1月時点で、総ファイル数は10億、ソースファイルの数は900万、コードは20億行あり、3500万回のコミットがあって、内容は86TBあるとのこと。そして、営業日1日に対してのコミット回数は4万5000回。

累積コミット数のグラフはこんな感じ。左側の回数目盛りは40までですが、それぞれ1目盛りが1000万回分に相当。2000年1月1日からの数字ですが、コミットが1000万回を越えたのは2012年ごろのこと。回数はぐんぐん増えていて、2015年1月時点で3500万回まで増えています。

Googleで働く「Googler」は2万5000人、世界に12あるオフィスで働いています。1日あたりのコミット回数は4万5000回とありましたが、そのうち1万5000回が人間の手によるもの、3万回が自動化されたシステムによるもの。ファイルリードリクエストは1日に10億回で、ピーク時には80万QPS(秒間クエリ処理数)に到達するとのこと。

これが1週間のコミット数を、人の手によるものと全体とを分けてグラフ化したもの。単位は1000回なので、だいたい人の手によるコミットは週間7万5000回ほど。

Linuxのカーネルが4万ファイルで1500万行あるのに対して、Googleのリポジトリは25万ファイル・1500万行が人の手によって毎週変更されています。累計のサイズは900万ファイルで20億行にもなります。

Windowsの公式Facebookページによると、Windows XPは4500万行のコードでできていたとのこと。数字だけを単純に比較すると、Googleは3週間でWindows XP全体に相当する量のリポジトリを変更している、ということになります。

引用元: Googleは10億個のファイル・20億行のコード・合計86TBでできている – GIGAZINE.

第9回 カーネル内部のセキュリティを強化,ネストカーネルでメモリ区画化:BSD界隈四方山話|gihyo.jp … 技術評論社

ネストカーネルでは,次の過程がアイディアの根幹をなしています。

メモリ管理ユニット(MMU:Memory Management Unit)のページテーブルへのアクセスを規制することができれば,カーネル内部においてもメモリの区画化を実現できるのではないか。たとえそれが単一のハードウェア特権レベルで動作しているのであったとしても。

カーネルはこれまでスーパバイザモードで動作し,その世界はすべての特権を持つものでした。ネストカーネルのアイディアは,このスーパバイザモードで動作するカーネルを仮想化して,そこでのメモリアクセスをより細かに規制して保護すればよいのではないか,というものです。

ここで従来のカーネルは次の2つのカーネルに分かれます。従来のカーネルに相当するものは「アウタカーネル」と呼ばれ,新しく追加されるカーネルが「ネストカーネル」と呼ばれています。そして,ユーザランドからシステムコールが呼ばれると,カーネルは次のような処理をするようになります。

システムコールが呼ばれる

アウタカーネルが呼ばれる

アウタカーネルはネストカーネルを呼ぶ

ネストカーネルが処理を実施する

処理は「アウタカーネル」と「ネストカーネル」の2つに分かれています。そして従来と異なり,それぞれ次のような規制が加わります。

アウタカーネル

ページテーブルは常にリードオンリー

ネストカーネル

カーネルコードはリードオンリー

カーネルデータは実行不可能(Non-executable)

ユーザコードはSMEP(Supervisor Mode Execution Protection)

ユーザデータはSMEP(Supervisor Mode Execution Protection)

ページテーブルは常にリードオンリー

引用元: 第9回 カーネル内部のセキュリティを強化,ネストカーネルでメモリ区画化:BSD界隈四方山話|gihyo.jp … 技術評論社.

Linuxカーネル4.0リリース、ライブカーネルパッチを導入 | SourceForge.JP Magazine

2月中旬に公開されたLinuxカーネル3.19に続くリリースとなる。Linuxカーネル3.19の公開後、Torvalds氏はGoogle+にて次期版の名称を「Linux 3.20」とするか、以前構想を明かした通りに「4.0」とするかについてオンライン投票の形で意見を募った。投票では少しの差(56%対44%)で「4.0」が上回っており、その後2月末に初のリリース候補版を「Linux 4.0」として公開した。今回のバージョン番号の変更については「数字が大きくなることを避けること」を目的としており、Torvalds氏も「4.0の前提は、新しい実験的な機能よりも安定版リリース」でありこれに沿うものと記している。

大きな変更点として、再起動をせずにカーネルにパッチを適用できる基礎的な仕組みが導入された。米Red Hatのライブパッチツール「kpatch」とSUSEのライブパッチツール「kGraft」をサポートする。一方でremap_file_pages()システムコールは削除された。この機能のエミュレーションは残るため、アプリケーションの動作に影響がでることはないという。

ファイルシステム側ではパラレルNFS(pNFS)ブロックサーバーのサポートが加わり、btrfsでのRAID 5/6も改善した。また、ubifsファイルシステムでマルチキューブロックレイヤーをサポートし、準仮想化のvirtioはバージョン1.0となった。ext4ではlazytimeファイるシステムオプションのマージも行われており、ファイルシステムに多数のI/Oを加えることなく正確なアクセス時間を効率的に追跡できるとしている。overlayFSでは複数のリードオンリーレイヤーのサポートが加わっている。

このほかにも、perfツールの改善など多数の細かな機能強化が施された。IBM s/390 z13プロセッサなど、新しいプロセッサ、ハードウェアのサポートも加わっている。

引用元: Linuxカーネル4.0リリース、ライブカーネルパッチを導入 | SourceForge.JP Magazine.

Linuxカーネル4.0が登場 – 再起動せずにパッチ適用が可能に | 開発・SE | マイナビニュース

今回、オンタイムでリリースされた理由として、大きな問題が発生していないこと、週末にLinus Torvalds氏の都合が悪いことなどが挙げられている。

引用元: Linuxカーネル4.0が登場 – 再起動せずにパッチ適用が可能に | 開発・SE | マイナビニュース.

これから始める人のためのNginx(1):高速・軽量・高機能……Nginxの基礎知識 (2/2) – @IT

Nginxが大量のリクエストでも同時に高速処理できるのは、イベント駆動方式を採用しているためです。

Webサーバーのように同時に複数の処理を行うには、ディスクやネットワークといったI/Oの多重化が必要になります。I/O多重化の実装には「select」や「poll」といったシステムコールが従来使われています。

Apache HTTPでプロセスベースやスレッドベースのMPM(マルチプロセッシングモジュール、注6)を選択すると、こうしたシステムコールが使用されます。select/pollでは、プログラムがアクセスするファイルネットワークソケットなどをOSが識別するための「ファイルディスクリプター」を1つ1つチェックします。チェックするディクリプタが増えれば処理にかかる時間も比例(注7)して長くなり、同時リクエスト数が2倍になれば処理に掛かる時間も2倍に膨らみます。

Niginxのイベント型では、I/O多重化を実装するのに「epoll」システムコールを使用します。epollではディスクリプターの状態がカーネル内で管理されるため、プログラムが1つ1つチェックする必要がなくなります。この場合、処理にかかる時間はリクエストによらず一定(注8)になります。そのためNginxは、万単位のリクエストも高速に効率良く処理することができます。

また、メモリの使用量が少ないのも特徴です。Apache HTTPのプロセスベースやスレッドベースのMPMでは、リクエストを処理するのにプロセスやスレッドを起動するため、使用するメモリもリクエスト数に応じて増加します。一方Nginxは単一プロセスで全てのリクエストを処理するため(注9)、リクエスト数に応じてメモリ使用量が変化することはありません。

Nginxの省リソースの恩恵は、数万単位のリクエストを処理するような大規模サイトだけではなく、組み込みPCやマイクロサーバーのように限られたリソースしか使用できない状況にも有効です。

引用元: これから始める人のためのNginx(1):高速・軽量・高機能……Nginxの基礎知識 (2/2) – @IT.

Solaris 10 Feature Spotlight: Solaris ゾーン

Solaris ゾーン機能は、FreeBSD Jails と同じ基本概念に基づいています。 FreeBSD Jails と Solaris ゾーンのどちらでも、実行環境のそれぞれのビューはお互いに完全に隔離され、ある環境にあるプロセスは別の環境にあるプロセスにシグナルを送出できず、そのプロセスを参照することさえできません。 Jails とゾーンでは、1 つのインスタンスのオペレーティングシステムだけが共有されるため、CPU が 1 つしかないマシンでも、複数の実行環境が共存できます。

ゾーンには、グローバルゾーンと非グローバルゾーンの 2 種類があります。 Solaris ゾーン機能が有効になっているマシンには、1 つのグローバルゾーンと最大で 8191 の非グローバルゾーンがあります。 1 台のマシンで使用できる最大ゾーン数は、そのマシンのハードウェアリソースによって決まります。 それぞれのゾーンには、起動時に ID が割り当てられます。 グローバルゾーンの I D は常に 0 になり、起動可能な Solaris カーネルはグローバルゾーンだけに収容されます。 すべてのデバイス、ファイルシステム、他のゾーンを認識できるのはグローバルゾーンだけです。 また、グローバルゾーンは、非グローバルゾーンの設定、インストール、管理を行える唯一のゾーンでもあります。

非グローバルゾーンには、グローバルゾーンにインストールされた Solaris OS のサブセットが収容されます。 さらに、グローバルゾーンにインストールされていないパッケージも組み込むことができます。 それぞれの非グローバルゾーンには、そのゾーンに関連するインストール済みのソフトウェアパッケージを記録した専用のパッケージデータベースがあり、グローバルゾーンや他の非グローバルゾーンとの間でパッケージの情報は共有されません。 非グローバルゾーンには、ローカライズされた設定情報や、他のゾーン固有のファイルやディレクトリも含まれています。

引用元: Solaris 10 Feature Spotlight: Solaris ゾーン.

Dockerリリース候補版

Dockerバージョン0.11がリリースされた。これはバージョン1.0の初めてのリリース候補版だ。今回のリリースは、安定性だけでなく、ネットワークやセキュリティ、管理に関する多くの機能を改善している。

ホストネットワークはコンテナにダイレクト(ブリッジネットワークの仮想インターフェース経由で接続するのではなく)にホストのネットワークスタックを共有する。コンテナ内でネットワーク監視ツールを走らせる場合に有効だ。また、ブリッジネットワークを使っている場合のパケットの処理がCPUのボトルネックになってしまう問題も回避できる。

コンテナリンキング/etc/hostsを自動で移植することで改善された。これによって、環境変数を解析してリンクされているコンテナのアドレスを検出する必要はなくなる。以前の仕組みは、アプリケーションのコードやスクリプトを使って対処するのには問題なかったが、環境を解析する方法を持たない構成ファイルでは無理があった。

セキュリティに関する大きな機能は、Security-Enhanced Linux (SELinux)をサポートしたことだ。SELinuxは10年以上に渡り、主要なLinuxカーネルの一部分を占めている。SELinuxはDockerのコマンドラインスイッチから有効にできる。コンテナ内で動作しているプロセスが強制アクセス制御で制限を受けるため、ホストシステム(やほかのコンテナ)は影響を受けない。これによって、システム管理者はコンテナをより厳密に分離できる。

管理機能のアップデートには、DockerデーモンにPingしてヘルスチェックをする機能やログファイルのオプションタイムスタンプ機能が含まれる。Dockerは複数のイメージレジストリミラーをまたがって動作し、フェールオーバすることができる。SHA-512を使ったレジストリもサポートする。

引用元: Dockerリリース候補版.

本の虫: Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子

syscallトラップのパフォーマンスは興味深いものだ。

15年前[訳注:この記事が書かれたのは2004年なので、1989年頃]、IntelとMicrosoftと会議があった(残念ながら、私はこの会議に参加していなかったので、この話は伝聞なのだが)

Microsoftというのは、Intelの最大の顧客のひとつなので、Intelの代表はよくMicrosoftを訪問して、最新のプロセッサーを紹介したり、カーネル開発部に新しいプロセッサーの機能をサポートするようロビーしたり、どのような機能を追加すれば、もっとも役立つかという知見を吸い上げたりしていた。

この会議で、Intelの代表がたずねた。「でさ、たったひとつだけ、速くして欲しいところがあるとすれば、どこ?」

躊躇なく、カーネルの開発主任が答えた。「無効命令のfaultingの高速化」

Intel社員は笑い転げた。「いやぁ、Microsoftのエンジニアは愉快でいらっしゃる」というわけで、会議は冗談で締めくくられた。

研究所に戻った後、IntelのエンジニアがWindowsカーネルのプロファイルをしたところ、驚くなかれ、彼らはWindowsがかなりの時間を、無効命令例外をさばくためにつかっていることを発見したのである。何だと! ひょっとして、Microsoftのエンジニアは冗談を言ったのではなかったのか?

冗談じゃない。

この当時の80386チップで、V86モードからカーネルモードに移行する最速の方法は、無効命令を実行することだったのだ! そのため、Windows/386は、無効命令をsyscall trapに使っていたのであった。

この話の教訓? よくわからない。たぶん、何か物を作ったならば、それが作成者の意図しない方法で使われるだろうということか。

引用元: 本の虫: Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子.

Geekなぺーじ:FreeBSDのTCPスタックに脆弱性、カーネルメモリを抜き取られる可能性

FreeBSDのTCPスタックに含まれる脆弱性に関する情報が公開されました。 現在サポートされている全てのFreeBSDバージョンに影響があるようです。

The FreeBSD Project Security Advisory: TCP reassembly vulnerability

TCPセグメントの並び替えを行うコードに不具合があり、カーネルをクラッシュさせることによるDoS攻撃が可能とあります。 また、非常に難易度が高いとしつつも、今回の脆弱性を突くための工夫を凝らしたTCPセグメントを駆使することで、カーネルが保持するメモリを、接続されたソケット経由で取得できてしまう可能性もあるとのことでした。 FreeBSDのセキュリティアドバイザリでは、カーネルがメモリに保持するものの例として「ログイン認証情報など」とあります。

FreeBSDは家庭用PCや各種サーバで利用するだけではなく、SOHOルータやNASなど、様々な機器を制御するためのOSとしても使われています。 今後、そういった機器に含まれるソフトウェアのアップデートが必要になるかも知れません。

引用元: Geekなぺーじ:FreeBSDのTCPスタックに脆弱性、カーネルメモリを抜き取られる可能性.

Google Cloud Platformのネットワークを改善するAndromeda

Andromedaの利点を享受するため、GCEのユーザは最新のDebianバックポートのイメージを使うことを推奨されている。このイメージにはオフロードとマルチキューの機能を利用できるカーネルドライバが含まれている。GCEはRed Hat Enterprise Linux(RHEL)、SUSE Linux Enterprise Server (SLES)などサポートするOSを増やしているが、Andromeda向けに最適化されたカーネルは搭載していない。また、Windowsイメージ向けのAndromeda最適化については情報がないが2014年5月1日に発表される予定だ。

引用元: Google Cloud Platformのネットワークを改善するAndromeda.