Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか？また、元々Permanent領域に格納されていた情報は何処にいってしまったのか？JVM付属のツールにどういった影響があるのか？ 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番（「補足 – HotSpotVMのメモリ構造概説）を読んでいただくとスムーズに読み進められるだ
非同期ストリーム処理の標準化を目指す "Reactive Streams" とは - Okapies' Archive
TL でこんなのが流れてたので少し調べてみた。 Learn about the Reactive Streams initiative & how we're supporting a standard for asynch stream processing on the JVM http://t.co/5wUF0PjTBe— Twitter Engineering (@TwitterEng) 2014, 4月 17 Reactive Streams って？ Reactive Streams ”JVM 上でのノンブロッキングなバックプレッシャーを持つ非同期ストリーム処理の標準の提案”（公式サイトより）。 ざっくり言うと、既にある JVM ベースの様々な非同期ストリーム処理フレームワーク実装の共通部分を括りだして API 化、SPI 化しようというもの。最終的には JSR での標準化を目指
「JVM Operation Casual Talks」発表資料のリンクをまとめてみる #jvmcasual - 元RX-7乗りの適当な日々
4/7に、LINEさんのオフィスで開催された「JVM Operation Casual Talks」。 一部で、Cassandra Casualだったのではないかという疑惑もありましたが、なかなかためになる話が多くて、あとできっと資料を見たくなる日が来そうなので、ちょっとまとめておこうと思う。 こちらもあわせて読みたい JVM Operation Casual Talks #jvmcasual - Togetter Understanding Memory Management of JavaVM in 15 minutes (@stanakaさん) https://speakerdeck.com/stanaka/understanding-memory-management-of-javavm-in-15-minutes @stanakaさん、どこでJVM使ってるのかと思ったら、今日は
なにもわからないところから始めるJVMモニタリング #jvmcasual - ゆううきブログ
JVM Operation Casual Talks で発表してきた。 なんでJVMでしゃべってたのか本当によくわからない。 JVM Operation Casual Talks : ATND とにかく雑な発表したという記憶しかない。 NewRelic のトップページにでかでかとおっさんでてきて印象悪いとかそういうの。 JVM とかどうでもよくて mackerel: 新しいアプリケーションパフォーマンスマネジメント にしか興味がなかった。 Java Performance (Java Series) 作者: Charlie Hunt,Binu John出版社/メーカー: Addison-Wesley Professional発売日: 2011/10/04メディア: Kindle版この商品を含むブログを見る Java Performance: The Definitive Guide 作者:
トラブルに備えるJVMオプション - n-agetsumaの日記
以前の記事でトラブルが起きた後の初動対応を書いてみたが、いざトラブルに遭遇すると、まず再起動してからどうするか考えるケースが多いと感じている。しかし何も情報がないと『情報がない/再現方法が不明』などの理由からそのままお蔵入りになってしまう。今回はトラブルに事前に備えるために、地味だけど大切なJavaVMのオプションをまとめてみる。 GCログの出力とローテーション OutOfMemoryError発生時のヒープダンプ自動出力と出力パス設定 JavaVMクラッシュログの出力パス設定 JVMオプションの設定 (OpenJDK/OracleJDK) JavaVMにはGCおよびヒープメモリの状態をロギングする仕組みや、OufOfMemoryError時にヒープダンプを自動的に出力するような障害に備えて自動的に情報を出力する機能がある。おすすめのオプション*1は以下の通り。 java -Xms?g -
Java 7 CMS GCの基本的な情報の整理 - nekop's blog
バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve
Javaトラブルに応じた初動対応のまとめ - n-agetsumaの日記
Javaトラブルでは『情報がなくて、再現もなかなかしません』といった状況に陥ることがある。このような状況を回避するために、以下の3つの代表的なトラブルを例に、アプリケーションサーバを再起動する前に何を取得すれば良いのかをまとめてみる。 アプリケーションから応答がない アプリケーションが遅い ヒープメモリが足りない(OutOfMemoryErrorの発生) アプリケーションから応答がない 取得する情報 スレッドダンプ データ取得方法 スレッドダンプとは、コマンド実行時点でのJavaスレッド実行状態を出力したものである。応答がない場合、何らかの要因によりどこかで処理が止まっていることが想定される。スレッドダンプは『どこで止まっているのか？』を切り分けるのに大切な情報である。 取得方法はJDKのバージョンによって色々ある。 kill -3 <pid> (少なくとも1.4.2にはある〜JDK7でも
Elasticsearchソースコードリーディング～内部構造把握の第一歩～ - Taste of Tech Topics
こんにちは！ ツカノ(@snuffkin)です。 ElasticsearchとKibanaを使うとログなどを簡単に可視化できるため、利用者が急速に増えてきています(私もそのひとりです)。様々なブログで紹介されているKibana画面はとても素敵で、積極的に使いたくなります。 ただ、それなりの規模でElasticsearchを利用するには、中身を知ったり、データ設計や運用面なども考える必要がありますが、そのあたりの情報はまだ十分ではないように思います。そこで、Elasticsearchの中身をもっと知るために、ひとりでひっそりソースコードリーディングをしてみました。 今回利用したElasticsearchのバージョンは1.0.0.RC2です。以下の場所から実行媒体とソースコードをダウンロードして確認しています。また、確認はWindowsで行っています。 実行媒体 http://www.elas
JMXのメトリクスをfluentd経由で蓄積する | nagaseyasuhito Daily works.
みなさんJMXは使っていますか？Javaアプリケーションのメモリ使用量を始めとした統計情報を取得したりできる、運用には欠かせないモニタリング・管理の仕組みですが、統計情報を蓄積する方法に悩んでいる方も多いのではないでしょうか。 今回はアプリケーションから取得できる様々な統計情報をfluentd経由で蓄積し、分析やトラブルシュートに活用する方法を紹介します。 JMX用のfluentdプラグイン JMXの統計情報をfluentdで収集するfluent-plugin-jolokiaというプラグインを使います。 fluent-plugin-jmxではなくfluent-plugin-jolokia？と思われるかもしれません。 JolokiaはJMXをJSONベースのREST APIとして提供するためのエージェントです。fluentdのプラグインはRubyで書かれていますが、Rubyから直接JMXのプ
Sprayの簡単な紹介 - アドファイブ日記（ミラー版）
Scala Advent Calendar 2013の10日目担当記事です。みんなガチな人ばかりで怖いです。あまり期待しないでください。 ググっても日本の記事があまりないSprayの紹介をしてみます。 あと表題と関係ないですが最近書いたPlayFrameworkにSlickやSecureSocialを入れたメモを掲載しておきます。 Play2.2へのSlickのインストール Play2の認証ライブラリSecuaSocialを使う Sprayについて Akkaをベースに非同期モデルで実装された超ハイパフォーマンスなHTTP処理フレームワークという感じのもの。型システムがあって非同期でマルチスレッド（アクター）対応しててプラグインがある程度揃ってるHTTPサーバやWebフレームワークってScalaにしばらなくても少なそうです。ハイフリークエンシ―なWebアプリケーションやREST-APIを作る
Eclipse Ceylon: Team blog
The Eclipse Ceylon™ project encompasses development of the language itself (the language specification), the compiler frontend (typechecker), the compiler backends for Java and JavaScript, the module system, the command-line tooling, the SDK, and the Eclipse-based IDE. A future direction is tooling for Eclipse Che. The project also maintains the website and documentation for the language. Eclipse
Twitter: 大きなトラフィックに耐えうるアーキテクチャーへの変更 - ワザノバ | wazanova.jp
https://blog.twitter.com/2013/new-tweets-per-second-record-and-how 少し前、8月のTwitterエンジニアブログのエントリーですが、アーキテクチャー変更について触れているポストなので、取り上げてみます。 1) 背景 2010年のワールドカップ時点でのトラフィックがさばききれなかった時点での状況は、 200人のエンジニアが、単一のRailsのコードベースで大量のユーザとトラフィックに対応する構造であった。 MySQLのストレージシステムは、一つのマスタと一時的にシャーディングされるスレーブの構成で、読込み/書込みともにスループットの限界にきている箇所がでていた。 フロントエンドのRubyマシンは期待通りのトラフィックをさばけていなかったが、技術的な解決ではなく、サーバの追加でしのいでいた。 コードベースは、可読性とパフォーマン
完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか？ まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
はじめの言語の賞味期限 - Kato Kazuyoshi
ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 Twitter と Ruby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、Twitter の Ruby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JVM! JVM! JVM!
Javaトラブルに備えよう #jjug_ccc #ccc_h2
IntelliJ IDEA 13のJVM設定 - terurouメモ
10歳になったScala
Heliosearch/Solrオフヒープフィルタ | 関口宏司のLuceneブログ
Scala稟議の通し方（公開版）
