アホみたいにでかいgit repositoryを上手く扱う方法 - Qiita
gitが大きくなると時間かかってしゃーないと思っていたら、ちょうどatlassianのブログにこんな記事があった。 How to handle big repositories with git - Atlassian Blogs 巨大なリポジトリ を Git で上手く扱う方法 直訳ではなく、読んだことを参考に自分用にメモを記す。これは本当にメモ代わりなので原文を参照した方がいいと思う。 gitが重くなる原因は、「長い歴史」と「デカいファイル」の2つがある。その2つの対処法。 長い歴史に対処する shallow cloneを使う gitのhistoryが積み重なると、git cloneに時間がかかる。そのときはshallow cloneを使って、深さを限定してcloneする。 git clone --depth depth remote-url 手元の環境だと23sくらいかかっていたのでも
linuxの作業ログをとるscriptコマンドを起動時からいれる - Qiita
2014/07/17追記 この方法だとcentosが起動しなくなりました。なので、実施しないでください。原因は調査中です。 基本中の基本かもしれないけど、地味にやっていなかったのでlinuxの作業ログを起動時から全部取得するのをやっておく。 $ mkdir -p /usr/local/dev/script_log $ chmod 777 /usr/local/dev/script_log $ sudo su $ vi /etc/rc.local #!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V sty
Serfで既存の自動化スクリプト群を叩けるようにして、複数台構成に対応した。 - Qiita
そこでSerfさんですよ。Serfをつかって、eventが送られた際に、任意のスクリプトをすべてのサーバで叩くという構成をつくった。 serf-handler.sh #!/bin/sh HANDLER_DIR="/path/to/scripts" if [ "$SERF_EVENT" = "user" ]; then EVENT="tarr-$SERF_USER_EVENT" elif [ "$SERF_EVENT" = "query" ]; then case ${SERF_QUERY_NAME} in "uptime") uptime;; * ) EVENT="tarr-$SERF_QUERY_NAME";; esac else EVENT=$SERF_EVENT fi HANDLER="$HANDLER_DIR/$EVENT" [ -f "$HANDLER" -a -x "$HAND
fluentd -> elasticsearchでつっこんだデータのstringになっているやつをintegerに変換する - Qiita
fluentd -> elasticsearchでつっこんだデータのstringになっているやつをintegerに変換するFluentdElasticsearch [2015/08/25]追記 この方法では一時的にそのindexではうまくいきますが、fluentdから送られるデータは変わっておらず、新しいindexを作成するタイミングでまた同じ状況になってしまいます。 下記が現状での正しい対処法です。 Elasticsearchでintegerになっていて欲しいところがstringになっていた時の対処法 - Qiita 概要 fluentd + elasticsearch + kibanaを作成して、apacheのlatencyでsortしようとしたら、なんか上手くいかない。latencyがstringではいっていることに気づいた。 確認法 $ curl -X GET localhost:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
