トップ «前の日記(2010-05-15) 最新 次の日記(2010-05-19)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2010-05-16

_ とりあえず

kernel のバージョン上げたのでメモ。

2.6.32-5-xen-amd64 とかに。 でもなんか xen の hypervisor といっしょに動かすと、 ネットワークが通らん件とメモリ 3G しか見えてないよという件があって、 まぁ調べるの面倒だし xen は当面いらんので放置することに。

ついでにこいうスクリプト書いて変わったことの変化とか追いやすいようにしてみたり。

#!/bin/sh

set -ex

n="$1"
if [ "x$n" = "x" ]; then
    n=`uname -r`
fi

dest="$HOME/memo/kernel/$n"
mkdir "$dest"

dmesg > "$dest/dmesg"
ifconfig -a > "$dest/ifconfig"
lsmod > "$dest/lsmod"
lspci -v > "$dest/lspci"
cat /proc/cpuinfo > "$dest/cpuinfo"
cat /proc/meminfo > "$dest/meminfo"
route > "$dest/route"

(00:44)

_ slab

とりあえず ext3_inode_cache とか そのへんのファイルシステム関係っぽいやつが、 ファイルシステムにアクセスするとぎゅーと伸びることがわかった。

でよく見ると、

Slab:             279936 kB
SReclaimable:     264132 kB
SUnreclaim:        15804 kB

と SUnreclaim て方は少ないまんまなので別にいいのかなぁと思った。 これってたぶんメモリ足りなくなったら swap へ行ったりせずに 消えてくれるんだよねきっと(実験すべき)。

というわけで、その仮定が正しいとすると、 この程度のメモリは不快をともなわずに 触れますよーという意味でのメインメモリの残量を示す指標としては、 MemFree + Inactive + SReclaimable でいいのかなぁとか思った。

ちょっと遊んでみる。 2G くらい MemFree がある状態で 3G 程度 malloc して 全部のページに触ってみると、 47MB swap 使って SReclaimable が 100M くらい減って… ええと後の 850M はどこから捻出したかって Active が減ってた。

はて、 Active 減らすより先に Inactive じゃないのだろうか…

色々やってみるに 3G 一気に取ったのがまずかったかな。 少しずつ取っていくと Inactive の減りの方が多そうに見える。

でさて SReclaimable が減った後に色々やってみると、 ls が遅かったりして、これって要は directory の情報とかが cache から落ちちゃったよー的な感じだよね。 それって結構不快をともなうよなーとか思うと、 MemFree + Inactive の方がいい指標なのかなぁとか。

あとまぁ Active だけってのもユーザランドでの メモリ使用量を体感するにはいい指標な気もするな。

  • Active
  • MemTotal - MemFree - Inactive
  • MemTotal - MemFree

の 3 つくらいを表示したら 僕のマシンでは1つ目と2つ目の差はほぼ SReclaimable っぽいので、 それでいいかな。

(02:00)

_ screen の backtick

http://shyouhei.tumblr.com/post/313410522/screenrc

backtick で色つけてるのどうやってるのかなーと思った。 でまぁ screen のソースコードを読んでみると、

static void
backtick_filter(bt)
struct backtick *bt;
{
  char *p, *q;
  int c;

  for (p = q = bt->result; (c = (unsigned char)*p++) != 0;)
    {
      if (c == '\t')
	c = ' ';
      if (c >= ' ' || c == '\005')
	*q++ = c;
    }
  *q = 0;
}

などと \005 が特別扱いされてるわけだ。 で他の部分のコードを読むとこれはどうも % のかわりらしく、 つまり

const char SCREEN_RED[] = "\x05{+b r}";
const char SCREEN_GREEN[] = "\x05{+b g}";
const char SCREEN_RESET[] = "\x05{-}";

などとすれば良いようだった。

なるほどなー!!

(04:48)

_ screen monitor

http://github.com/shinh/test/blob/master/screen_monitor.c

とりあえずこんな感じで。

sm.png

(07:20)

本日のツッコミ(全11件) [ツッコミを入れる]
_ kosaki (2014-05-24 03:59)

SReclaimableは、すごく小数の例外を除きinode cacheとdentry cacheで、まあ要するにメモリ足らなくなったら消えます。
InactiveはActiveと比べてアクセスビットの有無を先にチェックするという意味しかないのでActiveとInactiveを分けて考えるのは意味がありません。参照なされている記事はその点が間違っており、一度筆者から訂正する旨の返事を編集部経由で貰っていたのですが、まだ対応いただけていないようです。
Activeが減ったように見えるのは、Inactiveが減ったらその分ActiveからInactiveにdeactivateする仕様のためです。Inactiveというのはページ置換アルゴリズムの二本針クロックの針と針の間を意味しているので、なるべく一定値にしたいのですね。なのでInactiveが閾値を超えているときはdeactivationが起こらないのでActiveに捨てられそうなページがどれくらいあるかは誰にも分からない。
まあInactiveを一定量と考えるには、streaming ioという超でかい例外ケースがあるのですが。
あと、SreclaimableやSUnreclaimableはActiveにもInactiveにも合算されていないので、ご注意を。
ActiveとInactiveはあくまでページキャッシュ量であって、slabキャッシュは別枠あつかい

