Detecting Memory Leaks in Kernel & Managed code OSesThis blog post has two sections. Firstly, a section covering " Memory Leak detection in the Linux kernel in 10 easy steps " and the next sec...
Kazuho@Cybozu Labs: ウェブサービスにおける SSD 導入にむけて〜検索サービスの可能性
« Filter::SQL でデータベースを叩くワンライナーを簡単に書く方法 | メイン | ウェブサービスにおけるダメージコントロール (MySQL のスロークエリを自動的に kill する方法) » 2008年10月28日 ウェブサービスにおける SSD 導入にむけて〜検索サービスの可能性 実際に試してみた結果については、ウェブサービスの SSD 化について話してきましたをご参照ください。 検索エンジンや小さな行が多いデータベース等で使用する目的での SSD (Intel X25-M) のベンチマーク結果については、Kazuho at Work: Benchmarking SSD for MySQL をご覧ください (InnoDB の話をしていますが、Senna / Tritonn でも基本的に同じ) Sun が SSD 製品の投入を表明 (マイコミジャーナル) したり、Google
proc/meminfoの差分 (Rev.3,最新版) - Linuxカーネルメモ
MemTotal: 1001008 kB MemFree: 200708 kB Buffers: 43400 kB Cached: 395740 kB SwapCached: 0 kB Active: 557556 kB Inactive: 178624 kB HighTotal: 97216 kB HighFree: 140 kB LowTotal: 903792 kB LowFree: 200568 kB SwapTotal: 2096472 kB SwapFree: 2096472 kB Dirty: 224 kB Writeback: 0 kB Mapped: 356492 kB Slab: 47820 kB CommitLimit: 2596976 kB Committed_AS: 689048 kB PageTables: 6192 kB VmallocTotal: 11468
Stray Penguin - Linux Memo (PostgreSQL-5)
このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 数十万レコードのデータを持つ大規模なテーブルを扱うようになると、クエリによっては回答が得られるまでに数秒かかるケースも出てくる。これは、より多くのメモリやディスクの使用を PostgreSQL に許すことで改善される可能性が高い。ただし、扱っているデータベースが小さい時には大した効果は望めない。また、そもそもの実装メモリが 256M とか 128M という貧弱な状態では、調整の余地さえなく、単なる悪あがきだ。以下は搭載メモリ 1 ギガを目安に書いている。更に、テーブルの素性とクエリパターンによっては、テーブル自体のクラスタ化が加速を上乗せしてくれるかもしれない -- クラスタリングや適切なインデックスの作成は、メ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
