成長は小さな失敗の積み重ね 事業を支えるCARTAのフルサイクルエンジニアリング / growth-for-small-fail-fast-carta-fullcycle
レナートがsystemdの構想について語ったブログエントリーの翻訳。 原文はこちら: Rethinking PID 1 投稿は2010年4月30日とかなり古いものではあるが、この時点で現在に至るまでのsystemdの設計思想がしっかり示されており、いまもなお色あせていないと思う。 レナートからブログエントリーの翻訳の許可を取り付けたので、せっかくだから一番最初に訳すのはこの記事にしたい。 一気に訳すだけの気力と時間はないので、何回かに分けて訳す。 記事を分割すると検索性が落ちるので、この記事に加筆修正していく。 最初からきちんと訳せるという気はしておらず、誤字・脱字・誤訳がたぶんいっぱいある。 なので、見つけた方はご指摘ください。徐々にいいものにしていきたい。 *1 PID 1 を考え直す 十分な関わりがあったり、行間を読むのが得意であったりすれば、このブログ投稿が何に関することかはもう察
他のプロセスを中断せずに、その出力をミラーリングして新しくパイプで繋ぐ、そんなことはできるのでしょうか。 straceやgdbといったコマンドは一体どういう仕組みで動いているのでしょうか。 ptraceシステムコールを使い、プロセスが呼ぶシステムコールを調べて出力を覗き見するコマンドを実装してみたいと思います。 ptraceシステムコール Linuxを触っていると、いかにプロセスを組み合わせるか、組み合わせる方法をどれだけ知っているかが重要になってきます。 パイプやリダイレクトを使ってプロセスの出力結果を制御したり、コードの中からコマンドを実行して、終了ステータスを取得したりします。 プロセスツリーやプロセスグループを理解し、シグナルやnohupコマンドを使ったりします。 プロセスの扱いに慣れると疑問に持つのがstraceやgdbの仕組みです。 プロセスの実行しているシステムコールを出力し
はじめに 脆弱性対応のためのアップデート作業というものは頻繁に発生するものですが、本番運用しているシステムではサービスへの影響を最小限にしたいものです。 アップデートした後、出来ることなら必要なプロセスだけリスタートさせることで済ませたいのですが、どのプロセスをリスタートすれば良いのか、そもそもOS再起動しないと反映されないものなのか、判断が付かない場合が少なくありません。 そのような場合のため、再起動が必要なプロセスを見つけたり、OS再起動が必要かどうかアドバイスしてくれるコマンドがあります。 Redhat系 「yum-utils」パッケージに入っている「needs-restarting」コマンドを使います。 # needs-restarting -h Usage: needs-restarting: Report a list of process ids of programs th
はじめに これは Linux Advent Calendar 2016 の第 11 日目の記事です。Linux のタスクスケジューラーのソースコードや関連するドキュメントなどを読んで分かったことをまとめました。とても長いです・・・ はじめにスケジューラーのアーキテクチャと重要な概念を紹介し、その後はスケジューラーコアとシステムコールの実装について分かったことを延々と述べます。調べきれなかったことや分からなかったことは TODO に残したので、コメント欄とかツイッターで教えてもらえると嬉しいです。間違いの指摘も大歓迎です。 ちなみに私が読み始めたきっかけは、スケジューラーのアーキテクチャ、スケジューリングアルゴリズム、スケジューリングアルゴリズムの切り替え方、nice 値やプロセッサアフィニティがスケジューリングに及ぼす影響、プリエンプションの流れ、マルチプロセッサにおけるタスクのロードバラ
暴走してどんどんメモリを食うスクリプトが OS全体のメモリ使用量(CentOS5 ... カーネルは2.6系になる)の動作にどんな影響を与えるのか ってのを見るために以下のようなテストをしてみました。仕組みはだいたい理解してるけど、細かい数値を追ったことはなかったのでやってみました。 sshでログインして、topを立ち上げる。プロセスを見張る用意をしておく 別のsshをたちあげて、 Perlワンライナーで以下のようなプロセスを走らせる(このプロセスをtopで見張る) # 1秒ごとに5MB単位でメモリを食うプロセス # 数値はお好みで perl -e "while(1){ sleep 1; push @h , 1 x 1024 x 1024 x 5 } " ちなみにtopで見張るときは メモリ使用量でソートされるようにして top起動中に shift + o を押して n を押すと 実メモリ
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
UNIX(Linux)のプロセス起動は createProcess というような1つのシステムコールではなく、fork と exec の組み合わせ(Fork-Exec)で実現される。 fork は現在のプロセスをまるまるコピーし、別々の実行コンテキストを作る。 fork への戻り値をそれぞれのコンテキストで変えて区別させる。 仮想メモリ空間の情報もコピーされる。 exec は自プロセスを別のバイナリ実行用プロセスに置き換える。 fork と exec が分かれており、かつ、fork が親プロセスの仮想メモリ空間をコピーしていることで、親プロセスと子プロセス(または子プロセス同士)の間の通信用のパイプを作る処理を fork と exec の間で行うことができる。 「fork」『フリー百科事典 ウィキペディア日本語版』より Fork-Execは、UNIXで一般的に使われる手法であり、新たなプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く