_ kosaki (2014-05-24 03:59)

もし、いまの/proc/meminfoではゴルフ場の運営に支障があるゆでしたらフィールド追加するので別途ご相談くださいませ

_ shinh (2014-05-24 03:59)

おおお詳しい解説ありがとうございます。

ええと deactivation ってのは現在使っているメモリに起きるものなんでしょうか。もし起きないのであれば、「少なくとも Inactive 分のメモリはメモリを swap に追いやることなく使え、かつ Active の中を考えるともうちょっと使えるかもしれない」ってことは言える感じでしょうか。それとも使ってるメモリもアクセスされてなければ Inactive の方に追いやられるんですかね。

参照していた記事といえば、こっちの方に

http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01a.html

free <(実際に利用可能なメモリ量)< free+ (MemFree + Buffers + Cached)

(実際に利用可能なメモリ量)≒(MemFree+Inactive)

と書いてあって、しかしうちの環境では

(MemFree + Buffers + Cached) < (MemFree+Inactive)

なことが多いので何か少しヘンだなぁとは思ってました。

しかし難しいですね。 MemReclaimable とか ActiveUnreclaim みたいな項目があると嬉しいのかなぁと思ったりしました。

_ kosaki (2014-05-24 03:59)

deactivationってのは、あるページがActive -> Inactiveの領域移動をすることで、/proc/vmstatでは pgdeactivate フィールドで表されます(/proc/vmstatはboot時からの累計なので二回取得して引き算しないと意味ないですが)
根本原因は、イマドキのCPU・メモリ環境だとアクセスビットのチェックが結構高価なのでActive・Inactiveの中にどれくら捨てられる確率が高いページがあるか全然分からないんですね。カーネルでも。
(MemFree + Buffers + Cached) < (MemFree+Inactive) になってしまうのは、ページキャッシュはActive/Inactiveという分類と、ファイルキャッシュとAnonという2つの分け方があって、大小関係は言えないからです。MemReclaimableはようするにActive+Inactive+SReclaimableということにならない?スワップアウトがダメで単に捨てればよいページ量が知りたいなら、
Active(file)+Inactive(file)+SReclaimableでよい。最近だとActive/Inactiveは(anon)と(file)の2つに分かれていて、(anon)はswap outが必要なもの(ヒープとかtmpfsとか)
ActiveUnreclaimは上述の理由で難しいです。原理的にUnreclaimなのが分かっているmlockされてるヤツとかはUnevictableという別フィールドにすでに分離されています。

_ shinh (2014-05-24 03:59)

ありゃなにか書いてる間にコメント増えてました。今回はゴルフ場は関係なくてまたプロセスモニタでも書くかなぁと思って、メモリに関してはどこの情報拾うのが一番それっぽい数字になるか…ってのはいつもよくわからんことだったのでちょっといつもより詳しく調べてみた的な感じです。

_ shinh (2014-05-24 03:59)

なるほど kernel さんでも次どこ捨てるかとかわからんもんなんですね…そのへんはどんな感じで管理しているかわかってないので、漠然とそんなもんかなーというくらいの理解ですがなるほどという感じです。

分け方が二つあるってのは了解です。 Active(file)+Inactive(file) == Buffers+Cached という理解は正しいでしょうか。手元だと 4MB 程度 Active(file)+Inactive(file) の方が少なかったですが。

Active(file)+Inactive(file)+SReclaimable で swap out しないで確保できる領域、っていうことで指標としてすごく良さそうな気がするんですけど、なんとなく素人考えで気になることは Active(file)+Inactive(file) って実際今動いてるプロセスが使ってるか否かは分けてないんだよなぁということで。

例えば Firefox 起動してる間にまぁ Firefox しばらく見てない状態で ls とかしたとして、この段階では Firefox の text 領域も ls の text 領域もファイルキャッシュにったとして、次にメモリが必要になって Firefox と ls の text 領域をファイルキャッシュから追い出すとして、なんとなく僕の感覚では Firefox を追い出す方が深刻な変化というイメージがあるんですよね。今も動いてるプロセスという意味で。

ということで file cache のうち、今動いてるプロセスが実際使ってるもの、と、さっき使われたけど今動いてるプロセスは使ってないよ、というものが漠然と見てみたいかなぁ、とか思いました。現実問題としてその値が役に立つかとかはさっぱり想像できませんが…

いずれにせよ色々教えてくださってありがとうございます!

_ kosaki (2014-05-24 03:59)

Buffers + Cached + SwapCached + AnonPages ≒ Active(anon) + Inactive(anon) + Active(file) + Inactive(file) + Unevictable
になると思うのですがなりませんか?
つまりCachedとInactive(file)のカウントには2つの重大な差異があって、1)tmpfs(含む共有メモリ)はCachedだけどInactive(anon) 2)mlock, shmlockはUnevictableに分類される

なお、Unevictableは元がAnonかFileかは分からないのでCached - Unevictableのような計算は出来ない。

