Linuxでは空いているMemoryは積極的にファイル用のCacheに使用する MemoryはPageという単位で分割して管理されており、Cacheに使用されているMemoryをPage Cacheと呼ぶ Memoryのチューニングのポイントは無駄なPage Cacheを残さないこと Page Cacheにデータを書き込んだ時点でProcessからの書き込み処理は終了するが、実際のデータの書き込みはHDDに後に書き込まれる(Writeback処理) LinuxにおけるWriteback処理は、"pdflush"というデーモンが担当する "pdflash"デーモンのパラメータ パラメータ 内容 vm.dirty_backgroudo_ratio Processの書き込み処理は終了したがまだWritebackされていないPageの、全物理Pageに対する割合(%)が"vm.darty_back
前回は、一般的なLinuxファイルシステムをいくつか紹介し、それぞれの機能を見ていった。Linuxをすでにインストールしてあれば、パーティションの設定とファイルシステムの構成は済んでいるはずだが、この構成を変更したい場合もあるだろう。最適な方法を探ってみよう。 本稿は、先日刊行された書籍『Linux Power Tools』からの抜粋である。 変更と一口に言っても、中には手間のかかるものもある。たとえば、ファイルシステムを変更するには、バックアップ、新規ファイルシステムの作成、ファイルのリストアという手順が必要になる。ただし、ext2fsからext3fsへの変更だけは例外で、非常に簡単に行うことができる。ファイルシステムを切り替えたら、ファイルシステム作成のさまざまなオプションを利用して、新しいファイルシステムのパフォーマンスを向上させることができる。その他の変更は、比較的簡単だ。ディスク
Optimizing the EXT3 file system on CentOS Ext3 is a very capable file system with excellent fault tolerance and a long track record of stability. While it performs well, it's by no means the fastest file system out there. There are some things you can do to give ext3 a boost when you just want speed. Some of the methods listed here will reduce the information kept about your file system as a trade
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
明けましておめでとうございます。今年もコンピューター道に邁進して参りますのでよろしくお願いします! さて、今年一発目のネタはMySQL利用時におけるZFSのチューニングについて取り上げようと思う。Solarisに搭載されている機能の中でも最も注目度の高いものの一つであるZFSであるが、MySQLのバックエンドとしてはあまり利用されていないように思う。(そもそもSolarisのユーザー数自体がそれほど多くないという話もあるが。)ZFSは優れたファイルシステムであり、ファイルシステム自体にスナップショット機能が搭載されていたり容量の限界に先が見えない(充分すぎるほど余裕がある)といった管理上のメリットがあり、DBAにとっては垂涎のファイルシステムであると言える。(Linuxで利用出来ないのが難点だが、ZFSを使うためにSolarisを使うのもアリだろう。) MySQL利用時におけるZFSのチュ
Presentation Title Fumiaki Tokuyama (tokuhy) Fumiaki Tokuyama (tokuhy) COMSTARでiSCSI OpenSolaris勉強会 for Admin (仮) 2010.04
S3 Support in Apache Hadoop Apache Hadoop ships with a connector to S3 called "S3A", with the url prefix "s3a:"; its previous connectors "s3", and "s3n" are deprecated and/or deleted from recent Hadoop versions. Consult the Latest Hadoop documentation for the specifics on using any the S3A connector. For Hadoop 2.x releases, the latest troubleshooting documentation. For Hadoop 3.x releases, the la
2024.03.01 記憶 By KeI 2024.02.28 3500円の海鮮丼 By kogt 2024.02.26 白い妖怪ぱーく展を見てきた話 By 毛焼坂 2024.02.21 ピンチⅡ By 勇者ああああ 2024.02.19 最近、導入したサブスクの話 By キタサン 2024.02.16 ゴールデンカムイは最高って話 By sawara 2024.02.15 2月14日は何の日?シリーズ第3弾! By Moon 2024.02.09 たまには身体を動かそう By hik 2024.02.07 展覧会 By ra-men 2024.02.05 老舗韓国冷麺のすゝめ By よねたみ 2024.02.02 38歳に「僕が大人になる」と言われた話 By 弦 2024.01.31 少年少女へのネット普及ってすごいし怖い By むったん 2024.01.29 会社より10倍快適なNW環
HOME > PC > SSD vs. HDD > Linux ubuntu SSD や ANS-9010 と Linux ubuntu SSDでは読み書きが交錯すると書込遅延が発生し、プチフリが発生する。これをさける方法としてRAIDの構築があるが、SONYのVAIOは基盤2枚でSSDのRAIDを組めますが、それ以外のノートパソコンでは、一般にRAIDを組みにくい。このような環境で、読み書きの交錯を避けるためには、WindowsからLinuxにOSを入れ替えてしまうのもいいと思います。 Linuxのext2やext3などのファイルシステムはNTFSやFATとは別の哲学で設計(訳)されており、本来はマルチユーザーを想定して複数のユーザーが同時に複数のファイルにアクセスする事を前提に作られているので、Windowsの様に同じ場所に書き込みを繰り返すのではなくパーティションの空いている部分に一
LinuxカーネルはRAID-1の実行をソフトウェアでサポートしている。RAID-1では、1つのファイルシステムを2台以上のディスク装置で保持するため、障害が発生しても最後のディスクさえ生き残っていればすべてのデータを復旧できる。すばらしい仕組みだが、メモリや電源ユニットなど、ほかのハードウェアコンポーネントが故障した場合にはやはり貴重なデータが失われる可能性がある。だが Chiron FS を使えば、ネットワーク上の2台のマシンが持つディスクで1つのRAID-1を構成でき、一方のマシンがダウンしてもファイルシステムにアクセスし続けることができる。 RAID-1構成が維持された状態で一方のマシンに障害が発生した場合でも、ネットワーク接続が無事であれば、障害で破損したファイルがChiron FSによって他方のマシンに複製(レプリケーション)されるおそれがある。だが、2台のローコストPCとネッ
ファイル名の長さの制限 概要 NTFS(Windows) : 255文字(UTF-16) ext3(及びUNIXのファイルシステム一般) : 255バイト NTFSとHFS+ではファイル名にUTF-16を使用することが仕様で規定されているが、 Unix系のファイルシステムではファイル名の文字コードの規定はなく、NULL(0x00)と"/"(0x2f)を含まない任意のバイト列が使用できるようになっている。 ASCII文字だけ使うなら上記のどのファイルシステムでも同等だけど、マルチバイト文字を使うとext3の方が使える文字が少なくなる。 今のLinuxは文字コードにUTF-8を採用しているので、日本語は1文字3バイトとなり、255/3=85文字でファイル名のリミットとなる。 ext系 Filesystems HOWTOにてext2でも必要なら1012バイトまで拡張可能という記述があるが、その方
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く