タグ

プロセスに関するakaneharaのブックマーク (36)

  • いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか? を運用に生かす - エンジニアHub|Webエンジニアのキャリアを考える!

    エンジニアHub > 記事一覧 > いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか? を運用に生かす いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか? を運用に生かす Webアプリを動かして負荷をかけると、OSのプロセスという観点ではどのように見えるのでしょう? それを通して運用やトラブルシューティングではどういったことが分かるのでしょう? Linuxカーネルの開発者でもある武内覚(sat)さんによる解説です。 こんにちは、sat(@satoru_takeuchi)と申します。 コンピュータが誕生してから現在まで、最終的にエンドユーザが意識するアプリケーション開発はどんどん楽になっています。先人たちのたゆまぬ努力の結果、アプリ開発者はOSや、そのさらに下にあるハードウェアのことをほとんど意識することなく開発ができるよう

    いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか? を運用に生かす - エンジニアHub|Webエンジニアのキャリアを考える!
  • /proc/[pid]/stat まとめ - 中年engineerの独り言 - crumbjp

    いつも忘れるので、まとめておくことにした stat No フィールド scanf 説明 0 pid %d プロセス ID。 1 comm %s 括弧でくくられた実行形式のファイル名。実行形式がスワップアウトされているかどうかによらず、見ることができる。 2 state %c "RSDZTW" のどれか 1 文字。 R は実行中 (running)、 S は割り込み可能な休眠状態 (sleeping in an interruptible wait)、 D は割り込み不可能なディスクスリープの待機状態 (waiting in uninterruptible disk sleep)、 Z はゾンビ状態 (zombie)、 T はトレースされている (traced) か (シグナルにより) 停止している状態 (stopped)、 W はページング中 (paging) を表している。 3 ppid

    /proc/[pid]/stat まとめ - 中年engineerの独り言 - crumbjp
  • https://ubiteku.oinker.me/2016/08/09/how-do-erlang-microprocesses-work-internally/

    https://ubiteku.oinker.me/2016/08/09/how-do-erlang-microprocesses-work-internally/
  • パイプ処理における遅延評価の問題(SIGPIPE問題) - Qiita

    パイプ処理における問題といえば、例のcat file | while readの同一変数が別コンテキストになる問題でしょ?と思われたかもしれないですが、それとはまた別のお話でして。 上記のコードを実行すると、画面上には1~10が表示されます。 パイプ前段のプロセスが無限に標準出力する場合でも、パイプ後段のプロセスが必要な結果だけ取得できれば事足りるので、前段プロセスが愚直に最後まで計算を続けたりする必要はない。これはかしこい。 ただ、このようなイケてる遅延評価があだとなり、結果的に、ユーザの思惑に反する挙動をしてしまうケースもあります。 例えば以下のコードの場合、書かれてある通りに解釈すれば、来ファイルにはi=99まで出力されてしかるべきなんですが、実行してみるとi=15までしか出力されませんでした。 i=16を書き込もうとしたタイミングで、書き込もうとしたパイプが後段プロセスによってク

    パイプ処理における遅延評価の問題(SIGPIPE問題) - Qiita
  • シェルでパイプ元のプロセスを殺したい - Qiita

    (tcpdump | awk '{print $1}') & curl -s http://example.com > /dev/null kill $! cURLリクエストが終わった時に tcpdump を殺したい!$!で殺せるのは()を司るサブシェルだけだし…さてどうする? 解決策 プロセス単位ではなくジョブ単位で殺す 俺、なんでサブシェル上で動かしてるんだ!? ってことで原点回帰します。 %%は同一シェルプロセス内で最後に実行したバックグラウンドジョブを意味する ジョブとプロセスは1対1にしかならないと勝手に思い込んでいたけど、このようにサブシェルに載せる必要もなく2プロセスを1ジョブにまとめることが出来る。また、ジョブに対してのkillは、ジョブに含まれるプロセス全てに対するkillとして実行されるようだ。 …ただ、先頭プロセス以外の死に方が若干変わってしまう点にだけ注意。役目を終

    シェルでパイプ元のプロセスを殺したい - Qiita
  • デーモンプロセスの作り方を通じて色々なことを再確認した - えいのうにっき

    続き。今回はデーモンプロセスについて。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき パイプとソケットでのプロセス間通信を Ruby で再確認した - えいのうにっき デーモンプロセスについて知るときに前提知識として外せないのが、「プロセスグループ」と「セッショングループ」というふたつの概念らしい。まずはそれについて再確認する。 プロセスグループとセッショングループ プロセスグループ 今までずっとプロセス単体について見てきていたけど、実はプロセスというものは、全てがいずれかの「プロセスグループ」というものに属している。各プロセスグループには、ユニークな整数のIDが振られている

    デーモンプロセスの作り方を通じて色々なことを再確認した - えいのうにっき
  • Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき

    前回までの続き。なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 - 達人出版会をまだ読んでいる。遅読。 Unixプロセスとリソースの基礎を再確認した - えいのうにっき プロセスとの情報のやりとりについて再確認した - えいのうにっき プロセスの適切な扱い方を再確認した - えいのうにっき 今回は、Unixプロセスとシグナルの基礎について再確認していく。 Unixシグナル・事始め Unixシグナルの「いろは」 シグナルを再定義する シグナルハンドリングの注意点 Unixシグナル・事始め 前回、子プロセスの終了を待ち受けるのに用いた Process.wait は、実行するとそこで自身(親プロセス)の処理を止めて子プロセスの終了を待った。これは ブロッキング呼び出し と呼ばれる。 では「親は親で何か別の仕事をしたいとき」はどうするかというと、これから見ていくシグナルを上手に使うと実

    Unixプロセスとシグナルの基礎をRubyで再確認した - えいのうにっき
  • 【wait】Linuxで指定したプロセス・ジョブの終了を待つコマンド | UX MILK

    引数の数値にはプロセスIDまたはジョブ番号を指定します。ジョブ番号を指定する場合には、番号の前には「%」が必要です。 waitコマンドは指定した指定したプロセス(ジョブ)が終了するまで待ちます。プロセス(ジョブ)を指定しなかった場合は、バックグラウンドで実行しているすべてのプロセスの終了を待ちます。また、複数指定した場合は指定したプロセス(ジョブ)がすべて終了するまで待ちます。 引数なしで実行する 以下のシェルスクリプトでは、command1、command2、command3を同時にバックグラウンドで実行し、その3つのプロセスすべてが終了した後、waitコマンドが実行されcommand4が実行されます。

  • Linuxでプロセスのデーモン化 - Qiita

    プロセスと周辺の概念 TTY (仮想端末) |-セッション |-プロセスグループ |-プロセス 「TTY = セッション 1>N プロセスグループ 1>N プロセス」 プロセスの中の一つがセッションリーダーで、その中の複数がプロセスグループリーダー。 セッション TTYと結びついたログインセッションのこと。一つ以上のプロセスグループの集まりであり、セッションリーダーとなるプロセスが制御端末とやりとりをして端末切断時に子プロセスを全て終了させる役割を持つ。自身が属するセッション内でしかプロセスグループは生成できない。 プロセスグループ プロセスの集まりで、シグナルを他のプロセスへ送信することができる。メンバーはプロセスグループリーダーのプロセスIDをグループIDとして持つ。プロセスグループのリーダーになるにはsetpgid()かsetsid()を呼び出す。 fork() この関数を呼ぶとプロ

    Linuxでプロセスのデーモン化 - Qiita
  • 開いているファイルのプロセスを特定(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
  • スレッドの実際 -- Pthread と Java

    オペレーティングシステム II 電子・情報工学系 新城 靖 (臨時代講) <yas@is.tsukuba.ac.jp> このページは、次の URL にあります。 http://www.hlla.is.tsukuba.ac.jp/~yas/coins/os2-2002/2003-02-28 あるいは、次のページから手繰っていくこともできます。 http://www.hlla.is.tsukuba.ac.jp/~yas/coins/ http://www.is.tsukuba.ac.jp/~yas/index-j.html ■スレッドの実際 C言語での利用 -- Pthread Java言語での利用 (言語組込み) ◆スレッドとは スレッド(thread) あるいは、 軽量プロセス(lightweight processes) とは、 1つの保護の単位としての プロセス(タスク,あるいは,アド

  • 特定条件下のclone(2)を4倍速くする - 人間とウェブの未来

    とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。 そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。 22.38% [kernel] [k] copy_pte_range 18.44% [kernel] [k] zap_pte_range 11.13% [kernel] [k] change_pte_range 3.58% [kernel] [k] page_fault 3.32% [kernel] [k] page_remove_rmap また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。 sudo strace -T -o/dev/stdo

    特定条件下のclone(2)を4倍速くする - 人間とウェブの未来
  • パイプ出力を現在のシェル上のwhileに喰わせる上手いやり方 - Qiita

    これはコマンドの標準出力を1行ずつ f という変数に読み込んで何らかの処理を行うってやつです。 whileの中でやることがファイル操作などの一般的なことならこれで全然問題ないんですが、実行中のシェル環境に対する処理(具体的には変数の設定など)を行おうとすると期待通りにいってくれなくなります。例えばこんな感じ↓ # findで見つけたファイル名をfilesという配列変数に詰め込みたい files=() find -type f | while read -r f; do files+=("$f") done echo "${files[@]}" # 確かにfilesに値を入れた筈なのに空が出力される?? これはパイプで繋げると後ろのwhileがサブシェルで実行されてしまうために起こる現象です。噛み砕いて説明すると… 現在findを実行中のbashとは別に、パイプの後ろでもう一つのbashが起

    パイプ出力を現在のシェル上のwhileに喰わせる上手いやり方 - Qiita
  • 1.5 プロセススケジューラ - Linux Kernel Documents Wiki - Linux Kernel Documents - OSDN

    トップページへ Linuxカーネルに関する技術情報を集めていくプロジェクトです。現在、Linuxカーネル2.6解読室の第2章までを公開中。 目次まえがき第0章 Linuxカーネルの構成要素 0.1 Linuxカーネルとは 0.2 Linuxカーネルのソースコード 0.3 Linuxカーネル機能の概要 0.4 カーネルプリミティブ 0.5 プロセス管理 0.6 メモリ管理 0.7 ファイルシステム 0.8 ネットワーク 0.9 プロセス間通信 0.10 Linuxカーネルの起動 0.11 Linuxカーネルの動作例 Part 1 カーネルプリミティブ第1章 プロセススケジューリング 1.1 マルチタスク 1.2 プロセスとは? 1.3 プロセス切り替え 1.4 プロセスディスパッチャの実装 1.5 プロセススケジューラ 1.6 プロセススケジューラの実装 1.7 事象の待ち合わせ 1.8 最

    1.5 プロセススケジューラ - Linux Kernel Documents Wiki - Linux Kernel Documents - OSDN
  • スケジューリング - Wikipedia

    この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "スケジューリング" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL(2021年6月) 計算機科学においてスケジューリング(英: scheduling)は、スレッドやプロセスやデータの流れについて、システム資源(例えば、プロセッサ時間、通信帯域など)へのアクセスを与える方法である。システムを効果的に負荷分散するため、あるいはターゲットの Quality of Service を保証するためになされる。スケジューリングアルゴリズムは、マルチタスク(同時に複数のプロセスを実行)や多重化(複数のデータの流れを同時に転送)の発展とともに進化してきた。

  • Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる

    Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に

    Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる
  • コンピューター:C言語講座:fork,exec,pipeについて

    コンピューター:C言語講座:fork,exec,pipeについて このテーマはどちらかというとUNIX系の話題になってしまうのですが、PC系ではDOSの時代にはマルチタスクができませんでしたので、平行には走れませんでしたが、C言語の処理系独自の関数がたくさんありました。WindowsになってからはUNIX系と似てきましたが、まだ少し違うようです。 自分で作成したプログラムから他のコマンドを実行したい、ということは良くあることだと思います。例えば、ディレクトリーの中身を簡単に得たい場合などはUNIXではlsコマンドを実行させて、結果をもらうのが簡単に思い付くと思います。とくにUNIXのコマンドはそのように組み合わせて使いやすくできていて、必要な情報だけを明確に返答するコマンドがほとんどです(その分、初心者が自分でコマンドを使う時に不親切なのですが)。 system() 大抵の人が上記のような

  • プロセス毎のメモリ消費量を調べたい時に使えるコマンド - Qiita

    # ps aux | grep unicor[n] USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND user 1111 0.0 10.4 479180 177440 ? Sl Aug16 0:38 unicorn worker[0] -D -E production -c /RAILS_ROOT/config/unicorn.rb user 2222 0.0 10.5 547060 178604 ? Sl Aug16 0:39 unicorn worker[1] -D -E production -c /RAILS_ROOT/config/unicorn.rb user 3333 0.0 10.5 479180 178764 ? Sl Aug16 0:26 unicorn worker[2] -D -E production -

    プロセス毎のメモリ消費量を調べたい時に使えるコマンド - Qiita
  • そこまで遅くないShellスクリプトの書き方

    この記事は Shell Script Advent Calendar 2015 10日目の記事です。 9日目の記事はryoana14さんの麗しきawkの世界でした。 Shellスクリプトがいつまで経ってもまともに書けないMasWagです。書けないなりにも人の書いた(昔の自分が書いたものも多く含む)スクリプトを見てこれは遅いなと思うことはたまにあります。書き方のコツというか考え方が幾つかあると思うのでまとめてみようと思います。基的な話なので多分Shellスクリプトをあんまり普段書かない人向けだと思います。ShellはBashを前提として書きます。zshだともっと色々できるのかもしれないです。細かい説明は(そんなに細かくなくても?)省いているので適宜manやinfoを参照すると良いでしょう。 forkを減らす Shellでコマンドを使うということは多くの場合プロセスをforkしていることにな

  • Linuxhack.jp » デーモンプロセスの構造

    バックグラウンドで呼び出しがあるまで待機状態にあり、呼び出されるときにだけ動作する特殊なプロセスとして、デーモンプロセスがあります。デーモンプロセスは名前こそデーモンとついてますが、基的に通常のプロセスと同じです。しかし、その動作には通常のプロセスとは異なる点がいくつかあります。具体的にはfork()、exec()系などのプロセス生成の過程において、実行するシステムコールは通常のプロセスと変わらないのですが、デーモンプロセスの特徴を実現するために行うプロセス生成の工程が異なります。デーモンプロセスを作成するためには以下のような処理が必要になります。 ・ファイスディスクリプタのクローズ ・端末セッションとプロセスグループの切り離し ・ワーキングディレクトリの移動 ・ファイル生成マスク値の変更 ・SIGCHILDシグナルの処理 以上の項目はデーモンプロセスを生成する上で、実装すべき処理になり