サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
chonaso.hatenablog.com
諸般の都合でどうしてもメモリが潤沢ではない環境でのテストを行わなければならない場合があるかと思います。 また、Java7もすでにEOLということでJava8の開発も多くなっているかと思いますが、Java8になって初めて遭遇した問題がありました。 そんなわけでJava8で開発を始めた頃のお話です。 TomcatアプリがJava7以前では重いながらも動いていたのに、Java8ではスワップの重力を乗り越えたと思ったら急にアプリが応答しなくなってしまい、よく見たらTomcat(java)プロセスがいません。 アプリケーションやTomcatのログを見てもOutOfMemoryErrorが出ているわけでもなく、仕方なくTomcatを起動しなおしてテスト再開するとまたプロセスがふっと消えている…。 そんな怪談話みたいなことがあるかと思いながら/var/log/messagesを見ると Sep 17 01
というわけで行ってきました。 個人的には技術云々のセッションにはほとんど参加せずいわゆる"エモい"セッションに多く参加しました。 ていうかずっとS405に居ました。 いきなりド頭から全員で1時間ひがやすをことDJ Yasuoの近況を聞くのかと思いきや、 「開発者としてある技術をやり遂げたら今の領域に居続けず次の挑戦に進んで欲しい。Seasar2から卒業して欲しい。」 「Seasar2は2016年9月26日をもってサポートを終了。」 と重大発表。 Q.ISIDに組み込まれたSeasar(ビジネスとしてのSeasar)は? A.ISIDにとってSeasar2はビジネスではなく、Seasar2をサポートすることで普及させる・信頼感を高めるためのものだった。また、商用サポートは手間がかかる割にお金にならない。 サポートは大変なのでフェードアウトしたかったのでは(ひが氏個人意見)。 Q.Seasar
1日目も併せてご覧くださいませ。 2日目は午前からどっぷりセッション漬けでした。 色々な刺激を受けつつも非常にリフレッシュできました。 今回はこれを聴きに来ました。 実は第1回に参加してました。別段ドヤれる成績ではなかったですが。 元々iSUCONは旧ライブドアさんが「サーバ大量に仕入れたんでサービスイン前にこれ使ってイベントやろうぜ」的なものだった記憶があります。 ISUCONに勝つためのポイントは以下の通りです。 準備 チーム編成:コミュニケーションコストを減らすため、できれば同じ業務のメンバー、あるいはお互いをよく知っているメンバーがよい。 コミュニケーション:チームメイトとの会話を重視する。問題をいち早く相談して解決する(悩まない)。決まったことはメモ(手書き)して書き出す。後戻りを減らす。 時間配分:チームで認識を合わせる、最後の30分は再起動テストに残す 事前準備 Privat
昨年に引き続き、YAPC::Asiaへお邪魔しました。 YAPCは今年で最後とのことで個人スポンサーでの参加です。 なお、午前のセッションを聴き始めたら会社から割と緊急なコールで途中退場→その場で障害対応ってなわけで午後からのセッションからの参加です。 例によって、場所確保のためにずっと同じ席で聴講です。(たまたま聴きたいセッションが集中していたということもありますが) フロントエンドエンジニアというポジションが成立するようになった今日に至るまで、 Javascriptを中心としたフロントエンド周辺は様々な変遷を経てより高度にあるいは複雑になってきています。 そんなフロントエンド周りの技術要素をnon Javascript時代から現在まで駆け抜け、メインはSPA周りの技術要素についての解説というプレゼンでした。 個人的には一応最近までのトレンドはだいたい押さえてるつもりでしたが、 言葉だけ
訳あってHinemosをジョブコントローラとして利用しているシステムがあります。 ジョブコントローラは以前にとある商用プロダクトを導入したことがあったためか「Hinemosでよろしく」といきなり導入を無茶振りされました。 導入は1年半ほど前ですが、なんかもう色々苦労しました。 今はそれなりに運用できています。 Hinemosは歴史の長いOSSの割にびっくりするほど情報がないので何かの参考になればと思いエントリ化しました。 なお、Hinemosは監視アプリケーションとしての機能もありますが、監視には別のプロダクトを使用しているため監視機能は全く使っていません。 ジョブネットのグラフィカル表示は有償サポート 開始から終了まで一直線なものであればほぼ問題ないですが、複雑な分岐が入った途端に何か別のもの(紙とか)に書いて見ながら入力しないと厳しいです。 あと「今何が実行中か」はわかりますが、全体俯
渋谷Java第二回で発表した内容のもう少し掘り下げた内容です。 主にUNIX系OSでのJavaアプリケーションサーバ運用を想定しています。 なおJava7以前のVMを取り扱っていますが、Java8においてもPermanent以外はほぼ同様かと思います。 運用フェーズのリソースリーク メトリクスの可視化 JVMの監視観点 各ヒープ領域のサイズと使用量 Full GCの頻度 GCログの解析 ファイルオープン数 ヒープ統計情報 別の可能性:純粋なメモリ不足 リソースリークの結果、危なそうだったら… 運用フェーズのリソースリーク 「運用が始まってからJavaWebアプリのリソース障害が発覚する」ということがちょいちょいあります。 特に開発と運用が綺麗に分離されている組織などではエアポケットになりやすい部分かと思います。 もちろんリソースリークの起きないコードを書
このページを最初にブックマークしてみませんか?
『chonaso.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く