タグ

linuxとprocessに関するsomathorのブックマーク (27)

  • 令和にふりかえる C10K 問題

    C10K 問題 (the C10K problem) は1999年に Dan Kegel が発表した文章、ならびにそこで提示された「問題」です。文章はその後も2000年代前半に何度か更新されているのですが、さすがに令和に読み返すと、当初の問題意識がわかりにくいところがあります。 2000年からの10年は、 ソフトウェア面では、select(2), poll(2) にかわる新しいシステムコールの実装と、それを使ったアプリケーションの普及 ハードウェア面では、x86 アーキテクチャの64ビット移行、仮想化命令の追加と、マルチコア化 さらにそこにクラウドも登場する、面白い時代でした。ここでは、それらの出来事を中心に、さらに、当時の雰囲気をつたえるような日国内のブログやインタビュー記事をまとめることで、C10K 問題が、さまざまな側面から解決されていく流れを説明したいと思います。 書き足したいと

  • C10K 問題、実は理解していない

    お願い 「C10K 問題とは何か」がわかる方は是非 Issue や Twitter などで教えてください。 追記: 自分の立場 1req ごとに 1 native thread を割り当てていたら、クライアントの数が増えれば増えるほど負荷が高まるのは当然だ。ただハードウェアの性能的に余裕があっても性能が劣化することがあり、それを C10K 問題と呼ぶ。C10K 問題は fd, pid の枯渇、スレッドを固定長サイズで確保することによるメモリの無駄遣い、コンテキストスイッチコストを含む。これを解決する方法が 1req ごとに 1 native thread を割り当てない技術で、シングルスレッド+イベントループ+IO 多重化といったテクニックや M:N モデルにつながる。 追記: @naoya_ito さんに解説してもらった当時の歴史的背景 https://twitter.com/naoya

    C10K 問題、実は理解していない
  • マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー

    また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ

    マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
  • Linux でのハングタスクについて - 赤帽エンジニアブログ

    Red Hat でコンサルタントをしている菅原と申します。 この記事では、意外とあまり説明されていないような気がする Linux システムで発生するハングタスクについて少し説明したいと思います。現場のシステムでもハングタスク検知の設定がされていることが多いと思いますが、ハングタスクとは何なのかを正しくご理解いただくことで、ハングタスク検知を行う目的が明確になること、また、実際の障害事例もご紹介することで、通常あまりハングタスクと関連づけて考えないような設定でもハングタスク発生につながる場合があることを知っていただき、少しでもシステム管理や障害の理解、障害対応などのお役に立てれば幸いです。 なお、この記事では RHEL のみを対象に書いていますが、他の Linux ディストリビューションにも適用される内容と思います。 ハングタスク (hung tasks) とは ハングタスクとは読んで字のご

    Linux でのハングタスクについて - 赤帽エンジニアブログ
  • Linuxプロセスアクセス制御の概要 - えんでぃの技術ブログ

    SELinuxシリーズ 記事は、SELinuxシリーズの1記事目です。 Linuxプロセスアクセス制御の概要 ←今ココ SELinuxの概要 SELinux Type Enforcement SELinuxの実践 (参考) SELinuxのRBAC、UBAC、MLS、MCS (参考) SELinux Module Policyのソースコード読解、ビルド 参考URL 1〜3記事目は、4記事目を理解するための前提知識をカバーしています。 4記事目が最も重要で、SELinuxの具体的な操作方法やコマンド、トラブルシューティング手順を紹介しています。 5記事目以降は参考情報です。 SELinuxの関連記事は、SELinuxタグから探せます。 一連の記事はFedora環境を前提として書いています。 FedoraやRHELに類するディストリビューションであればほぼ同等の挙動になると思いますが、他のデ

    Linuxプロセスアクセス制御の概要 - えんでぃの技術ブログ
  • Diving into /proc/[pid]/mem

    A few months ago, after reading about Cloudflare doubling its intern class size, I quickly dusted off my CV and applied for an internship. Long story short: now, a couple of months later, I found myself staring into Linux kernel code and adding a pretty cool feature to gVisor, a Linux container runtime. My internship was under the Emerging Technologies and Incubation group on a project involving g

  • ペパボ トラブルシュート伝 - node プロセスの general protection fault を追う - abort(3) の意外な実装 - Pepabo Tech Portal

    セキュリティ対策室の伊藤洋也 @hiboma です。 業務中に、Haconiwa コンテナ で動くとある node プロセスが general protection fault ( 一般保護違反! ) を起こしてdmesg にログを残す現象を調べ、問題解決にあたっていました。その際の痕跡をまとめなおして記したエントリになります。 エントリの概要 エントリでは、以下のような内容を扱います。 Haconiwa コンテナの node プロセスが general protection fault を起こしている ライブラリ関数 abort(3) の概要 abort(3) がプロセスを停止する方法の検証 node プロセスが abort(3) を呼び出すケース glibc x86系の abort(3) 実装が HLT 命令を呼び出し、general protection fault を起こすこと

    ペパボ トラブルシュート伝 - node プロセスの general protection fault を追う - abort(3) の意外な実装 - Pepabo Tech Portal
  • LinuxでTCP/UDPコネクション状態にプロセス情報を紐付ける方法 - ゆううきメモ

    Linuxでは、/proc/net/*やNetlinkソケットを通じて、TCP/UDPのコネクション情報を取得できる。 しかし、ここで取得したコネクション情報は、コネクションを保有するプロセスに関する情報(pidなど)を含んでいない。 ssコマンドの--extendedオプションは、inode番号を表示することから、inode番号からプロセス情報を辿ることを考える。 当該プロセスのpidがわかっていれば、/proc/<pid>/fd以下から、次のようにsocket inode番号を知ることができる。 ubuntu@yuukidev01:~$ sudo readlink /proc/21326/fd/6 socket:[16801] しかし、inode番号からそのinodeを保持しているpidを直接知ることはおそらくできない。 そこで、次のようなTCP/UDPのコネクションリストとプロセスリ

    LinuxでTCP/UDPコネクション状態にプロセス情報を紐付ける方法 - ゆううきメモ
  • Linux コンテナの内部を知ろう / OSC 2018 Kyoto - Speaker Deck

    OSC 2018 Kyoto の講演資料です。 参考となる情報にはPDF中からリンクをしていますが、資料中のリンクは Speaker Deck 上ではクリックできないので PDF をダウンロードしてご覧ください。

    Linux コンテナの内部を知ろう / OSC 2018 Kyoto - Speaker Deck
  • 開いているファイルのプロセスを特定(lsofコマンド) - Qiita

    lsofコマンドの使い方です。 lsofコマンドは、、、 PortやPID、プロセス名からファイルがオープンしている情報を表示するコマンド。 よく利用する場面 「netstat -an |grep LISTEN 」とかでListenしているPortを調べてそのPortが何のプロセスとかで動いているのかとかを確認するのに使っています! 使い方サンプル % lsof /var/log/system.log COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME tail 97529 USERNAME 3r REG 1,2 498299 12085861 /private/var/log/system.log

    開いているファイルのプロセスを特定(lsofコマンド) - Qiita
  • 実行中プログラムのイメージを得る - tmtms のメモ

    Twitter見てたらこんなこと言ってる人がいました。 Unix で実行中の実行ファイルのパスを確実に得る方法はない、というのは FAQ だと思うけど、実際にやりたいことは自分自身を別プロセスで新たに立ち上げたいということなので、メモリにロード済の自分自身から別プロセスを作る手段はないんだろうか— Yusuke Endoh (@mametter) 2017年10月25日 昔自分もそんなこと考えたなーと思いつつ、Linuxなら /proc/<pid>/exe が実行ファイルへのリンクになってるんで、 環境によるような気もするけど、自分の実行ファイルのパスは /proc/pid/exe から取れないですかね。— とみたまさひろ (@tmtms) 2017年10月25日 と言ってみたら、 Linuxならその手が使えますが、現在実行中の実行ファイルでも削除できちゃいますから、パス名を得る完璧な方法

    実行中プログラムのイメージを得る - tmtms のメモ
  • Linux OOM Killerについて - Qiita

    OOMとは? Linuxは、メモリが不足してシステムが停止する恐れがある際、メモリリソースを多く消費しているプロセスを強制的に殺します。これをOOM Killerといいます。重要なプロセスでも問答無用で殺しにきます。 いるはずのプロセスがある日消えていたのなら、それはOOM Killerに殺されたのかもしれません 確認方法(CentOS) 5789のrubyのプロセスが殺されたことが分かります $ sudo cat /var/log/messages | grep Killed Oct 1 11:11:54 ip-xx-xx-xx-xx kernel: [1983378.957901] Killed process 5789 (ruby) total-vm:4957320kB, anon-rss:2717004kB, file-rss:0kB

    Linux OOM Killerについて - Qiita
  • #/usr/binとその同種の周辺を探る | POSTD

    (注:2017/04/10、いただいたフィードバックを元に翻訳を修正いたしました。) はじめに 私はLinuxが大好きです。コンピュータとのやりとりが楽しくなるし学ぶことも多くなります。OSとハードウェアの基盤となる基原則を学びたい人にとって、Linuxはとてもいい出発点と言えるでしょう。 ご存じのとおりLinuxとは大抵の場合プログラム(コマンド)を通してやりとりします。Linuxと他のUNIX系システムが持っている特徴は、コマンドラインと、パイプのコンセプトです。プログラムの提供する入力と出力を統合すれば、データを操作するのに非常にパワフルなプラットフォームになります。 Linuxのコマンド、プログラム、バイナリ(何と呼んでもいいのですが)の大部分は、/usr/bin、/usr/sbin/、/binそして/usr/local/binに存在しています。これらのディレクトリを見れば、プロ

    #/usr/binとその同種の周辺を探る | POSTD
  • systemdメモ - tom__bo’s Blog

    Ubuntuで、キーボードの数字と記号を入れ替え(シフト無しで記号、シフトありで数字になる)ようにしようとしていた。 .profileで予め用意したキーマップをxmodmapコマンドで上書きしようとしたけど、Unityに上書きされるのか、上手く書き換えられなかったので、Systemdを使ってどうにかしようとした時のメモ。 結局途中でキーマップの変更方法は正しい方法が見つかったので、やっていない。 まずはsystemdの仕組みがわかっていなかったので、調べた内容から。 参考のURLを読めば仕組みは詳しく書いてあるので、まずはそれを読む。 特徴 高速なシステム起動と終了 高い並列度でプロセスを扱う 設定ファイルによるシステム管理の共通化 柔軟なプロセス起動 タイマーによる起動 socketへの通信検出によるプロセス起動 所定のパスへのファイル作成をトリガーとしたプロセス起動 cgroupsによ

    systemdメモ - tom__bo’s Blog
  • シグナルの使い方と実装について - へにゃぺんて@日々勉強のまとめ

    今回は、Linuxのシグナルについて、自分なりにちゃんと調べてみましたので、 記事にまとめてみます。 ほとんどUNIXシグナルと変わらない話だとは思いますが、ソースコードは Linuxのものを参照しているので、Linuxに限った話も混じっているかと思いま す。 そもそも「シグナル」とは? 辞書を引いてみると、"signal"は signal 【他動】 〜に信号を送る、合図する、〜を信号で伝える 〜の前兆となる、〜を示す、示唆する、知らしめる文例 【名】 〔メッセージを伝えるための〕合図、信号、信号機 〔合図で伝える〕メッセージ、意図、警告 〔行動を起こす〕きっかけ、引き金 《電気》信号 【形】 信号の(働きをする) 際立った、目立つ、顕著な、目覚ましい、注目に値するとのことです。 signalの意味・用例|英辞郎 on the WEB:アルク http://eow.alc.co.jp/se

    シグナルの使い方と実装について - へにゃぺんて@日々勉強のまとめ
  • Linux Insides : カーネル起動プロセス part1 | POSTD

    ブートローダからカーネルまで これまでの私の ブログ投稿 を読まれた方はご存じかと思いますが、しばらく前から低水準言語を使うようになりました。Linux用x8664アセンブリ言語プログラミングについても書いています。また、同時にLinuxのソースコードにも触れるようになりました。下層がどのように機能しているのか、コンピュータでプログラムがどのように実行されるのか、どのようにメモリに配置されるのか、カーネルがどのように処理や記憶をするのか、下層でネットワークスタックがどのように動くのかなどなど、多くのことを理解しようと意欲が湧いています。これをきっかけに、 **x8664** 版Linuxカーネルについてシリーズを書いてみようと思いました。 私はプロのカーネルプログラマではないことと、仕事でもカーネルのコードを書いていないことをご了承ください。個人的な趣味です。私は下層で何が起きているのかと

    Linux Insides : カーネル起動プロセス part1 | POSTD
  • プロセスのランキュー待ち時間とI/O待ち時間を調べる - ablog

    cat file|awk では実行時間 < CPU時間となっていますが、cat が I/O wait していないとは限りません。実行時間は単純に終了時間 - 開始時間で算出しますが、CPU時間はプロセスのCPU時間を getrusage システムコールで取得します。catのプロセスと awk のプロセスが並列実行されている期間があるため、実行時間 < CPU時間となっています。例えば、CPUバウンドな2プロセスがほぼ完全に並列実行されると、実行時間 * 2 ≒ CPU時間 となったりします。 (中略) 大きなテキストファイルをawkで処理するときにcatで投げ込むと速い理由 - ablog と書きましたが、プロセスの ランキュー待ち時間は /proc//sched の2列目(sched_info.run_delay) I/O待ち時間は /proc//schedstat の se.stati

    プロセスのランキュー待ち時間とI/O待ち時間を調べる - ablog
  • 技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか?(擬似端末, Pseudo Terminal, SIGHUP他) - Glamenv-Septzen.net

    ホーム 検索 - ログイン | |  ヘルプ 技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか?(擬似端末, Pseudo Terminal, SIGHUP他) [ Prev ] [ Next ] [ 技術 ] 何をいまさら当たり前の事を・・・と思われるだろう。 $ nohup long_run_batch.sh & SSHからログアウト後も実行を続けたいバッチジョブを、"&"を付けてバックグラウンドジョブとしてnohupから起動するのは定番中の定番である。 しかし、「nohupを使わなくても実行を続けることが出来る」やり方があったり、さらには「nohupを付けてもログアウト時に終了してしまう」パターンがあるとしたらどうだろう? そして、ある日あなたの後輩や同僚がこれらについてあなたに質問してきたら、あなたはどう答えるだろうか? 「Web上で検索したら見つか

  • Linux Advent Calendar 2014 14日目: sched-design-CFS.txtの和訳 - hiraku_wfsの日記

    Linux Advent Calendar 2014 こんにちは、hiraku_wfsです。 今年はLinux KernelのDocumentation/scheduler/sched-design-CFS.txtを和訳してみました。 過去には2009年頃にsyuu1228さんが機械翻訳ベースの和訳を試みています(sched-design-CFS.txtの和訳 - syuu1228's blog)が、今回v3.18-rc7のものを訳してみます。 ところどころ(ちょっとやりすぎかもしれない)意訳を入れています。 �場所によっては原文を見た方が分かりやすい箇所がいくつかあるので、原文と併記しています。 (やっぱり翻訳の専門家ではないので日語でどう表現したものか悩んだりと結構大変でした...) 原著作者: Ingo Molnar ============= CFS Scheduler CFSス

    Linux Advent Calendar 2014 14日目: sched-design-CFS.txtの和訳 - hiraku_wfsの日記
  • Linuxのプロセススケジューラ(Reading the Linux process scheduler)

    1. Linuxのプロセススケジューラ (Reading the Linux process scheduler) Copyright Hitachi Ltd. 2014. All rights reserved. 日立製作所 横浜研究所 豊岡 拓 (hiraku.toyooka.gu@hitachi.com) ! Linux 3.15.0版 2. プロセススケジューラに関す るトピックの全体像 プロセススケジューラ スケジューリング・クラス CFS Real-time Copyright Hitachi Ltd. 2014. All rights reserved. Dead-line ロードバランスグループ・ スケジューリング カーネル内 プリエンプション stop idle 省電力 割り込み, スピンロック プロセス/スレッド, 時間管理, 高精度タイマ, tick管理, etc..

    Linuxのプロセススケジューラ(Reading the Linux process scheduler)