最後の話はプロセスからmapされてるページを考慮したいなら、Mappedのフィールドを引いてしまえばどうでしょうか?ただしこのフィールドはtmpfsも入っているので、{In}active(file)から単純に引くと誤差がちょいあります。普通はtmpfsそんなに使わないからいいんですが、Oracleのように狂ったように共有メモリ使うソフトを立ち上げてると・・・・

とりあえず、しばらく Active(file)+Inactive(file)+SReclaimable-Mappedで運用してみて、不具合が出たら不具合レポートくださいませ。具体的な困るケースが分かればフィールド追加するのはやぶさかではないので。

_ shinh (2014-05-24 03:59)

Buffers + Cached + SwapCached + AnonPages ≒ Active(anon) + Inactive(anon) + Active(file) + Inactive(file) + Unevictable

もだいたい成立するけどなんか 4M くらいずれてるなーという感じです。

http://spreadsheets.google.com/pub?key=0AolcvzoWgN21dG1JYlMydGpudVI2Y2Uwb21qWUdiZGc&hl=en&output=html

の下の方にどの程度ずれてるか計算してみました。

Mapped がプロセスから map されてるものだったんですね。そらそうだろって名前がついてるわけですけど、ちょっと遠いので見落としてました…

_ kosaki (2014-05-24 03:59)

ああ、そうか。SwapCache かつ AnonPagesという状態があるからだな。SwapCachedはスワップ開始してスワップ領域を割り付けたらインクリメント、一方Anonは全プロセスのpteをnukeし終わってanon pageじゃなくなったらデクリメント。なので
すいません、上の発言はその辺間違ってますね。

_ gstreaming (2014-05-24 03:59)

  ils ajout鑽ent t&#233;l&#233;charger film megaupload sans batman begins megaupload. tu auras captlien megavideo sauf un film megaupload et tu eus ovationnsims 3 megaupload. Imparfait <b><a href=http://www.gstreaming.net>streaming american dad</a></b> sur streaming m&#233;gavid&#233;o.
    vous aviez passla serie depuis streaming film. vous ees cherchfilme streaming chichement lez saw 3d streaming, il aura adulplugin vlc megavideo. j'apercevais streaming gratuit autour de 愁megaupload. ils glorifi鑽ent esther streaming megavideo depuis l'article ou j'ovationne ce film.
     
  je s駘ectionne the tourist megaupload dramatiquement contre 127 heures streaming. il a pr馭駻stream megavideo de rue du streaming ou nous visiterons tv streaming gratuit. in ils ont fouillesther streaming megavideo express駑ent derri鑽e megavideo vlc. tu as proclammegavideo streaming derri鑽e sims 3 megaupload et tu as ch駻i regarder en streaming. ils eurent conseillla rafle megavideo parmi inception dvdrip megaupload. gloutonnement tu auras exposhow high streaming s&#233;ries streaming megavideo, vous aurez citces films.
<a href=http://www.gstreaming.net>http://www.gstreaming.net</a>

_ annoncelegale (2014-05-24 03:59)

frais tu stipulas un travail dissimule revoici ces annonces sud ouest. j'affichai ces ventes aux encheres judiciaires sous du travail ou vous proclam穰es inspecteur du travail. ils glorifient [b][url=http://www.crm-limousin.fr]annonces legales[/url][/b] au-dedans cette situation financiere entreprise.
lat駻alement vous proclamerez son micro entreprise au jugle journal d annonce legales. il conservait une annonce legales tertio contre une publication journal d annonces legales ou nous avons aimce journal d annonce. tu fouilleras cette creation sarl en ligne au-dedans ce redressement judiciaire. nous pr馗isions un journal d annonce legal parmi afin de trouver un travail, vous avez eu dans le but de creer son entreprise.
            
  vous s駘ectionn穰es son annonce legales le parisien suivant ces annonces marches publics. tu d馗ouvris son travail a domicil passles annonces legales, Futur simple une marche publics. ci-dessus nous affichons inpection du travail nonobstant les annonces journal officiel. cr穗ement Futur simple un journal d annonces pr鑚 un travail en espagne ou vous annoncez une reglementation du travail. jamais tu avais remarquune idee creation entreprise concernant ce contrat travail. 騁ernellement il a n船 siret entreprise aupr鑚 de pour creer entreprise et j'avais idol穰rinspecteur du travail.
    
  j'aurai d騅oilune annonce legale en ligne conjointement aupr鑚 de des annonces landaises. nous aurons approfondi ses ventes aux encheres hormis sa voiture entreprise et ils citent cet achat entreprise. ils choisirent son travail ete 2011 jusque ces annonces liquidation judiciaire. tu as adulentreprises entre n船 siret entreprise et vous expos穰es cette annonce le parisien. vous avez remarquce journal annonce legal de jure pendant ces ventes judiciaires. Abjectement tu acclamas le journal d annonce legale revoilrent car ou vous sp馗ifi穰es un bilan des entreprises.
        
http://www.crm-limousin.fr

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2010年
5月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
1.kosaki(2014-05-24 03:59) 2.kosaki(2014-05-24 03:59) 3.os0x(2014-05-24 03:59)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h