(This post is also available in English.) この記事は In defence of swap: common misconceptions を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。 長文を読みたくない方への要約: スワップを持つことは正しく機能するシステムのかなり重要なポイントです。 スワップが無ければ、まともなメモリ管理を実現することは難しくなります。 スワップは一般的に緊急事態用のメモリを取得するためのものではなく、メモリの回収を平等に効率的に行うためのものです。 実のところ「緊急事態用のメモリ」は一般的に盛大に悪影響を及ぼします。 スワップを無効にすることは
補足(2010/08/24 15:00):rename関数について言えば、同一ファイルシステム上であればrenameシステムコールを利用するのでこの問題は起こりません。さらに蛇足ですが、ファイルシステムをまたがってrename関数を利用するとコピーしてから削除することになり、アトミック性を保証できないため、障害の原因にならないかどうかの検討が必要だと思います。 「AKIBA de: PHPのrename()関数はファイルシステム間で使うとメモリをバカ食いする」で指摘されている通り、PHPのcopy関数やファイルシステムをまたがってrename関数を使う場合に、PHPがファイルサイズと同じ大きさのメモリを消費してしまいます。環境によっては再現しないかもしれませんが、僕の手元のMacOSX 10.5+PHP5.3.3環境では再現しました。 <?php // 「dd if=/dev/urando
Kodama's home / tips. Linux ディスクキャッシュの開放 以下は Linux 2.6.16 以降. 2.6.15 以前では, /proc/sys/vm/bdflush で行う. 概要 一時的にキャッシュを開放したい場合 ディスク装置のバッファキャッシュ キャッシュのメモリー使用量の調整 キャッシュの書き込み間隔の調整 概要 ディスク装置の中のディスクの回転速度や読み書き速度と コンピュータのデータ転送速度には大きな差がある. この速度の違いを調整するために, 一時的なデータの置き場所として使われるものをバッファキャッシュと云う. ディスク装置に組み込まれたバッファキャッシュと, 主メモリーの空いた部分にとるバッファキャッシュの2段階があることに注意. 通常は気にする必要は無いが, 能力の測定でファイルの読み書きを行う場合などに影響する. Linux では, 主メモリ
上記 Dirty COW によると Linuxカーネルのメモリサブシステムがcopy-on-write(COW) 時に、プライベートなread-onlyメモリを破損する事が可能である問題らしい。 これにより、権限のないユーザが権限昇格によって、読み取り専用のメモリへ書き込みを行えるようになる( 特権取得が可能 ) 実際にこの脆弱性を利用する exploit が Phil Oester によって見つかっている Linux users urged to protect against 'Dirty COW' security flaw (HTTPのパケットキャプチャにより発見) Dirty COW の COW は copy-on-write (COW) から。 Dirty COW explained: Get a moooo-ve on and patch Linux root hole によ
選択肢 $fp = fopen('php://memory', 'r+b'); メモリ上に領域を確保する。メモリリークに注意。 $fp = fopen('php://temp', 'r+b'); メモリ上に領域を確保し、 2MB を超えたら自動削除される一時ファイルを作る。 $fp = fopen("php://temp/maxmemory:{$n}", 'r+b'); メモリ上に領域を確保し、$n バイトを超えたら自動削除される一時ファイルを作る。 $file = new SplTempFileObject($n); 上記の SplFileObject 版 (継承クラス) 。 引数は省略可能でデフォルトはもちろん 2MB (2 * 1024 * 1024 ) 。 0 にすることも可能。 OOP好きな人はこれでどうぞ。 $fp = tmpfile(); 自動削除される一時ファイルを作る。
今日は、Xfce4で利用できるファイルマネージャ thunar についてです。 (HALに関してでもあります) 復旧作業が終わったばかりのArchLinuxでいろいろと作業していたのですが、少し問題が。 thunarが起動している状態でUSBメモリなどを挿入すると、自動的にマウントしてくれる。。。 はずだったんですが、何やらエラーメッセージが表示されて、うまくマウントできませんでした。 あれ。。まだ設定が足りなかったかな。。と思いながら調べてみると、ArchLinuxのWikiで参考に なるページがありました。 参考ページ:http://wiki.archlinux.org/index.php/HAL 上記参考ページの「Another USB automounting fix」という部分がそうです。 実際に上記のWikiの内容にあるような修正を行ったわけではなく、「こっちでもいいんじゃない
はじめまして、Cerevoの中河です。 ソフトウェア担当で主にLinuxカーネル/ドライバ回りを担当しています。 今回はUBIFSとういうLinuxで使用できるファイルシステムについて書きたいと思います。 UBIFSって? UBIFSとはNANDフラッシュメモリ向けに開発されたファイルシステムです。 フラッシュメモリと言うと、一般的にはUSBメモリやSSDが連想されるかもしれませんが、それらのデバイスはハードディスクと同じような扱いが出きるようハードウェア的な仕組みが入っている為、ここでは該当しません。 UBIFSが対象としているのは、あくまでもCPUのNANDフラッシュメモリ・コントローラに直接接続されたNANDフラッシュメモリです。 何故UBIFS? フラッシュメモリ上では、JFFS2というファイルシステムが広く使用されてきました。 しかし、JFFS2にはフラッシュメモリの容量に比例し
Linux上のとあるファイルがページキャッシュに乗っているかどうかを調べたいなーと思ってGoogle先生にご相談したところ、こんなコマンドを教えてくれた。 ファイルをメモリにマップして、mincore(2)でページごとにRAMに存在するかどうかをチェックしているらしい。 mmapしても即メモリにロードされるわけではないのかぁ。 Cの部分だけ抜き出して、単体で動かしてみた。 #include <errno.h> /* errno */ #include <fcntl.h> /* fcntl, open */ #include <stdio.h> /* perror, fprintf, stderr, printf */ #include <stdlib.h> /* exit, calloc, free */ #include <string.h> /* strerror */ #includ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
oktです。 インフラ系とか社内システムとかいろいろ担当してます。 Linuxのカーネルは過去に読み込んだディスクの内容をメインメモリに保持する機能を持ってます。 重要な機能ですが、普段サーバ等を触っている分には意識しないことが多くハマったりします。 意識しないでプログラムの検証なんかしていると、キャッシュ有無で大きく結果が違ったりします。 ちなみにページキャッシュ自体についてはhatenaのnaoyaさんの記事を読むのをお勧めします。 そんなわけで、意図的にキャッシュを消したい場合には?という方のためにメモを残してみます。 linux kernel 2.6.16以降、以下の操作でページキャッシュを強制的にクリアすることができます。 ちなみに、RHEL4は2.6.9ベースのカーネルですが、RHEL4.6から実装されています。 # echo 1 > /proc/sys/vm/drop_cac
あるシステムで、shm_openとやったときに、なぜか失敗してエラーコードにENOSYSが帰ってくることがあって、 「まさか共有メモリがノーサポートなわけなかろう、、、」 ということで調査してみました。 すると、どうやらLinux(glibcのLinuxの実装)ではまず/dev/shmの存在を確認してから、もしそれが無い場合は、/proc/mountsを調べて、tmpfsかshmfsの存在を調べるみたいでした。 それもなければENOSYSと。。。。 glibcのソースをみてようやく判りました。 結局Tmpfsでマウントしたディレクトリ以下に、なんらかのファイルを作ってるだけという感じですね。 で、まぁあとはmmapとかしますわな。 ということで、適当なディレクトリを作って、tmpfsでmountしてやるとENOSYSも返さずにさくさく動きました。 というか、この動作よくよく考えて見ますと、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く