世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
こんにちは。斎藤です。 最近、新しいスキー板が欲しいなと思っています。現在使っているOGASAKAの板は5年目に入り、メーカーからこれ以上はチューンナップ(メンテナンス)はできないよ、と言われてしまいました。もし、次に買うなら、スノーボーダーの人と一緒にパウダーに飛び込みやすいセミファットタイプが良いのかなと考えています。皆さんのオススメ、ぜひ教えてください。 さて、今日はLinux Kernel上でのメモリ管理、特にページ回収(Page Reclaim)とスワップに絞り、「スワップの理由」「ページを回収する仕組み」そして「スワップの様子を観察する」の3点に分けてお話しします。「スワップするのが気持ち悪い」と考えている方は少なくないと思いますし、私もそう考えていた時期がありました。しかし、それは本当に悪い事なのか、今回掘り下げて行きます。 ※主な対象Kernelは2.6.32(Red Ha
監訳者まえがき はじめに 1章 概要 1.1 LinuxとほかのUNIX系カーネル 1.2 ハードウェア依存 1.3 Linuxのバージョン 1.4 オペレーティングシステムの基本概念 1.4.1 マルチユーザシステム 1.4.2 ユーザとグループ 1.4.3 プロセス 1.4.4 カーネルアーキテクチャ 1.5 UNIXファイルシステムの概要 1.5.1 ファイル 1.5.2 ハードリンクとソフトリンク 1.5.3 ファイルの種類 1.5.4 ファイルディスクリプタとiノード 1.5.5 アクセス権とファイルのモード 1.5.6 ファイルを取り扱うシステムコール 1.6 UNIXカーネルの概要 1.6.1 プロセス/カーネルモデル 1.6.2 プロセスの実装 1.6.3 再入可能なカーネル 1.6.4 プロセスアドレス空間 1.6.5 同期とクリティカル区間 1.6.6 シグナルとプロセ
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
LIKE 検索等では通常のインデックス(btree)が使えない*1 …ということを意識していなかったので、 jcomi_db=# SET ENABLE_SEQSCAN=OFF; jcomi_db=# EXPLAIN ANALYZE SELECT COUNT(*) FROM t_book_info WHERE book_title LIKE '%ラブひな%'; QUERY PLAN -------------------------------------------------------------------------------------------------------------- Aggregate (cost=87.40..87.41 rows=1 width=0) (actual time=2.352..2.354 rows=1 loops=1) -> Seq Sca
くだらないことばかり書いているので、自分の知識の整理もかねて真面目なことをかいてみようと思う。 PostgreSQLは、セットアップ時のデフォルトの設定は、最近の高性能なハードウエアに合わせた設定になっていないのでハードウエアの性能に合わせて適切な値にしないとハードウエアの性能を引き出すことができない。 [max_connections] PostgreSQLがどれだけコネクションを待ち受けるかを指定するパラメーター、基本的にフロントエンドのWebサーバーの接続数と同じ数だけ用意する必要がある。 数値を増やすとOSのShared MemoryとPostgreSQLのWork_memの消費量が増えるので必要以上に大きくしない方が良い。 また1000コネクション同時接続とか大量のコネクションをさばく必要があるのならpgpoolを使用してコネクションプールをすることを考慮に入れる。 また、コネク
https://www.youtube.com/watch?v=7KS4L-mA_-c 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Takipi のFounderであるTalWeissのSan Francisco Java User Groupミートアップでの講演。本番環境で役に立つデバッグテクニックの紹介です。 1. スレッド名の活用 スレッド名はmutable（EJB除く）である。コードのコンテキストにあわせて、Thread.currentThread().setName(Context, TID, Params, Time,...);のようにすれば、トランザクションID、Serveletパラメータ、キューメッセージID、起動時間など、スタックトレースに役に立つ情報を表示できるようになる。 J
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く