OpenShiftやKubernetes上でJavaを動かす際の注意 - nekop's blog
OpenShift 全部俺 Advent Calendar 2017 OpenShiftやKubernetes上でリソース制限を設定したコンテナでJavaを動かすとき、デフォルト設定のままだとパフォーマンスが悪くなったり、oom-killerに殺されたりします。これはコンテナのcgroupsの制限をJavaが考慮しないためです。 Javaはデフォルトでホストのメモリの1/4を最大Javaヒープメモリに設定し、Java VM本体、スタック、Metaspaceなどの非Javaヒープ領域を含めると最終的にその倍程度のメモリを利用します。たとえば16GBのマシンだと8GBくらいです。これを4GBなどの制限で動作させるとメモリが確保できずエラー終了もしくはoom-killerに殺されます。また、GCThreadsなども効率を最大化するためにCPUコア数とスレッド数を同一に設定します(厳密には8コア超
Kubernetes/OpenShiftのバージョンアップとクラスタをどのように分けるか問題 - nekop's blog
Kubernetes/OpenShiftのバージョンアップをどのようにするか、およびクラスタをどのように分けるかという問題はk8s関連のmeetupでよく出る話題です。昨日のレッドハット on Cloud Dayでも出たので、現時点での自分が知っている情報や考えを書いておきます。 現時点で自分が一番しっくりくるそれなりな規模の構成はdev, testing, staging, prodの4種類を2クラスタずつ用意、8クラスタの構成です。規模によってはtesting, stagingは一つにしてしまってもいいと思います。 各ステージのクラスタ、たとえばprod1, prod2はBlue-green deploymentのような形で利用します。たとえばprod1はk8s 1.7, prod2は一つ新しいk8s 1.8となっていて、新規のデプロイは全てバージョンの新しいほうであるprod2に行い
テクニカルサポートというお仕事 - nekop's blog
tstalk Vol.1というテクニカルサポートのトークイベントに行ってきていろいろお話したり聞いたり考える機会になったので書き出しておくよ。いろいろなテクニカルサポートな人が集まっておもしろかった。ソフトウェア製品サポート、ハードウェア製品やそのファームのサポート、非サポート(興味がある、昔やっていた、サポートを利用するお客様の立場だけど、というような方々)、その他、みたいなごちゃまぜ編成。 ランダム箇条書きな感じで。 テクニカルサポートは楽しい テクニカルサポートはケーキバイキングみたいなお仕事 基本的に扱う内容はエンジニアであるお客様がつまずいた「技術的に難しいところだけ」おいしいとこどり食べ放題 「サポート」を「エンジニアリング」する、多くの改善余地のある創造的な作業が多め 例えばプログラマ関連だと、WebとDBとの橋渡しをするだけのコード書きや(デザインなどの創造的な作業ではない
JBoss AS7 おたより紹介 - nekop's blog
JBoss AS7のリリース、Twitterでいろんな反応があったので簡単に紹介してお返事とかするよ！ 起動が10秒くらいであんまり速くない！ 初回の起動ではないでしょうか。というのも、JavaやJBoss ASを構成するファイルがOS側のディスクキャッシュに存在していない場合、単にそれらを読み込むときの「ディスクの遅さ」という話になってしまい、JBoss ASが遅い、という話ではなくなってしまいます。2回目以降の起動の速度を見てください。 あとありがちなのとしてupdatedbとかウィルススキャンが走っていて実は何やっても遅かった、というような可能性があります。 TomcatやJettyより起動がだいぶ遅い！Glassfishとあまり変わらない！ TomcatやJettyは機能セットが違いすぎるのでさすがにフェアな比較ではありません。TomcatからServlet/JSPコンテナを削除し
JBoss AS 7.0.0.Final コードネーム "Lightning" リリース - nekop's blog
JBoss Application Server 7はJBoss AS 6をベースにせず、ノウハウだけを流用しコードはスクラッチから書きなおした新しいJBoss ASのリリースです。書きなおしているので良いところは残しつつ、今までのJBoss ASとは大幅に異なるリリースとなっています。 バージョン7ということでJBoss AS 7を選ぶ上位7つの理由を挙げてみます。 超高速 - 10倍以上の起動速度、世界最速のJava EE 6アプリケーションサーバ Java EE 6 - CDIによるカスタマイズ容易なプログラミングモデル 超軽量 - 16Mのメモリ指定でも起動 モジュール化 - アプリケーション空間の独立とクラスローダ地獄からの開放 管理容易性 - 新しい管理API、管理コマンドラインインタフェースとグラフィカルインタフェース ドメイン管理 - 複数のサーバをまとめて管理 テスト容易
TomcatではなくJBossを選ぶ○○の理由 - nekop's blog
java-ja忘年会でharu860さんに聞かれたのでエントリを書くよ。と思ってざっくり書いて放置していましたすみません。この質問へのよくある回答として「EJBを使うとき」みたいなものがありますが、この回答は多くの場合何の役にも立ちませんね。このような回答をする人はJBossをあまり良く理解していない可能性があります。 というわけで、JBossを使っているユーザがどのようなモチベーションでTomcatではなくJBossを使うのか、もしくは完全にJBossに乗り換えているのか、実例ベースの理由をいくつか紹介しましょう。 機能 Tomcatで提供される機能は基本的にServlet, JSP, JDBC接続プールのみで、他のものは提供されていません。シンプルですが、他のものが必要になったときに、それらをインテグレーションするコストが発生するなど、少し面倒なことになります。 TomcatになくてJ
BytemanによるJava黒魔術 - nekop's blog
クリスマスも近いですね。さて、クリスマスといえばどういうわけか黒魔術への需要が一気に高まる時期のようですので、Java Advent Calendar -ja 2010の12月20日はJavaの黒魔術をお送りします。昨日はid:celitanでした。 今日紹介する黒魔術はバイトコードインジェクションツールであるBytemanです。 この前ですね、お仕事で「HTTPレスポンスのヘッダが勝手に想定外のものに書き換わる」という不思議現象の相談を受けたんですね。Servletの中ではsetHeader("Foo", "bar")ってしてるのに、実際のレスポンスは"Foo: hoge"とか返ってる。アプリのJavaソース調べてもそんなことしてなさそうだし、Tomcatのソース見てもsetHeader()呼び出しでは何のログも出さないっぽいのでログを有効にしても原因がわからなさそう。なんだこれはとか思
OutOfMemoryErrorが発生したときにきちんとJavaプロセスを殺す - nekop's blog
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
