タグ

2016年7月8日のブックマーク (5件)

  • EvernoteからAtom+Markdown+Dropboxに乗り換えてみて - セカイノカタチ

    [↑マルチディスプレイの図(左からWindows,Mac,Linux)] さて。Evernoteショックから一週間が経ちました。 qtamaki.hatenablog.com 前回の記事で、Evernoteから、Atom + DropBox + Markdown構成への移行を決意したわけですが、結果として「超快適」です。^^ 現在、(恐らく利用者を対象に)半額キャンペーンをやっているので「1年ぐらいはプレミアム課金しても良いかな?」と思っていますが、今後入力するデータは、この構成を使っていきたいと思っています。 やはり、Markdownでさくさくメモが取れるのは、嬉しさ満点です。 こんな感じで、フォルダ分けをして、ファイルを追加していけば、ほぼEvernoteと同じ使用感になります。 この構成の良い所を上げます。 軽い Evernoteでは、長めの文章(数百行)を打っていると、信じられない

    EvernoteからAtom+Markdown+Dropboxに乗り換えてみて - セカイノカタチ
  • Java開発の性能改善! その3 ヒープダンプを取ろう - Qiita

    プロセスIDがわかったらjmapコマンドでダンプを取ります。 サーバのディスク容量に注意してください。 heapサイズを2GBとかに設定した場合は2GB以上のファイルが 生成されることがあります。 これで指定した場所にダンプファイルができます。 -dump:live,format=...というようにliveをつけるとGCが起きて コマンド実行時に活きているオブジェクトのみのダンプになるようです。 とりあえず今回はフルで取ります。 ヒープダンプの中身を解析をする 解析をするにはツールを使います。 java標準のjhatやMemory Analyzer、HeapAnalyzerなど いくつかありますが今回はMemory Analyzerを使います。 Eclipseベースなのでサイズの大きいダンプファイルを開く場合は MemoryAnalyzer.iniの設定でツール自体のヒープサイズを 増やす

    Java開発の性能改善! その3 ヒープダンプを取ろう - Qiita
  • Java開発の性能改善! その2 GCログの解析とHeapの設定 - Qiita

    第2回です。 なかなか更新できる時間がないですが マイペースで書いていこうと思います。 ストックやフォローをして頂けると励みになります。 さて前回はGCの仕組みの概要説明とjstatでのモニタリングでした。 今回はCGログの分析をしてみようと思います。 JVMのGCログ設定 まずはGCログが取得できるように設定しないと始まりませんね。 以下のようなオプションをjavaの起動コマンドに付与すると GCの情報を取れるようになります。 -verbose:gc [GC 919089K->41941K(943744K), 0.2300771 secs] こんな感じのGCログが出ます。 -XX:+PrintGCDetails -XX:+PrintGCDateStamps [GC2015-12-10T07:06:41.209+0900: 308.418: [ParNew: 903392K->50610K

    Java開発の性能改善! その2 GCログの解析とHeapの設定 - Qiita
  • Java開発の性能改善! その1 jstatによるヒープ/GCの確認 - Qiita

    JavaのWeb開発の開発後期になると性能試験や負荷試験を実施することになると思いますが、 そのフェーズになると色々な問題が起こることが多い。 今まで起きた問題と調査・解決方法をいくつかの回に分けて紹介しようと思います。 まずはメモリリーク。 長時間サーバを起動して運用していたり、負荷試験を実施するとメモリリークを起こすことがある。 ガベージコレクションのおさらい Javaのヒープは大きくnew領域(young領域)とold領域に分かれます。 new領域には生成されてすぐのオブジェクトが格納されてマイナーGCにて未使用になった際に開放されます。 マイナーGCを何度も繰り返されても開放されない(長く参照されている)オブジェクトは old領域へと移動され、こちらはメジャーGC(フルGC)で開放されます。(メジャーGCはnewとperm領域も開放。) もう少し細かく説明すると・・・ new領域は

    Java開発の性能改善! その1 jstatによるヒープ/GCの確認 - Qiita
  • Lambda+RDSはアンチパターン - Qiita

    何が起きたのか 作成していたアプリではサーバレス構成にてLambdaからRDS(MySQL)を呼び出していました。 リクエストが増えるとRDSのコネクション数が増加して すぐにDBコネクションエラーになってしまいました。 最大コネクションの上限値 結論から言うとLambdaとRDS(MySQL)は相性が良くないです。 理由はLambdaからRDSのDBコネクションを貼ると リクエスト単位でコネクションを張ってしまうため 仕組み上、同時接続に耐えられません (RDSのコネクション上限数が少ない) さらにVPC設定すると・・・ セキュリティのため、RDSをLambdaからのみアクセスさせるためには LambdaとRDSを両方とも VPC領域に置く必要があるのですが、Lambdaの起動が遅くなる場合があります。 これは、一定時間Lambdaがコールしない場合にスリープ状態になり、 起動する際にE

    Lambda+RDSはアンチパターン - Qiita