read(2) vs mmap(2) の迷信
この記事は、シェルスクリプトの記事よりも前に読んだような気がする。同じくらい古い記事だけれど、ちょっと書いてみる。記事への反論はいくつか検索すると見つかって、たぶんみんな知っていることなのだと思うけれど、まとまって書かれている文章はないみたい。 tl;dr read(2) と mmap(2) の性能差に絶対的な回答はない。どちらか一方が常に高速だと主張している文章は、根拠が証拠とともに明確に書かれていない限り信用しないほうが良い。 メモリコピーのコストが高かった時代と、L1キャッシュが巨大になってメモリコピーのコストが低くなった時代と、SMPが一般的になってメモリのマッピング処理のコストが高くなった時代とで、この性能差は頻繁に入れ替わっている。少なくともスループットとレイテンシを分けないで分析できるものではない。 まず当該記事には技術的な間違いがいくつかある。 「mmap()はユーザランド
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
CPU Cache Essentials
This post came to my mind after watching the excellent presentation of Scott Meyers called "CPU Caches and Why You care". This post will try to summarize the ideas of the presentation so if you have some spare time you can just watch the presentation on video. To emphasize importance of cpu caches in our daily work we start with 2 examples: The first problem is a simple traversing of 2 dimensional
OSのメモリ管理と仮想記憶の歴史 - ablog
今や空気のような存在で普段意識することはないが、メモリ管理や仮想記憶はOSの主要機能だ。wikipedia:MVS や wikipedia:VMS のような名前の OS があるのもうなづける。OS、プロセッサ、メモリの歴史と深い関係がプロセッサを支える技術 ??果てしなくスピードを追求する世界 (WEB+DB PRESS plus)にわかりやすく書かれていたのでまとめてみた。 wikipedia:プログラム内蔵方式コンピュータ（1940年代） wikipedia:ENIAC(1946年)のような初期のコンピュータではプログラムはメモリに格納されておらず、スイッチや配線ボードの差し替えでプロクラミングが行われていた。別のプログラムに切り替えて実行するのに手間がかかるので、データと同様にメモリにプログラムを書き込んでおき、命令もメモリから読み出せるようにするプログラム内蔵方式コンピュータが考
InsightfulLogic
Caching In: Understand, Measure and Use your CPU Cache more effectively Slides from my Javaone talk on CPU Caching Wed 02 October 2013 I've put the slides online for Javaone talk on CPU Cache Optimisation. Here's the talk abstract: Modern computationally intensive tasks are rarely bottlenecked by the absolute performance of your processor cores. The real bottleneck in 2013 is getting data out of m
[Java, Linux] UseLargePages on Linux
Oracle Blogsの主としてテクノロジー製品のエントリを日本語でご紹介します（オリジナルのエントリを投稿することもあります）。厳密性をご所望の方は原文をどうぞ。よい内容でしたら原文に対し、"Good Entry, thanks!"でもいいので、是非コメントお願いします（Typoや誤訳はコメント欄からどうぞ）。なお、このエントリは個人の見解であり、所属する会社の公式見解ではありません。また、エントリ内でご紹介している製品・サービスは国内導入時期が未定の場合もありますのでご了承下さい。 Good entries on Oracle Blogs are put into Japanese. Mainly this blog covers technology products. Opinions expressed in this blog is my personal one and d
How to Configure x86 Memory Performance for Large Databases Using Linux Huge Pages
How to Configure x86 Memory Performance for Large Databases Using Linux HugePages Published December 2013 ,by Edward Whalen This article shows how to improve x86 memory performance for large databases by using Linux HugePages. About Memory Performance Performance tuning of large database systems can be a challenge. Depending on the operating system (OS) and hardware, there might be performance iss
細かすぎて伝わらないmdbm
おまけ話として、mdbmはLinear Hashingと呼ばれるハッシュアルゴリズムの影響を強く受けています。 Linear Hashingの詳細はwikipediaをご覧ください。 http://en.wikipedia.org/wiki/Linear_hashing このアルゴリズムによりmdbmは、扱うデータサイズが大きくなれば、動的にHashTableを拡大することができる非常に便利な特性を持っています。 しかし、冷静になって考えてみてみましょう。このLinear Hasingの管理用のテーブルを走査する計算コストは可能なら避けるべきです。 mdbmをはじめ、多くのKVSでは最終的なデータのサイズの予想がつくのであれば、あらかじめ大きめのサイズでデータベースファイルを作成する方が好ましいでしょう。 この辺の話に興味がありましたら、コードの「hashval_to_pagenum()」
Webサーバのマルチスレッドでの実装における優位性をLinux Kernel 3.3のソースから読み解く
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 表題の通り、現行のカーネルの実装において、マルチスレッドとマルチプロセスでの実装の優位性はどういう所にあるのかを知りたい、というのが今回の調査の意図だ。 そのために、前提知識としてマルチスレッドとマルチプロセスの特徴について、カーネルのソースを見ていきたいと思う。カーネルの海に飛び込むには、やはり最新のLinux Kernel 3.3のソースを選択することにした。前置きの段階で少し長くなってしまいそうだ。ではカーネルの海に飛び込みたいと思う。 とはいっても、まずは最初の一歩が必要なので、当たりをつけようと思う。キーワードは、 マルチスレッド マルチプロセス コンテキストスイッチ メモリ空間の共有 TLB（トランスレーション・ルックアサイド・バ
Transparent Huge Page - 研究日誌。
Transparent Huge Page という hugepage が Linux 2.6.37 から使用することができます。 とはいっても、Transparent Huge Page は default で always 設定(すべて hugepage 上に確保)になっているので、CentOS6, Fedora15 あたりの OS を使用している場合、知らず知らずのうちにその恩恵を授かっていると思われます。 本来 Linux は 4KB のページと呼ばれる block でメモリを扱うことになっていますが、この場合 virtual address から 4 段階の変換テーブルを参照して目的の物理メモリにアクセスすることができます。この 4KB ごとの TLB miss を軽減するには、大きなサイズのページ hugepage を採用することが有効です。2MB の hugepage を採用す
Java Support for Large Memory Pages
Beginning with Java SE 5.0 there is a cross-platform flag for requesting large memory pages: -XX:+UseLargePages (on by default for Solaris, off by default for Windows and Linux). The goal of large page support is to optimize processor Translation-Lookaside Buffers. A Translation-Lookaside Buffer (TLB) is a page translation cache that holds the most-recently used virtual-to-physical address transla
The Calibrator (v0.9e), a Cache-Memory and TLB Calibration Tool
The Calibrator (v0.9e), a Cache-Memory and TLB Calibration Tool Introduction The Source Code and how to compile it Binary Executables How to use The Calibrator Sample Output The Calibrated Hardware Database Request for Contributions and Feedback 1. Introduction The Calibrator is a small C program that is supposed to analyze a computers (cache-) memory system and extract the following parameters: n
仮想メモリーを支えるもうひとつのキャッシュ TLB (1/3)
仮想アドレスと物理アドレスを変換する Address Translationの基本 前回はメモリーの階層構造と同様に、複数段階のキャッシュ構成があることを説明した。今回はちょっと見方を変えた話をしたい。まず、キャッシュという形でCPU内部に搭載されている、別のメモリーについて触れよう。 ご存知の通り、1次キャッシュは通常「ハーバード・アーキテクチャー」と呼ばれる構造に基づき、命令用とデータ用がそれぞれ別に用意される。詳細は後述するが、2次キャッシュや最近では3次キャッシュを搭載するプロセッサーも多くなった。ただ、これらはいずれも「プログラムそのもの、およびプログラムの実行時に利用されるデータ」である。 「ではそれ以外に何かあるのか？」と言われると、これが結構ある。一番多く利用されるのが「TLB」(Translation Lookaside Buffer)と言われるものだ。これは「仮想記憶」
CPU Cache Flushing Fallacy
Even from highly experienced technologists I often hear talk about how certain operations cause a CPU cache to "flush". This seems to be illustrating a very common fallacy about how CPU caches work, and how the cache sub-system interacts with the execution cores. In this article I will attempt to explain the function CPU caches fulfil, and how the cores, which execute our programs of instruction
MIPSのアドレス変換周り(TLB)の処理をまとめてみた - Boost Your Programming!
1年ほど前にTLB(Translation Look-aside Buffer)を使ったアドレス変換処理を実装したのだけど、もう一回実装しようと思ったらあまり覚えてなかったのでまとめておくことにしました。 See MIPS Runを参考にしました。間違っているところがあればご連絡ください。 アドレス変換とは 通常プログラムで扱うアドレスは仮想アドレス(Virtual Address)と呼ばれ、(32bitマシンでは)32bitのアドレスを自由に使えます。しかし、実際のデータは物理メモリ上のどこかに格納されています。物理メモリ上の位置を示すものが物理アドレス(Phisical Address)と呼ばれます。 データにアクセスするためには仮想アドレスから物理アドレスに変換する必要があり、この処理をアドレス変換と呼びます。 単純な実装では、仮想アドレス = 物理アドレスとすることも可能です。しか
JVM Performance Tuning
Last week was JBoss World, and it was exciting to be a part of it. I gave a presentation on performance tuning our Enterprise Application Platform or EAP, and it was packed. In fact, people were sitting on the floor in pretty much all available space. What struck me about the presentation, and much of the discussion I had with individuals afterwards, is that JVM tuning is a big topic. So, I though
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.cs.rochester.edu/~sandhya/csc256/seminars/sharanyan_superpages.pdf
Intel Xeonにおけるメモリレイテンシの測定についての表示 - memory profiling tool - OSDN
Command to measure TLB misses on LINUX?
Java, MySql increased performance with Huge Pages