Linuxのハードウェアに関する詳細情報を取得する『Inxi』コマンド | 俺的備忘録 〜なんかいろいろ〜
今回は、Linuxが搭載されているハードウェアのパーツごと、例えばサウンドボードやマザーボード、ハードディスク等のベンダーや型番といった詳細情報を取得出来るコマンド『Inxi』を紹介する。 1.インストール まずはインストールから。 以下のコマンドを実行しインストールを行う。 Debian/Ubuntu sudo apt-get install inxi RHEL系 sudo yum install inxi --enablerepo=epel 2.コマンドの実行 さて、それでは実際にコマンドを実行してみよう。まずはオプションを付けず、デフォルトの内容を表示してみる。 以下の内容は、実際に自宅で用いてるマシンのデータを表示している。 $ inxi CPU~Quad core Intel Core2 Quad Q9550 (-MCP-) clocked at 2833 Mhz Kernel~
ulimitが効かない不安を無くす設定 | 外道父の匠
limits.conf に書いても ulimit に効いていない、というのはよくある話です。 ulimit が少なくて困ったことはあっても、多くし過ぎて困ったことはほとんどないでしょうから、ドーンと全条件下でulimit設定を効かせる方法を紹介します。 ulimitが効かない問題 だいたいこんな内容だと思います。 SSHログインだと効かない su すると効かない OS起動時に自動起動したデーモンに効かない 普通はデーモンに効けばよいので、本当に困ったら起動スクリプトに直接書いたりしますが、方法としてはイマイチなのでちょっと工夫をします。 その前に・・・ PAMについて PAMというユーザー認証システムについてはググっていただくとして、よく出てくる /etc/security/limits.conf という設定ファイルは、PAMを通る条件下でしか有効になりません。 ではPAMを通るとはどうい
Linux サーバでの「Too many open files」対策について - akishin999の日記
Linux サーバでの「Too many open files」エラー対策について調べたのでまとめてみました。 確認した OS は CentOS 5.9 と CentOS 6.3 です。 「Too many open files」は Linux でプロセスが開けるファイルディスクリプタの上限に達してしまうと発生するエラーです。 「ファイルディスクリプタ」という名前ですが、 Linux ではソケットもファイルディスクリプタなので、ファイルを開いた場合だけでなく、ソケットを使って通信を行う場合にもファイルディスクリプタが使用されます。 そのため、Apache や Tomcat などで高負荷なサイトを運用している場合などには、比較的遭遇する確率の高いエラーではないでしょうか。 このエラーを回避するため、プロセスがオープンできるファイルディスクリプタの上限を変更します。 まずは以下のコマンドを実行
/tmpと/var/tmpの仁義無き戦い - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #課題 /tmpと/var/tmpどっちも大体一緒だからいいんじゃないかと思って/tmpにファイルをつくろうとしたら、プログラムが使用するものは/var/tmpにと叱られた。確かに、基幹系システムのディストリビューションだと何故か/var/tmp派の人が多かった気がする。じゃあ、linux系特有の宗派の問題なのか？と思い調べてみた。 #何が他のディレクトリと違うか 通常のディレクトリは、基本的にはファイルは削除しない限り消えない。 /tmpに関しては再起動するとファイルが綺麗さっぱり無くなる。 /var/tmpは再起動しても消えないがい
RST Packetが発生する理由 - LEVEL 05 BLOG
を探すことがたまにあるので、今まで遭遇した・調べて見つけたケースを書いておく [1]ListenしていないポートにSYNパケットが送信された場合、RSTパケットがSYNパケットの送信元に返される。 [2] Accept済みのソケットに対して、データを全て読み取っていない(EOFに達していない状態）でcloseを発行した場合にコネクションの相手側にRSTパケットが送られる。 [3] Linux限定だが、tcp_abort_on_overflowがonになっている状態で設定したバックログ以上の未Acceptのコネクションが張られた場合(http://linux.die.net/man/7/tcp) [4] tcp_max_orphans以上のorhanコネクションが張られた場合、orhanなコネクションに対してRSTパケットが送られる。 ＊orpahなコネクションってソケットがクローズされてる
プロセスのCPU使用率を制限する方法 - Qiita
CPU負荷制限 cpulimit というツールがあり、%指定でそのプロセス(子プロセス含む)のCPUの利用率を制限することができます。例えば infinity という単にシングルスレッドで無限ループするプログラムがあったとして、CPU使用率10%で制限するには以下のようにします。 この10%というのは1論理コアの割合です。100と指定すると論理コア1個分(100%)まで許可することになります。例えば4論理コアの環境ではこの値は0～400まで設定できます。なのでシングルスレッド・シングルプロセスのプログラムであれば100以上指定しても意味はありません。 infinityを2論理コア上で50%で制限すると、以下のようになります。 (↓では論理コア全部を100%として表示してます) 既に走っているプロセスに制限をかけることもできます。
減り続けるメモリ残量！ 果たしてその原因は!?
物理メモリ使用状況の把握には何を使う？ では、ストレージとの同期情報まで加味したメモリの使用状況監視を行うには、どうすればよいのでしょうか？ 実は現在（注2）のところ、「これで完ぺき」という方法はありません。ただ、それでは困るので、ここでは次善の策としてActiveとInactiveを監視する方法を挙げます。 ActiveとInactiveはvmstat -aやcat /proc/meminfoなどと入力することで取得できます（図5）。 Activeはページキャッシュや無名ページ（注3）のうち、最近利用したり、まだストレージとの同期が取れていない「捨てられない」ページです。Inactiveは、同じくページキャッシュや無名ページのうち、最後にアクセスされてからある程度時間がたち、ストレージとの同期も完了していて、すぐに捨てられるページです。よって、/proc/meminfoの出力でいうところ
installコマンドでコマンド数を減らす - @znz blog
mkdir とか touch とか chown とか chmod とか個別に実行しなくても install コマンドだけでまとめて出来るという話です。 問題例 Dockerfile の RUN などが典型的な例ですが、他でも例えば mkdir -p /home/foo/.ssh; chown foo /home/foo/.ssh; chmod 0700 /home/foo/.ssh のようなことをすることがあると思います。 特に Dockerfile の場合は RUN ごとにイメージがたまっていくこともあって、 ; や && でつなげて単独の RUN にまとめて書くことも多いと思います。 install でディレクトリを作る たとえば mkdir -p /home/foo/.ssh chown foo /home/foo/.ssh chgrp users /home/foo/.ssh ch
negative dentry と tmpfs で negative dentry がキャッシュされない理由について調べた - hibomaの日記
kazeburo さんの 一時ファイルとdentry cacheとメモリ を読んでからしばらくファイルシステム周りを調べていたのでした。 先のエントリで /tmp のファイル作成/削除を繰り返して dentry キャッシュ がもりもり溜まっていくのは negative dentry であることが理解できました。 negative dentry とは negative dentry とは 存在しない inode に対応する dentry です。 dentry キャッシュの役割は RAM より低速な HDD や SSD などの二次記憶装置からのディレクトリエントリの読み取りをメモリにキャッシュしておき高速化するためですが、negative dentry をキャッシュすることで存在しないディレクトリエントリの読み取りもキャッシュされます。 「存在しないのにキャッシュ？」がしばらくイミフだったので
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
どうしてメモリはスワップするのか！？
こんにちは。斎藤です。 最近、新しいスキー板が欲しいなと思っています。現在使っているOGASAKAの板は5年目に入り、メーカーからこれ以上はチューンナップ(メンテナンス)はできないよ、と言われてしまいました。もし、次に買うなら、スノーボーダーの人と一緒にパウダーに飛び込みやすいセミファットタイプが良いのかなと考えています。皆さんのオススメ、ぜひ教えてください。 さて、今日はLinux Kernel上でのメモリ管理、特にページ回収(Page Reclaim)とスワップに絞り、「スワップの理由」「ページを回収する仕組み」そして「スワップの様子を観察する」の3点に分けてお話しします。「スワップするのが気持ち悪い」と考えている方は少なくないと思いますし、私もそう考えていた時期がありました。しかし、それは本当に悪い事なのか、今回掘り下げて行きます。 ※主な対象Kernelは2.6.32(Red Ha
新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
RHEL(CentOS)6系でトラフィックをたくさん捌くサーバが死ぬ問題は6.5のkernel-2.6.32-431.el6以降で多分直る - このブログはURLが変更になりました
タイトルで言いたいことはすべて言った。 経緯 うちの場合はLVS+keepalivedなロードバランサなんだけど、ちょくちょくkernel panicになる問題が発生してた。 そこでcrashコマンドで解析してみた。crashコマンドの使い方はこちらが参考になる。Linux crash dump 読み方入門 # crash /boot/System.map-2.6.32-279.14.1.el6.x86_64 /usr/lib/debug/lib/modules/2.6.32-279.14.1.el6.x86_64/vmlinux /var/crash/127.0.0.1-2013-09-27-16\:21\:01/vmcore (snip) SYSTEM MAP: /boot/System.map-2.6.32-279.14.1.el6.x86_64 DEBUG KERNEL: /usr
TIME_WAIT状態のTCPコネクションを早く終了させるべくKernelをリビルド - 元RX-7乗りの適当な日々
以前、一度やったはずなのですが、すっかり忘れてしまっていて、結局調べることになったので、今回はここに作業ログを残しておきます。 TIME_WAITコネクションの増殖 一般的にネットワークアクセス数が極端に多いサーバでは、TIME_WAIT状態のコネクションが残留しがちです。 TIME_WAITの滞留時間が、Linuxデフォだと60秒になっているため、下記のエントリにも書きましたが、60秒の間に数十万レベルのリクエストが来るとあっという間にコネクションテーブルが埋まっていってしまうわけです。 で、別にTIME_WAITコネクションが多くなってしまうこと自体は、完全な悪というわけでもなく、 "net.ipv4.tcp_max_tw_buckets" あたりでキャップもできるし、それなりに制御して付き合っていけばいいわけですが、ローカルのTCPポートを使い切るようなケースだと、使えるローカルポー
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
コンテナ型仮想化「Docker 0.7」リリース。主要Linuxディストリビューション全対応、ストレージドライバ同梱、コンテナ命名も可能に
コンテナ型仮想化「Docker 0.7」リリース。主要Linuxディストリビューション全対応、ストレージドライバ同梱、コンテナ命名も可能に コンテナ型の仮想化は、ハイパーバイザによってハードウェアを仮想化する従来の方法とは異なり、OSの上に分離された複数のユーザー空間を作り出すことで、物理サーバの上に複数の仮想サーバを実現します。 ハイパーバイザ型に比べてコンテナ型は非常に軽量で、それがいまコンテナ型仮想化が注目される最大の理由になっています。一方、ハイパーバイザ型では仮想サーバごとに異なるOSが選べるのに対して、コンテナ型はその仕組み上、一種類のOSに限定されるという制限があります。 Dockerはコンテナ型仮想化ソフトウェアとしてもっとも注目度の高いソフトウェアといえるでしょう。バージョン0.7では主要なディストリビューションすべてで利用可能になったため、これからの普及に大きなはずみが
Linuxのメモリまわり - tmtms のメモ
ちょっと前から groonga を使うとプロセスサイズが肥大化するのが気になっていて、メモリ関係を色々調べていたのですが、そこでわかったことなどを書いときます。 malloc() しただけではOSのメモリは使用されない メモリを1GB獲得するだけのこんなプログラムを作って実行してみます。 #include <stdlib.h> #include <unistd.h> #include <stdio.h> #include <string.h> int main(int argc, char *argv[]) { char *p; char buf[1024]; int i; p = malloc(1024*1024*1024); gets(buf); for (i=0; i<1024*1024; i++) memcpy(p+i*1024, buf, sizeof(buf)); pause(
Linux のオーバーコミットについて調べてみた
Linux のオーバーコミットについて調べてみた Linux のオーバーコミットのはなし（これを書いたのは Linux 2.6.38 のとき） Linux カーネルは実メモリ以上にメモリをプロセスに割り当てることができる この仕組みをオーバーコミット (over-commit) と呼ぶ オーバーコミットでは，とりあえずメモリを malloc させて仮のアドレスを返しておき， 実際に使われる段になってはじめて実メモリを確保する． 実験ただ malloc し続けるだけのプログラムを作って実験してみる． このプログラムをメモリ 1 GB + スワップ 1 GB のホストで実行してみると， $ free -t total used free shared buffers cached Mem: 1022404 82992 939412 0 4172 12280 -/+ buffers/cache:
Linux女子部 systemd徹底入門
5. Open Cloud Campus 5 Linux女子部 systemd徹底入門！ Linuxの起動プロセス (1) 「システムBIOS」が起動ディスクからブートローダ（GRUB）をメモリに読み込んで実行。 GRUBは起動カーネル選択画面を表示して、指定されたカーネルと初期ラムディスクをメモ リに読み込んだ後に、カーネルを実行。 カーネルは、初期ラムディスクの内容をメモリ上のラムディスク領域に展開して、「initス クリプト」を実行。 – 初期ラムディスクには、ルートファイルシステムへのアクセスに必要なデバイスドライバと「init スクリプト」が含まれます。 ブートローダ （GRUB） /bootファイルシステム ② ブートローダが 読み込み ③ ラムディスク領域 に展開 起動ディスク物理メモリ Linuxカーネル 初期ラムディスク Linuxカーネル 初期ラムディスク
そのファイル、安全に更新できていますか？（アトミックなファイル操作：前編）
ハートビーツ最年長エンジニアの滝澤です。以前、弊社CTOにシニアおっさんエンジニアから若手エンジニアに向けて何か書いてくれと言われた気がしたので、アトミック（atomic）なファイル操作について3編に分けて紹介します。この内容は弊社の社内勉強会で話した内容をまとめ直したものです。 そのファイル、安全に更新できていますか？（アトミックなファイル操作：前編）←今回 そのファイル、安全に作成できていますか？（アトミックなファイル操作：中編） そのファイル、安全にロックできていますか？（アトミックなファイル操作：後編） 今回は「みなさん、安全にファイルの更新ができていますか？」ということについて、考えてみましょう。 あなたはあるサーバ上のファイルの更新を依頼され、もらったファイルをサーバ上でコピーして上書きしました。しばらくして、データに異常が発生したので調べて欲しいと言われました。さて、何が起き
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
