LinuxサーバでネットワークI/Oで刺さっている接続先を発見する - ゆううきメモ
Linuxサーバの障害対応で社内で伝統的に使われているテクニック。I/Oで完全にブロックしているポイントを特定するノウハウ。 問題対応のため、怪しいプロセスをstraceしてみる read(2)やwrite(2)でブロックしていることを発見する read(2)やwrite(2)、connect(2)の引数にはファイルディスクリプタ番号がみえる プロセスIDとファイルディスクリプタ番号を使って、/proc//fd/ の中身をみると、ソケットI/Oで刺さっている場合はソケット番号を発見できる netstat からソケット番号でgrepして接続先を発見する [y_uuki@hogehoge ~]$ sudo strace -p 10471 Process 10471 attached - interrupt to quit read(58, <unfinished ...> Process 10
Big Sky :: 書評：［試して理解］Linuxのしくみ
Twitter で「読みたい」と呟いたら著者の武内覚さんから献本しましょうかとお声を掛けて頂いたので即答でお願いしました。 僕はいつも Linux でしか動作しないソフトウェアを Windows に対応させるパッチを書いたりしているので、普段 Windows しか触っていないと思われがちですが、実は僕が Linux を触り始めたのは 1996 年にトッパンから出版された「Linux 入門」くらい昔だったりします。ちょうど Linux 2.0 が出た頃だったと思います。その頃の Linux はようやく SMB カーネルが出た頃で、まだまだお遊び感のある OS で不安定でもありました。ディストリビューションもほぼ Slackware くらいしか無かったかもしれません。 あの頃の Linux はインターネットを検索しても殆ど情報が出て来ず、本気で調べるにはソースコードを読むしかありませんでした。
Linuxカーネルを読む前にやったこと - komukomo’s diary
「カーネルのコードがよくわからない。Linuxカーネルに関する本を読んでもいまいちしっくりこない。」 から、「読めば理解できそう..!」 になるまでにやったことのまとめ。 はじめに 低レイヤの話がわかるようになりたかった。 カーネルの中身が知りたかった。 とりあえず本を読もうと思い詳解 Linuxカーネル 第3版を読んだが知識がなさ過ぎてよくわからない。 知らない用語だらけで都度調べればなんとなくはわかる気もするが、いまいち頭に入ってこない。 今思うとそもそもCPUの話なのかカーネルの話なのかさえよくわからない状態で読んでいたような気がする。 そんな状態を克服するためにやったことをまとめておく。 学習前 学習前の自分の知識はこんな感じだった。 知っていた データ構造とアルゴリズム 論理回路 C言語（研究室で数値計算に使える程度。構造体やポインタくらいならわかる。） よく知らなかった OSが
超高速なパケットI/Oフレームワーク netmap について - ゆううきブログ
GPUを用いたSSLリバースプロキシの実装について - ゆううきブログ 100Gbpsソフトウェアルータの実現可能性に関する論文 - ゆううきブログ の続きで，最近論文読んだやつのプロジェクトの紹介です． 概要 今の汎用OSは高速なパケットI/Oを考慮してない． 20年前のAPIをそのまま使っている． ネットワークがどんどん高速になっているので，NICとかOSカーネルのパケット処理がボトルネックになってる． (http://news.mynavi.jp/news/2013/04/04/094/index.html) こういうの解決するために既存手法がいろいろある． Linux packet mmap - IwzWiki Linux Kernel Documentation :: networking : packet_mmap.txt DNA (Direct NIC Access) Pac
消すだけなのに rm -rf がいっつも長くて待ちきれない問題 - kuenishi's blog
rmコマンドで大量のファイルを削除しようとするとjournaldがめっちゃリソース持っていく件— bokko (@cubicdaiya) 2017年8月3日 今時のファイルシステムはみんなジャーナルもってて何かあったときにそこからリカバリする仕組みになってるので、当たり前といえばそうなんだけども。 （TODO: ここにファイルシステムのツリー＋ジャーナルのポンチ絵を手描きでも何でも描く） ご本尊のデータのツリーと何らかのWALを1セットで持っておくのはRDBだろうがファイルシステムだろうがそうは変わらない、で、削除についても並行制御をうまくやるために削除フラグをログに入れておいてあとで本尊のデータを整理するというのが基本的な設計になる。そこで私は立ち上がった（TL;DR: 特にオチとかはないです）。 rm -rf が遅いのは人類にとって損失ではないか。もっと速く完了するようにすれば、 rm
#きょうのsystemd: (翻訳)PID 1 を考え直す - ぽぽの備忘録
レナートがsystemdの構想について語ったブログエントリーの翻訳。 原文はこちら: Rethinking PID 1 投稿は2010年4月30日とかなり古いものではあるが、この時点で現在に至るまでのsystemdの設計思想がしっかり示されており、いまもなお色あせていないと思う。 レナートからブログエントリーの翻訳の許可を取り付けたので、せっかくだから一番最初に訳すのはこの記事にしたい。 一気に訳すだけの気力と時間はないので、何回かに分けて訳す。 記事を分割すると検索性が落ちるので、この記事に加筆修正していく。 最初からきちんと訳せるという気はしておらず、誤字・脱字・誤訳がたぶんいっぱいある。 なので、見つけた方はご指摘ください。徐々にいいものにしていきたい。 *1 PID 1 を考え直す 十分な関わりがあったり、行間を読むのが得意であったりすれば、このブログ投稿が何に関することかはもう察
「ふつうのLinuxプログラミング」でLinuxの基本概念やシェルの仕組みについて学んだ - $shibayu36->blog;
最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon この本はLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる本。この本を読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの？ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ
ファイルディスクリプタとかulimitとか/proc/sys/fsとかめも - tweeeetyのぶろぐ的めも
はじめに ファイルディスクリプタについては理解も薄かったのでこの機会にメモ 参考 主にこちらのサイトを参考にさせて頂きました →絵で見てわかるファイルディスクリプタ・パイプ・リダイレクト →Linuxのファイルディスクリプタ数を変更・確認する方法 →180style wiki>ファイルディスクリプタを確認する →ファイルディスクリプタ数の上限変更とlimits.confの罠 補足 こんなのもあります →ファイルディスクリプタをperlで見てみたいときメモ ついでに td-agent(fluentd)を使うにあたってファイルディスクリプタについてこんな表記がある ファイルディスクリプタの最大数を増やしてください。現在の数値は ulimit -n コマンドで確認できます。 →treasure dataさんの「Fluentdインストールの前に」ページです ファイルディスクリプタについて ファイル
日常から使えるUnix系OS業務効率up技 - Qiita
気分転換に、普段からLinuxで作業する上で割と便利なツールだったり小技を共有します。知ってたらごめんね 一応全部MacでもLinuxでも動くはずです。 高速化系 axel , aria2c http://qiita.com/sarumonera/items/2b30999d7d41a4747d74 https://goo.gl/gsFrCT https://wiki.archlinuxjp.org/index.php/Aria2 http://qiita.com/TokyoMickey/items/cb51805a19dcee416151 こいつらは割と有名（？）かなと思います。やってることはcurlやwgetとほとんど変わらず、サーバにHTTPリクエストを送ってレスポンスを取ってくるだけなのですが、ダウンロードを高速化するためにtcpコネクションを何本も貼って、相手サーバーに負担をかけ
Linuxメモ : topの代わりとして使えそうなコマンド（glances, ctop, gtop, htop, vtop, cpustat）を試してみる - もた日記
glances インストール 使い方 ctop インストール 使い方 gtop インストール 使い方 htop インストール 使い方 vtop インストール 使い方 cpustat インストール 使い方 GitHubを眺めていたらtopの代わりとして使えそうなコマンドが色々あったので試してみる。 glances Glances - An Eye on your system（公式ページ） github.com glancesは色々な情報を表示できるモニタリングツール。 インストール pipでインストールできるので下記コマンドを実行。 $ pip install glances 使い方 glancesで起動できる。図のように色々な情報がまとめて表示可能。 ブラウザで確認できるWebサーバモードや、リモートマシンを監視するクライアント／サーバモードもあるようだ。 ctop ctop（公式ページ
Ryzenにまつわる2つの問題 - 覚書
NOTE1: 2017/8/12に2つ目の問題について更新しました。ついに両方の問題が解決しました。 NOTE2: 2つ目の問題についてはすべての経緯をまとめた書籍があります。 4月にRyzenを積んだデスクトップマシンを買いました。その上で日課であるカーネルビルド&テストをした*1ことをきっかけに、2つの問題が発生しました。先代のCore i5を積んだマシンでは起きなかった現象です。 このエントリは自分用のメモがてら、新しいことがわかれば随時更新していきます。後者については9月に開催されたkernelvm北陸にて、本ブログには書かれていない解析の詳細などについて発表してきました。 Ryzen segv battle from Satoru Takeuchi www.slideshare.net 環境 ハードウェア CPU: Ryzen 1800X Motherboard: ASUS PR
lsコマンドに替わるコマンド「exa」とは
nixCraftに8月4日(米国時間)に掲載された記事「exa a modern replacement for ls written in rust for Linux/Unix｜nixCraft」が、lsコマンドのモダン代替候補として「exa」コマンドを紹介した。exaはRustで開発されたls系コマンド。サイズが小さく高速に動作し移植性も高いという特徴がある。 exaコマンドはlsコマンドと似たような動作をするが、最初からカラーでの表示を前提に開発されており、カラー対応のlsコマンドよりも多くの情報を色分けして表示する。また、拡張情報の表示、ディレクトリのツリー表示、Gitステー経つの表示など、lsコマンドが提供していない機能も提供している。
Bashのよくある間違い | Yakst
原文は2015年8月22日時点のものを利用しており、それ以降に追記、更新されている可能性があります。 本翻訳は原作者の許可を得て公開されています。 Thanks for GreyCat! このページはBashプログラマーが陥りがちなよくあるエラーについてまとめました。以下の例は全てなんらかの欠陥があります。 クオートをいつも使い、どんな理由があっても単語分割を使わなければ、多くの落とし穴からあなた自身を守ることができます！単語分割はクオート表現をしない場合にはデフォルトでオンになっている、Bourneシェルから継承された壊れたレガシーな設計ミスです。落とし穴の大半はクオートされていない展開になんらか関連し、単語分割しその結果をグロブします。 1. for i in $(ls *.mp3) BASHプログラマーたちがループを書く際にもっとも犯しがちなよくあるミスは以下のような感じです。: f
bashスクリプトをデバッグする方法 - Qiita
#!/bin/bash exec 5> debug_output.txt BASH_XTRACEFD="5" PS4='$LINENO: ' set -x するとdebug_output.txtにログが出力される。 exec 5>はファイルディスクリプタ5番をdebug_output.txtにするという意味。 PS4はトレース出力の際に表示されるプロンプト。$LINENOにより行番号を表示している。 set -xは実行するコマンドをトレース出力させる。 元記事にはbashdb、log4bash、Eclipse、Visual Studioo Codeを使う方法なども紹介されているが、これが一番手軽でほとんどの場合十分だと思う。 Register as a new user and use Qiita more conveniently You get articles that match
ビルド職人になるために覚えたコマンドメモ - ainameの日記
ここ2年ぐらいffmpegとかopencvとかRuby + CUDAみたいなやつとか たまーにビルド職人になることがあって上手くコンパイルするために各種コマンドを使うことがあるのだけど、 使い方はおろか、普段あんまり使わないのでコマンド名すら忘れることが多々あるためコマンド名とか使い時を覚えている限りざっくりメモしとく。 あとはmanを読めば良い。 pkg-config インストール済みのライブラリをコンパイルに利用するときに必要なコンパイルオプションを返してくれるやつ .pcファイルを元に返してくれる。 PKG_CONFIG_PATHを指定して利用したりする。 ldd .so（Shared Object）ファイルが動的リンクで依存しているライブラリへの依存関係を表示してくれる。 何かをコンパイルした結果、共有ライブラリがリンクできているかを調べるのに使える。 $ ldd `which f
ptraceシステムコール入門 ― プロセスの出力を覗き見してみよう！ - プログラムモグモグ
他のプロセスを中断せずに、その出力をミラーリングして新しくパイプで繋ぐ、そんなことはできるのでしょうか。 straceやgdbといったコマンドは一体どういう仕組みで動いているのでしょうか。 ptraceシステムコールを使い、プロセスが呼ぶシステムコールを調べて出力を覗き見するコマンドを実装してみたいと思います。 ptraceシステムコール Linuxを触っていると、いかにプロセスを組み合わせるか、組み合わせる方法をどれだけ知っているかが重要になってきます。 パイプやリダイレクトを使ってプロセスの出力結果を制御したり、コードの中からコマンドを実行して、終了ステータスを取得したりします。 プロセスツリーやプロセスグループを理解し、シグナルやnohupコマンドを使ったりします。 プロセスの扱いに慣れると疑問に持つのがstraceやgdbの仕組みです。 プロセスの実行しているシステムコールを出力し
シェルスクリプト Tips | UNIX & Linux コマンド・シェルスクリプト リファレンス
シェルスクリプト Tips コーディング・スタイル ここに書かれている内容は、あくまで筆者の好みでありほぼ完全に主観ではあるが、経験的に行き着いたスタイルでもあるので推奨します。 スクリプトのヘッダを作成する 最近はあまり使用されることもないのかもしれないが @(#) の記述と、スクリプトの使用方法、および概要をファイルの前方にコメントとして記述しておくようにする。 ※ @(#) は what コマンドで参照する情報を記述するための記号です。詳細は「whatコマンドについて」を参照。 #!/bin/bash # # @(#) hoge.sh ver.1.0.0 2008.04.24 # # Usage: # hoge.sh param1 param2 # param1 - パラメータ1です. # param2 - パラメータ2です. # # Description: # hoge.shスク
Linux のページ回収まわりのカーネルパラメータ - ablog
Linux(kernel 2.6.32-303 以降)のDBサーバでメモリ16GB、スワップ領域16GBの場合、ざっくりこんな感じが良いかなという妄想メモ。 vm.swapiness=1 vm.overcommit_memory=2 vm.overcommit_ratio=80 vm.min_free_kbytes=524288 vm.extra_free_kbytes=1048576(kernel 3.5以降) vm.swappiness=1 でページアウトよりページキャッシュ解放を優先させる。kernel 2.6.32-303 以降、0 にすると OOM Killer が発動しやすくなるらしいので、1 にする。 vm.overcommit_memory=2 でオーバーコミットしないようにして、OOM Killer が発動しにくくする vm.overcommit_ratio=80 で仮想
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux環境設定/bashのプロンプトに現在の時刻や、作業内容のメ の編集 - Linuxと過ごす
シェル芸初心者によるシェル芸入門
