タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

linuxに関するdencygonのブックマーク (12)

  • 環境変数はどこの空間にいるのですか

  • bash 環境変数とシェル変数 webzoit.net

    環境変数とシェル変数とは UNIX/Linux及びシェルに限らず、他OS環境でも環境変数は利用されますが、シェル(bash)には環境変数の他にシェル変数があり、その環境変数とシェル変数には組み込み環境変数と組み込みshell変数、更に変数と特殊変数があります。 環境変数、シェル変数と言えば、一般には組み込み環境変数と組み込みshell変数を指しますが、他方、これらはユーザー定義ができるので、組み込み変数とはユーザー定義変数ではない環境変数やshell変数を指します。 環境変数とシェル変数のスコープ 尚、組み込み変数は、ログアウト後、再ログインしても常に利用できますが、ユーザー定義の環境変数やshell変数でコマンドラインから設定した変数については、有効な設定ファイルで設定しない限り、ログイン中のみ有効です(再ログイン時には存在しません)。 scriptやshell関数において設定された環境

    bash 環境変数とシェル変数 webzoit.net
  • シェル変数と環境変数の違いをコマンドラインで確認する - Qiita

    最近、調べ直したので、この機会にまとめておきます。 はじめに シェル変数は現在実行中のシェルだけで有効な変数ですが,環境変数はシェルから実行したコマンドにも引き継がれる変数です。 再入門 体で覚えるLinuxの基ITpro http://itpro.nikkeibp.co.jp/article/COLUMN/20060620/241337/ 絵にすると↓な感じでしょうか。これをコマンドで確認していきます。 シェル変数の基 「=」を使用することで変数を格納出来ます。また、変数の先頭に‘$’をつけることで、格納された値を参照出来ます。

    シェル変数と環境変数の違いをコマンドラインで確認する - Qiita
  • Page not found | Splyt

    Page not found | Splyt
  • 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 をキャッシュすることで存在しないディレクトリエントリの読み取りもキャッシュされます。 「存在しないのにキャッシュ?」がしばらくイミフだったので

    negative dentry と tmpfs で negative dentry がキャッシュされない理由について調べた - hibomaの日記
  • 不審なプロセスがないのにメモリ使用量が高い場合はslab領域の肥大化を疑うといいかも

    メモリのfreeが10%を切ったとアラートが飛んできた時の対応のメモです。 top を見てもあやしいプロセスが見つからなくて、 /proc/meminfo を見てみると slab領域の肥大が確認できました。 slabtop で dentry_cache が肥大化している事がわかったので、 echo 2 > /proc/sys/vm/drop_caches を実行しました。 というはなし。 freeコマンドで現在のメモリの使用量を確認する [root@bacchi ~]# free total used free shared buffers cached Mem: 1030516 971468 59048 1088 278348 166456 -/+ buffers/cache: 526664 503852 Swap: 2064380 654596 1409784 確かにこのサーバーはメモ

    不審なプロセスがないのにメモリ使用量が高い場合はslab領域の肥大化を疑うといいかも
  • 一時ファイルとdentry cacheとメモリ - blog.nomadscafe.jp

    わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem

  • サーバーのメモリが少しずつ圧迫される原因と対策を調べてみた - Qiita

    サーバーのメモリが slab_cache で占有される サーバーのメモリが数日で slab_cache に占有されるので原因と対策を調査した。 メモリの使用状況の調査 meminfo meminfo を見ると Slab のメモリ使用量が確認できる。 SReclaimable と SUnreclaim を足すと Slab になる。 $ cat /proc/meminfo | grep "Slab\|claim" Slab: 1654520 kB SReclaimable: 1631304 kB SUnreclaim: 23216 kB slabtop slabtop コマンドをたたくと top コマンドのように Slab の内訳が表示される。 dentry が最も多いようだ。 --once は1回出力で終了するオプション。 --sort=c はキャッシュサイズ順にソートするオプション。 sl

    サーバーのメモリが少しずつ圧迫される原因と対策を調べてみた - Qiita
  • アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog

    問題 アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について調べた。 該当のサーバでは、以下のようにメモリの使用率が徐々に上昇していく。 また、アプリケーションのプロセス自体がメモリを消費しているわけではない状態。 原因 調査すると、このバグ仕様を踏んでいるのではないかと思われるページを見つけた。 https://bugzilla.redhat.com/show_bug.cgi?id=1044666 内容としては、curlを実行した際に /etc/pki/nssdb/以下の存在しないファイル(毎回違うパス)に対してaccessシステムコールが大量にコールされ、 negative dentry cacheが溜まっていき、メモリ使用量が圧迫されるというもの。 実際、この状況が起きているサーバを調べるとメモリ使用率のうち多くを占めているのはnega

    アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog
  • Slabキャッシュをクリアした話 – CLARA ONLINE techblog

    こんにちは。グローバルソリューション事業部の渡辺です。 なぜかメモリ使用率が高い状況に遭遇 とあるNagiosサーバのメモリ使用率が異常に高いことに気付きました こちらのサーバの状態は以下のような感じです。 監視対象は20ノード程度で、ほとんどpingのみ。 Nagios以外にはこれといって動いていない。 CPU使用率やロードアベレージには余裕がある。 経験的にこんなにメモリを使うとは思えませんでした。なんか怪しいです。 グラフが間違えているんじゃないの?とfreeコマンドで確認してみます。

    Slabキャッシュをクリアした話 – CLARA ONLINE techblog
  • slab肥大化とdentry_cacheに辿り着くまでの話 - Qiita

    内容(3行) memoryの使用量を監視している所からアラートが来て調査した アプリケーションのheap使用率は高くなく、top等を見ても他に怪しいプロセスが存在しない /proc/meminfoからslab領域の肥大を確認、slabtopでdentry_cacheが肥大化している事がわかったので、echo 2 > /proc/sys/vm/drop_caches を実施した 何があったのか 運用中のとあるサーバーのmemoryが残り20%を切ったとアラートが来たため、調査を行った。 当初は何かしらのプロセスがメモリリークしているか何かだろうとあたりをつけていた。 freeで現状確認 キャプチャとるの忘れた… が、一旦確かにfree(buffers, cahceを足したもの)がtotalの20%を切っていることを確認。 topで確認する アプリケーションプロセスにメモリを大量消費しているプ

    slab肥大化とdentry_cacheに辿り着くまでの話 - Qiita
  • メモリの状況を見るとかとか(/proc/meminfo、ps、top、free、vmstat、dstat) - tweeeetyのぶろぐ的めも

    はじめに なんかやだなー遅いぽいなーと思ったとき見る指標がいろいろあるかと思いますが その中でも「メモリを見る」についてメモ 今回つかうコマンド 今回は下記のコマンド(ファイル)を使います less /proc/meminfo → マシンのメモリ情報を知ってみる ps aux | sort -r -k4 | head -n10 → メモリ消費順に表示してみる toptop表示後に大文字Mで消費メモリ順)→ 消費メモリ順を表示してみる free -m → メモリの動作状況を知る vmstat -Sm 1 10 → メモリの動作状況を知る dstat -tclm → vmstat+α的な感じで見てみる less /proc/meminfo マシンのメモリ情報を知ってみます これはまぁそのままですね。 # less /proc/meminfo MemTotal: 12144800 kB Mem

    メモリの状況を見るとかとか(/proc/meminfo、ps、top、free、vmstat、dstat) - tweeeetyのぶろぐ的めも
  • 1