「This repository’s size is over 1 GB.」と Bitbucket に注意されました。 limit があるので 1GB を越えたところで警告するよ、ということのようです。 What kind of limits do you have on repository/file/upload size? – Bitbucket – Atlassian Documentation限定的ではありますが、対応してみました。 今後のために作業手順をメモしておきます。
![git repository size を削減する | DriftwoodJP](https://cdn-ak-scissors.b.st-hatena.com/image/square/dbe0b1f80a9cba330c14ce2f03c29faa6f986d6f/height=288;version=1;width=512/https%3A%2F%2Fwww.d-wood.com%2Fwpmt%2Fwp-content%2Fthemes%2Fdeadwood2%2Fimg%2Fog_image.jpg)
gitを使ってるとたまにgit gcが走る。これがどういうタイミングで実行されているか調べたので軽くメモしておく。 Gitでは時々auto gcが走る Git - Book を見ると、以下のように書かれている。 Git は時々 "auto gc" と呼ばれるコマンドを自動的に実行します。大抵の場合、このコマンドは何もしません。もし沢山の緩いオブジェクト(パックファイルの中にないオブジェクト)があったり、あまりに多くのパックファイルがあると、Git は完全な(full-fledged)git gc コマンドを開始します。 さらに、auto gcは普段は何もせず、特定の条件を満たすと実際にgcするとも書かれている。 繰り返しますが、これは通常は何も行いません。約 7,000個もの緩いオブジェクトがあるか、または50以上のパックファイルがないと、Gitは実際に gc コマンドを開始しません。これ
本稿は、ブダペストで開かれたイベント「 RuPy 」で、Pat Shaughnessyが披露したプレゼンの内容をまとめたものです。 プレゼンの映像はここ から視聴できます。 本稿は当初、 同氏の個人ブログ に投稿されましたが、同氏の了承を得て、Codeshipに再掲載します。 このイベントは「RubyとPython」に関するカンファレンスなので、RubyとPythonでは、ガベージコレクション(以下「GC」)の動作がどう違うのかを比較すると面白いだろうと私は思いました。 ただしその本題に入る前に、そもそもなぜ、GCを取り上げるのかについてお話しします。正直言って、すごく魅力的な、わくわくするテーマではないですよね? 皆さんの中でGCと聞いて、心がときめいた方はいらっしゃいますか? [実はこのカンファレンス出席者の中で、ここで手を挙げた人は数名いました!] Rubyコミュニティで最近、Rub
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
pwd が何の略か? ということを聞かれた。確かに答えられない。 http://www.abbreviations.com/pwd の中で working directory を含むものをピックアップすると、 Print Working Directory Present Working Directory Path of Working Directory の3説が見つかる。 man を見ても、あんまりしっくりこない。なんで cwd (current working directory)にしなかったんだろう? system call は getcwd(2) なのに。 昨日の続き。 早速中田さんが r49614 を入れてくれて、こういう a, b = x, y の時には、 push x # stack: x push y # stack: x y newarray 2 # stack: [
Ruby 2.2 の新機能にシンボル GC というものがあります。 正直、「え、シンボルって GC されないから速いんじゃないの?なのにシンボル GC で Rails が速くなるとか話聞くけど、いったいどういうことなの?」という感じでサッパリ理解できてなかったのですが、その辺りの疑問に対してまとめられている記事がありました。 Symbol GC in Ruby 2.2 とても分かりやすく素晴らしい記事だと感じたので、許可をもらって以下に日本語訳を公開します。 Symbol GC in Ruby 2.2 シンボル GC ってなに?それって気にしなくちゃいけないことなの? リリースされたばかりの Ruby 2.2 の大きな新機能として「インクリメンタル GC」が挙げられますが、もう1つの注目すべき新機能が、この「シンボル GC」 です。 もしあなたがこれまで Ruby の世界で過ごしてきたのな
こんにちは!SI部の満石です。 以前、仕事でJRockit Flight Recorder(現在OracleJDKに付属しているJava Flight Recorderの元になったもの)を使ったことがあり、最近出てきたHeapStatsにも興味があって使ってみたのでご紹介します。 HeapStatsとは NTT OSSセンタが開発したOSS(Open Source Software)であり、HeapStatsの日本語Wikiには以下のとおりに書かれています。 HeapStats とは、JavaVM のヒープやGC状況を監視する軽量なツールで、エラーの兆候を検知してSNMPのようなリアルタイムなアラートを発します。生成するログはかなり小さいもので、GUIツールで解析することができます。HeapStatsは、次の二つのプログラムで構成されます: エージェント(agent) – JavaVMの情
@azukiwasher さんからRuby2.1のGCについて解説されている記事の日本語訳を頂きました。 『WEB+DB の Ruby 2.1 特集を読んでたら、ガベージコレクション(RGenGC)の説明で参照されてた記事の次の記事がためになったので訳してみた。』 Vol.79ですね。 ソース Ruby 2.1: Out-of-Band GC · computer talk by @tmm1 Ruby 2.1: Out-of-Band GC Ruby 2.1 で GC は以前よりずっとマシになったが、相変わらず "Stop The World" な実装に変わりはない。リクエスト処理中にコレクションが始まると、リクエストへの応答時間に遅延が生じる。遅延を緩和する方法のひとつにリクエストとリクエストの間に GC を走らせる、いわゆる「Out-of-Band」がある。 OOBGC はよく知られた
ほとんどの開発者は、自動のガベージコレクション(GC)を当たり前のように使っています。これは、私たちの仕事を容易にするために言語ランタイムが提供する素晴らしい機能の1つです。 しかし、最新のガベージコレクタの中をのぞいてみれば、実際の仕組みは非常に理解しづらいことが分かります。実装の詳細が無数にあるため、それが何をしようとしているのか、また、それがとんでもなく間違った事態を引き起こしかねないことについて十分理解していない限り、すっかり混乱してしまうでしょう。 そこで、5種類のガベージコレクションアルゴリズムを持つおもちゃを作ってみました。小さいアニメーションはランタイムの動作から作成しました。もっと大きいアニメーションとそれを作成するコードは github.com/kenfox/gc-viz で見ることができます。単純なアニメーションによってこうした重要なアルゴリズムを明らかにできることは
まじめにJVMチューニングに取り組む機会があったので、忘れないようにこの記事を書きました。 GCアルゴリズムやパラメータの説明はいろいろなサイトに掲載されていたのですが、 「どうやって取り組むか」「何を見れば良いか」は意外とまとまっていなかったので。 JavaやScala製のアプリケーションはもちろんのこと、 Solr, ZooKeeper, Cassandra, Neo4J等jvm上で動くプロダクトを使う場合つねに 「JVMパラメータをどう設定するか」 という課題があります。 最近のミドルウェアでは、インストール時に最適なオプションを渡して javaを実行するようなシェルをつくるrpmを提供していたりしますが。 さて、今回私が取り組んだのはフルGC対策のためのチューニングです。 フルGCとは何かというと、 別名「Stop the World」と呼ばれ、全てのアプリケーション・スレッドを停
前回、JVMとGCのしくみ - ITエンジニアとして生きるでJVMとGCのしくみについて書いた。 今回はその続きということでJVMのチューニングについて書きたいと思う。 JVMチューニングって -Xms ・・・ ヒープ全体(New領域+Old領域)の初期値 -Xmx ・・・ ヒープ全体(New領域+Old領域)の最大値 くらいしか話題に上がらないし意識しないことが多い(気がする)。 でもホントはこれだけではダメで、前回のようにPermanent領域、New領域、Old領域を意識したチューニングが必要になる。 VMチューニングを考えるその前に・・・チューニングの話をする前にまずVMの起動モードについて話したいと思う。 VMには大きく以下2つの起動モードがあり、それぞれ以下のような特徴を持つ。 ◆クライアントVMモード 起動時間を短縮し、メモリサイズを縮小するように調整されている。 VM起動時
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
(環境変数GODEBUGは、 ランタイム パッケージで提供されています) この環境変数を指定してプログラムを起動すると、標準出力に以下の追加出力が出力されます(少し簡略化されています)。 % env GODEBUG=gctrace=1 godoc -http=:6060 ... gc76(1): 2+1+1390+1 us, 1 -> 3 MB, 16397 (1015746-999349) objects, 1436/1/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields gc77(1): 2+0+1582+1 us, 2 -> 4 MB, 14623 (1016248-1001625) objects, 1436/0/0 sweeps, 0(0) handoff, 0(0) steal, 0/0/0 yields scvg0: inuse:
Purpose This tutorial covers the basics of how Garbage Collection works with the Hotspot JVM. Once you have learned how the garbage collector functions, learn how to monitor the garbage collection process using Visual VM. Finally, learn which garbage collectors are available in the Java SE 7 Hotspot JVM. Time to Complete Approximately 1 hour Introduction This OBE covers the basics of Java Virtual
このテーマ自体はさんざん語り尽くされていることである。たとえば山口君によるWhy Erlang? というブログ記事の翻訳や、戦闘機本(Programming Erlang: Software for a Concurrent World (Pragmatic Programmers))を読めば世間でいわれていることはよく分かる。もしくは、同僚が最近書いたソフトウェアデザインの記事を読んでもらってもよいだろう。 Software Design (ソフトウェア デザイン) 2014年 02月号 [雑誌] 出版社/メーカー: 技術評論社発売日: 2014/01/18メディア: 雑誌この商品を含むブログ (3件) を見る 私自身もErlangに出会ってから5,6年が経とうとしているが、当初はそのよさがよくわかっていなかったように思う。しかし、仕事で高可用性が要求される複雑な分散システムに携わるよう
※タイトルは釣りです。 先のエントリで、 採るべき技術的アプローチに関しては、ソフトウェアの修正コストによってかわるという議論があって、ウェブサービスの場合にはソフトウェア製品(やSI)と比べて圧倒的に修正コストが安い。ウェブサービスの場合にロケット科学的な「正しいけど大げさ」なアプローチよりも、小さく作って動かしながら修正していく手法が好まれるのにはそういう背景もある ソフトウェアのアップデートとウェブサービス運用における継続性リスクについて - kazuhoのメモ置き場 と書いた件、GCを例にあげて説明します。 ソフトウェアを製品として出荷するビジネスは、修正コストが高いです*1。企業向けソフトウェアなら、管理者がアップデートをインストールしなけりゃいけないし、それによって不具合が発生していないか結合試験が必要になるかもしれないし、場合によって南極まで出張して…ごにょごにょ。 こういう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く