リモートのgitブランチをローカルにチェックアウトする - setoya-blog
まずは、リモートにどんなブランチがあるかを確かめる。-aオプションでリモートブランチも一覧できる。 > git branch -a * master remotes/origin/master remotes/origin/other_branch チェックアウトしたいブランチが表示されていない時は、git fetchとかすると情報をリポジトリから取得できる。 > git fetch 次に、ローカルブランチ名を指定して、リモートブランチをチェックアウトする > git checkout -b other_branch origin/other_branch 最初の引数がローカルブランチ名 -bオプションを指定しておくと、自動的にそのブランチに切り替わる。 -bオプションを指定しないと、以下を再度する必要がある。 git checkout -b other_branch
チューニング例1 「Java VMのチューニング」(＠IT：連載：J2EEパフォーマンスチューニング 第4回（2/4）)
ヒープサイズを決める ヒープサイズがシステムの使用可能な空き物理メモリより大きくならないようにします。ページスワップが頻繁に発生しない程度に設定を行ってください。OSのページングの設定にも影響しますが、使用可能な物理メモリ（OSまたはそのほかのプロセスによって占有されない物理メモリ）の80％が妥当な値と思われます。今回のテストでは、（全体メモリ[512Mbytes] -OS使用のメモリサイズ[128Mbytes]）×80％＝307Mbytesとなります。また、通常、XmsとXmxは同じ値に設定され、ヒープ時の負荷を軽減します。 GC値を決める パフォーマンスを向上させるポイントは、キャッシュされたオブジェクトをなるべく再利用するようにアプリケーションを作成することと、New世代領域とOld世代領域の比率を考えながらXX:NewSize、XX:MaxNewSizeの値を設定することです。有効
Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
「Java のヒープサイズ」についての簡単な説明
Java のヒープ領域及び 非ヒープ領域、メモリ管理について簡単に説明いたします。 ヒープやヒープサイズはガーベジ・コレクション：GC ( Garbage Collection ) と密接な関連があります。以下のページも合わせて参照ください。 ガーベジ・コレクション：GC ( Garbage Collection ) についての簡単な説明と調査方法 Java のオブジェクトは、大きく分けて、New、Old 、Permanent というメモリ領域で管理されます。 新しいオブジェクトを格納するのが New 領域と呼ばれ、古いオブジェクトを格納するのが Old 領域と呼ばれます。 Permanent 領域にはクラスやメソッドなどの情報が格納されます。 ( これらは Permanent Generation, Tenured Generation, Young Generation とも
[Jmeter]負荷があまりかからない場合の対策 | 黄脳エンジニアメモ
Webアプリケーションサーバの負荷上限を調べることになった。 利用者が増えていてWebAPサーバがあとどれぐらいもつのかサーバを増やす必要があるのか、なにかほかのボトルネックがきて動かなくなってしまうのがわからないのでというものだった。 追記 Jmeter2.7までの内容なので情報が古いです。 ということでJmeter登場 ログインが必要なサービスであったため負荷にabコマンドは使えず、セッションを保持したアクセスで負荷をかけて調べるためにjmeterを利用した。apacheのaccess.logをしらべてアクセスの傾向をしらべ、にたような割合と間隔でリクエストを発行するようにjmeterのシナリオを作成した。 あとはこれで同時アクセスを増やしながら、応答時間とスループットを計測すれば限界のrps(request/sec）を調べれば限界がわかる。あとは高負荷状態でリソースをしらべなにがボト
JMeter の利用方法(1) – Ramp－up、スレッド数、ループ回数の誤用 | 株式会社ケイズ・ソフトウェア
こんにちは、今回から何回かに分けて Apache JMeter の使い方について記事を書いてみたいと思います。 単純に負荷を限界までかけるだけのテストを行う場合、AB(Apache Bench) 等の簡易なツールから行う方法から、JMeter のように GUI のツールを備えたシナリオテストまで可能なツールで行う方法までさまざまな方法があります。 実務では特定の URL だけをひたすら叩いて・・というテストではあまり意味のある数字が出て来ない事が多く、JMeter を利用してシナリオを作ってテストする事が多いです。 限界まで負荷をかけ続けるのではなくて、秒間リクエスト数(rps)を決め打ちして実行してみてサーバ側の負荷やその他の状態を監視したいというニーズもすぐに出てきます。 さて、JMeter でそのようなテストを実施する場合にどのように行うかというと、これにはいくつかの方法が考えられる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
