JVM Anatomy Quark #2: Transparent Huge Pages
"JVM Anatomy Quarks" is the on-going mini-post series, where every post is describing some elementary piece of knowledge about JVM. The name underlines the fact that the single post cannot be taken in isolation, and most pieces described here are going to readily interact with each other. The post should take about 5-10 minutes to read. As such, it goes deep for only a single topic, a single test,
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に起因する高負荷問題から、システムコールやカーネ
革命の日々！ transparent hugepage considered harmful
タイトルは釣りです。はい。 現状、ありとあらゆるDBがTHPをdisableするよう推奨している。これはあんまり良い状況じゃないのでTHPを disabled by default に変えようという提案。 Ted Ts'o はデフォルトがenabledだから、パフォーマンスが良くなるケースが気づきにくいだけだろうと主張。まあ、そうだろうね。KVM hostとかだと anon ばっかりつかうし、guest OSでメモリ制限あるから、hostのreclaimは走らないしで、悪いケースになりにくそう。 Vlastimil Babka はそもそも page faultの延長で、コンパクション始めちゃうのがよくないので、デフォルトは今より less aggressiveであるべきという意見のようだ。 Googlerが今のままがいいと主張していて、エンタープライズ屋さんが変えたいという陣営なのかな。
Cannot create JVM with -XX:+UseLargePages enabled
I have a Java service that currently runs with a 14GB heap. I am keen to try out the -XX:+UseLargePages option to see how this might affect the performance of the system. I have configured the OS as described by Oracle using appropriate shared memory and page values (these can also be calculated with an online tool). Once the OS is configured, I can see that it allocates the expected amount of mem
Riak, Elasticsearch and numad walk into a Red Hat
What starts like a joke is really a serious post about large distributed systems. This is what we run at meltwater - and while there is a lot of fun designing and administering these systems, we run into odd problems from time to time. In this case: some well-meant Red Hat memory optimisations interfering with Riak performance. There is a lot of talk around “Big Data” in the industry - and here at
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
Linux で huge page を使っているプロセスを調べる方法 - ablog
調べ方 /proc/[pid]/smaps で KernelPageSize がデフォルトの 4kB 以外のプロセスを探す。 調べ方の例 /proc/[pid]/smaps で KernelPageSize が 4 kB 以外のプロセスを探す。 [root@yazekats-linux ~]# perl -lane '/KernelPageSize/ and $F[1]!=4 and print qq/$ARGV\t$_/' /proc/*/smaps /proc/3834/smaps KernelPageSize: 2048 kB PID:3834 のプロセス名を調べる。 [root@yazekats-linux ~]# ps -fp 3834 UID PID PPID C STIME TTY TIME CMD root 3834 3832 0 13:44 pts/0 00:00:01
細かすぎて伝わらないmdbm
おまけ話として、mdbmはLinear Hashingと呼ばれるハッシュアルゴリズムの影響を強く受けています。 Linear Hashingの詳細はwikipediaをご覧ください。 http://en.wikipedia.org/wiki/Linear_hashing このアルゴリズムによりmdbmは、扱うデータサイズが大きくなれば、動的にHashTableを拡大することができる非常に便利な特性を持っています。 しかし、冷静になって考えてみてみましょう。このLinear Hasingの管理用のテーブルを走査する計算コストは可能なら避けるべきです。 mdbmをはじめ、多くのKVSでは最終的なデータのサイズの予想がつくのであれば、あらかじめ大きめのサイズでデータベースファイルを作成する方が好ましいでしょう。 この辺の話に興味がありましたら、コードの「hashval_to_pagenum()」
第6回JVMソースコードリーディングの会(OpenJDK6) - NAKAMURA Minoru's Diary
[Book] トーマス・ヘイガーの「大気を変える錬金術――ハーバー、ボッシュと化学の世紀」 トーマス・ヘイガー著「大気を変える錬金術――ハーバー、ボッシュと化学の世紀」を読了した。 この本は中西 準子先生の書評で知ったのだがこれは評判通り凄い本だった。 内容は空気からパンを作る技術、つまりフリッツ・ハーバーとカール・ボッシュが完成させた窒素固定法(ハーバー・ボッシュ法)に関する科学技術史の解説だ。 一応理系なのでハーバー・ボッシュ法は知っていけど、窒素固定法が発明される前の前史、ハーバーとボッシュが発明以降に辿る数奇な運命はほとんど知らなかった。 ヨーロッパは火薬の原材料や農業生産性を高めるための肥料として硝石を必要とする。 人間の尿を集めることである程度硝石を集めることが出来たが、それでは足りない。 自然の中にある硝石の鉱脈を求めて世界中が探索される。 やがてペルーのグアノ(海鳥の糞由来
Structured Data | Linux 6 Transparent Huge Pages and Hadoop Workloads
This past week I spent some time setting up and running various Hadoop workloads on my CDH cluster. After some Hadoop jobs had been running for several minutes, I noticed something quite alarming – the system CPU percentages where extremely high. Platform Details This cluster is comprised of 2s8c16t Xeon L5630 nodes with 96 GB of RAM running CentOS Linux 6.2 with java 1.6.0_30. The details of thos
2011年3月16日 “夢の高速パッチ”が取り込まれたLinuxカーネル2.6.38が登場 | gihyo.jp
Linus Torvalds氏は3月14日（米国時間）、Linuxカーネル2.6.38のリリースを発表した。最大の注目ポイントは、Linus氏も賞賛した約200行の"夢の高速パッチ"による大幅なパフォーマンス向上。その他、仮想ファイルシステム（VFS）のスケーラビリティ向上、btrfsのサポート強化、サイズの大きいページを透過的に扱えるTransparent Huge Pages（THP）など、パフォーマンス向上を中心とする多くの機能強化が図られている。 今回取り込まれた高速パッチはスケジューラに関するもの。同じセッションIDをもつ複数のプロセスを1つのスケジューリングエンティティとみなし、プロセスのグループ化を自動で行う。たとえばCPUリソースを必要とする6つのプロセスがあり、最初の4つが同じセッションIDをもつとする。プロセスグルーピングを自動化しない場合は、これまで通り、6つのプ
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
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
https://blogs.oracle.com/linux/post/entry/performance_issues_with_transparent_huge
ななめ45°から見たJavaOne
