大統一Debian勉強会2013での発表資料です。 resolvconf パッケージなどとの連携方法や独自に同じようなスクリプトを作成する方法について話しました。Read less
Network servers are traditionally implemented using a separate process or thread per connection. For high performance applications that need to handle a very large number of clients simultaneously, this approach won't work well, because factors such as resource usage and context-switching time influence the ability to handle many clients at a time. An alternate method is to perform non-blocking I/
>>(1)よりつづく 前回は単純な実装からマルチスレッド、スレッドプールと順に見て行きました。今回はいよいよepollを使った実装を紹介します。 epoll例- 4epoll.c 多重I/Oすなわち select(2) / poll(2) によるイベントループはマルチスレッドが普及する以前から利用されていました。 select(2) / poll(2) は複数のファイルディスクリプタ(ソケット)を調べ、I/O可能なものを返すシステムコールです。ソケットに対する読み取りはデフォルトではデータがなければブロック(データが到着するまで待つ)しますが、事前にI/O可能かを確認しておけばブロックすることはありません。1システムコールで複数のソケットを調べられる点も重要で、1プロセスで複数のクライアントに並行して対応できるようになります。しかし当然ながら、対象ソケット数の増加に応じて処理量が増えます。
本連載ではシステムコールプログラミングの例も掲載していく予定ですが、本記事ではLinuxに追加されたepollを採りあげ、インターネットサーバでのPthread利用と比較してみます。 はじめに マルチスレッドプログラミングが普及し、POSIX threadも制定され、Pthreadの利用は目新しいものではなくなりましたが、スレッドにまつわる迷信や誤った認識を、だいぶ減ったとはいえ、今でもたびたび耳にします。例として、 スレッドはプロセスよりも軽いので、多数作成しても軽快に動作する スレッドはプログラミングを簡単にしてくれ、1つの処理だけに集中できる などがあります。しかし、これらは常に真であるとは限りません。本記事ではマルチスレッドの概念や入門を繰り返すのではなく、その利用方法をHTTPサーバのサンプル実装を基に考察します。更にLinuxに追加された独自機能のepollインタフェースを用い
お久しぶりです、初めての日本の夏に圧倒されているトールマエサカです。 今日はLinuxにおけるネットワークプログラミング関連のネタです。分散データベースサーバの開発過程で最近よくLinuxのepollというイベントハンドリング機能を使っています。これがまた優秀な機能なので紹介します。 このContextでいうイベントハンドラーはサーバがクライエントのリクエストを処理するためのメカニズムです。イベントの感知と通知は大雑把にいうと以下の三つの処理で構成されています: 一つもしくは複数のディスクリプタを監視 ディスクリプタの準備が整うまでハチ公のごとくひたすら待ち続ける 準備が整ったディスクリプタの通知 アプリケーションでの実装は一昔までselect(2)、もしくはpoll(2)というシステムコールで行われていました。二つとも役目は同じですがselect(2)の場合、kernelをいじらない限り
The document discusses the basics of I/O and event-driven I/O models in Linux like blocking I/O, non-blocking I/O, I/O multiplexing using select/poll and their internals. It then introduces epoll as a more efficient alternative to select/poll and describes its user-space API, kernel structures and how it works by adding file descriptors to an epoll instance and waking up blocked processes on I/O e
「大きい番号は魅力的だからv3.20へ進むか、あるいは番号をリセットしてv4.0にするか、どっちがいい?」。約10日前の2月13に、Linus Torvalds氏は次のLinuxのバージョン番号についてGoogle+に質問を投稿し、投票を呼びかけました。 2.6.39のようなバージョン番号を避けたかった Linux 4.0へとLinuxのメジャーバージョン番号を大きくすることは、以前からTorvalds氏が個人的な希望として示していたことでした。Torvalds氏は投票を呼びかける投稿の中でも「I don't want another 2.6.39」と書いています。これは、2.6.39のようにバージョン番号の下位の細かい数字が増えていくことで、バージョン番号が分かりにくくなることを敬遠したい、ということを示しています。 そして現在のLinuxがバージョン3になり下位の数字が3.19から次に
前回でページング機能を有効にすることまではできた。今回はこれを活用してメモリを管理する部分を考察する。因みに、まだ考察するだけ(汗)。 メモリ管理とは メモリ管理とは、ぶっちゃけ以下の2点に集約される。 必要とされるメモリを割り当て、使えるようにする。 使わなくなったメモリを回収し、別の場所でまたいつか使えるようにする。 これをいかに速く、無駄なく行うか。これがメモリ管理だ。 メモリの割り当て・回収について、C言語を使ったことのある人なら馴染みが深いと思う。つまりmalloc/free関数だ。メモリ管理を実装するとは、malloc/freeを自分で実装するという意味だ。だから、外から見えるインターフェイスとしては極めて単純なものだ。 しかしその中身は極めて複雑になる(汗)。メモリ管理について、いまだ人類が決定的な解決策を見出していないいくつかの問題があるのだった。(おおげさ) 断片化の問題
LinuxにおけるACPI構造の解説 NECシステムテクノロジー株式会社 夜久 健一 ACPIとは • ACPIの特徴 – 電源管理を行う – ACPIは、OSがパワーマネージメント – 本体装置、ソフトウェアの連携 ACPI構造 Device Driver Kernel ACPI Core Subsystem OSPM AP ACPI aware device drivers Hardware ACPI BIOS/Table/Register OS layer BIOS HW layer BIOS Memory MAP >> cat dmesg | less BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800
今月の初めに公表されていた、一般ユーザーが Linuxシステムをクラッシュさせてしまえるバグ CVE-2014-9090 が実は root権限の奪取にも使えることがわかり CVE-2014-9322 に進化しています。 CVE-2014-9090の日本語情報はこちら。 Linux Kernel の arch/x86/kernel/traps.c 内の do_double_fault 関数におけるサービス運用妨害 (DoS) の脆弱性 要するに、64bit版の Linuxでは管理者権限を持たない一般ユーザーが「わざと」システムをクラッシュさせてしまうことができるということです。対象となるのは x86_64用 Linuxカーネルの 今までの全てのバージョンです。 いま動いてるLinuxが 32bitか64bitかよくわからない場合は uname -m と入力して i686と出れば 32bit、
社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。 最近、Graphite に保存しているデータのバックアップ(データ同期)に rsync 使ってて、かなり遅いので困ってた。 LISA っていう 大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。 論文概要 dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische U
Linux Storage Filesystem/MM Summit 2014からの便り:Linux Kernel Watch(1/2 ページ) お久しぶりです、Linux Kernel Watchが帰ってきました。3月に行われた「Linux Storage Filesystem/MM Summit 2014」の主なトピックを紹介します。 皆さん、お久しぶりです。私は今ボストンで、米レッドハット常駐という立場でRed Hat Enterprise Linux(RHEL)開発に携わっています。 今回はサンフランシスコ近郊のナパバレーで2014年3月24~25日に行われた「Linux Storage Filesystem/MM Summit 2014」(以下LSF/MM)の中から面白かったトピックをピックアップしてお届けしたいと思います。 LSF/MMはLinux Foundation主催で行
原文へのリンクはこちらです。 Linux カーネル開発者の Greg Kroah-Hartman、Jens Axboe、Dave Chinner、Matthew Garrett、Mel Gorman は、3 月 26 日 Collaboration Summit において、LWN 編集者の Jon Corbet が進行役を務めるパネルディスカッションに参加しました。以下はそのハイライトです。本記事末にパネルディスカッション全体のビデオも置いています。 各開発者が現在取り組んでいる開発作業の詳細については、Linux カーネル パネルディスカッション プレビューをご覧ください。 企業がカーネル開発者を雇用する理由について: 「自分たちのソフトウェアを公開して、他者を手助けするという商業的な要請が実際にあることがだんだんわかってきたのです。なぜなら、彼らもこちらを助けてくれ、双方が利益を得るか
sysdig とは? Sysdig is open source, system-level exploration: capture system state and activity from a running Linux instance, then save, filter and analyze. Think of it as strace + tcpdump + lsof + awesome sauce. With a little Lua cherry on top. http://www.sysdig.org/ 上に書いてある通り、一言で言うと strace + tcpdump + lsof + α。tcpdumpのように-wで書き出して-rで読み込めるのがありがたい。 高機能過ぎてまだ全然使いこなせてないけど、ぱっと触った感じ使えそうだなと思ったものを紹介。 1. プロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く