第2回 MySQL・PostgreSQLユーザグループ(MyNA・JPUG) 合同DB勉強会で使用したスライドと追加が含まれていますRead less
vboxsfを速くするために頑張る記事の3本目です。 前回は、vboxsfでpage cacheを使えるようにして高速化を実現しました。 今回は、VirtualBoxのファイルシステムvboxsfと、VM上で使われているファイルシステムext4との違いを調べていきます。 もちろんvboxsfとext4では、ファイルシステムより下の構造が全く違います。 またvboxsfの場合、NFSと同様に複数のクライアント(vboxsfの場合、ホストOSやその他のゲストOS)からアクセスされるため、ext4ほどキャッシュを多用できないかもしれません。 とはいえ、何かしらvboxsfを速くするヒントが見つかるのではないか?と思い調べてみました。 比較してみる とりあえず、vboxsfとext4でどの程度違いが出るのか調べてみました。使っているのは、前回の修正を取り込んだpage cache付きのvboxsf
IMPORTANT: DON’T TRY THIS IN PRODUCTION. As demonstrated by Marko (see comments), it may corrupt your data. In a post, written a few months ago, I found that using EXT4 transactions with the “data=journal” mount option, improves the write performance significantly, by 55%, without putting data at risk. Many people commented on the post mentioning they were not able to reproduce the results and thu
ファイルシステムを作成すると、ファイルシステム自体の管理領域などのため、ファイルシステムを作成するデバイス・ボリュームの容量を100%使えるようにはならない。 では何パーセントが減ってしまうのか。10%あれば大丈夫なのか、3%程度でもよいのか、厳密には決まらないのか、そんな疑問・不安を取り除くために検証および論理的な裏取りを行った。 検証環境は CentOS 6.4 (x86_64) で、ファイルシステムは ext4 である。なお、ブロックサイズは 4KB を前提にする。CentOS 7 (RHEL 7) でも考え方は同じだが、計算の元になる基礎値に差があるため注意が必要(「その他」にて触れる)。 検証結果 128M, 256M, 512M, 1024M, 1.5G, 2G, ・・・ と20GまでのLVを作成し、実際にファイルシステムを作成。マウントした際の df -k の Availab
ここでは、Linuxでハードディスクを利用するための手順を説明します。 Last Update : 2013年08月07日 ハードディスクを利用するための手順 Linuxでハードディスクを利用するためには以下の手順をふみます。 パーティションの作成(fdisk コマンド) ファイルシステムの作成(mkfs コマンド) マウント(mount コマンド) それぞれの言葉の意味から説明していきます。 パーティションとは パーティションとは、ハードディスク内で分割された個々の論理的な領域のことをいいます。 ハードディスクは、内部の領域を論理的に複数の領域(パーティション)に区切る事ができ、それぞれをひとつのハードディスクとして利用する事ができます。 パーティションを区切り、データ専用、システム専用のパーティションのように目的別にわけておけば、バックアップやシステムアップデートが楽であったり、データ
2014/08/04更新 対応バージョン: 14.04 ファイルシステムを作る場合、普通は物理的なHDDや論理ボリュームなどを用意するが、一般的なファイルをループバックデバイスを用いてマウントすることで簡単にファイルシステムを作ることができる。 この方法は一時的にファイルシステム固有の仕様を調べる時などに便利である。 ここではext4上のファイルをXFSに仕立ててみる。 パッケージインストール まずパッケージをインストールする。 % sudo apt-get install xfsprogs これでファイルシステムを作成する/sbin/mkfs.xfsをはじめ、/sbinと/usr/sbinに各種管理ツール(xfs*)がインストールされる。 XFSのバックアップ/リストア用のコマンド(xfsdump/xfsrestore)を使いたい場合はxfsdumpパッケージもインストールする。 空ファ
14. ネットワークのレイヤ感 レイヤ 問題になりそうなところ OSIレイヤ アプリ コネクション管理、タイマ 5∼7 NWスタック パケット分割・送信処理 4∼2 NICドライバ カーネル/NICとの相性 1∼2 NIC リンク方式、ファーム 1∼2 ケーブル等 物理的破損 0 スイッチ リンク速度、MAC重複 1∼2 ルータ ルーティング 3 FW アクセス制御 3∼4 WAN 網障害 0∼4 その先 それ俺ですか 10 16. ディスクアクセスのレイヤ感 レイヤ 問題になりそうなところ アプリ アプリ実装(CPU使用率のusrが高い) ファイルシステム FSの特性(RW速度はext4<<xfs) キャッシュ OSキャッシュの乗り方 IOスケジューラ カーネルスケジューラの特性 ドライバ バグ、相性 CNA/NIC/HBA ファームバグ/リンク速度 通信経路 物理破損、スイッチなど コ
以下の記事が面白かった。inodeが枯渇するとどうなるのかということなんだが。 http://d.hatena.ne.jp/elf/20111113/1321177077 Ext2/3/4はディスクをフォーマットした時点でinode最大数が固定されてしまう。 一方でbtrfsはinodeを動的に確保できるのでフォーマットした時点では固定されない。 ではどの程度の違いがでるのかが気になるところ。 上記の記事をもとに実験をしてみた。 実験のために10MBの空ファイルをext4/btrfsでフォーマットし、ループバックを利用してマウントする。これで10MBのディスクを仮想的に実現できる。 root@ochimina:~# dd if=/dev/zero of=$PWD/dummy.ext4 bs=1M count=10 10+0 records in 10+0 records out 10485
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
結論 ext4magic 最高!!!!111 やったこと % ext4magic “デバイス名に” -r -a “このunixtimeから” -b “このunixtimeまで存在していた” -f “このファイル名のファイルを復旧する” 実例 /dev/md0 上の昨日の20:00から20:30の間まで存在していた udonchan/backup.tar を復旧させたい % ext4magic /dev/md0 -r -a $(date -d "-1day 20:00 +%s") -b $(date -d “-1day 20:30 +%s) -f "udonchan/backup.tar" どうしてこうなった 年末なので OSX をクリーンインストールしようとして ~ をバックアップしたが間違って上書きして消した。 具体的に? ~ をサーバ上にバックアップするぜ % tar cf -C /U
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く