おいぬま日報

qpstudy #01で「rsyncのちょっとイイ話 」というタイトルで話させてもらいました。勉強会で発表というのは初めてで緊張したのですが、なんとか終えられてよかったです。終わった後も参加者の方々からtwitterでrsyncについて色々フォローしてもらい、自分としても勉強になりました。

というわけで資料はこちら。

qpstudy 第2回目も予定されているとのことなので楽しみですね。また何かネタがあったらやりたいな。

インフラエンジニアじゃないけどインフラエンジニア勉強会 hbstudy#5に参加してきました。もともとこのイベントには参加したいなぁと思っていて、参加登録したらいいタイミングで松信さんが講演することにw 貴重なMySQLのチューニングの話が生で聞けてとてもよかったよかった。

あと、最初にPostgreSQLの話をしていた永安さんのセッションもよかった。普通DBの入門の話ってあまりつっこんだ運用の話は出てこないと思うのですが、運用を意識した入門編でこういうのはすごい貴重だったのではないかと。

PostgreSQL安定運用のコツ2009

永安さんの話はスライドを見てもらえばほぼ全てわかります。スライドが充実し過ぎていてあまりメモを取っていなかったのですが、最近のポスグレはAuto Vacuumなんて仕組みがあって、あまりVacuumを意識しなくてよいのだなぁと。あとポスグレもチューニングはいかに共有バッファをうまく使うかっていうところで、あんまりMySQLと変わらないんだなって思いました。

Linux MySQLサーバーのパフォーマンスチューニング

資料(PDF)
MySQLのチューニングの基本はデータサイズを小さくしていかにメモリにのっけるか、という話。たとえば、日時を格納するカラムはDATETIME(8byte使用)じゃなくてTIMESTAMP(4byte)を使えとか。statusみたいな1/0しか入らないカラムは文字列型じゃなくてTINYINTかENUM使えとか。ちなみに日時は2038年問題が気にならないのであれば、UNIXTIME化してINT型のフィールドにしてしまうという荒技もありますよね。アプリケーション側でいちいち変換しなくてはいけないですが。

あと「巨大なTEXT/BLOBはクエリ効率を悪化させる」という話で、巨大なデータを格納するカラムは別テーブルにすると、それ以外のカラムのデータをSELECTするときに悪影響が出ないらしい。ちょっとどういう話か失念してしまったので、資料が公開されたら復習します。一定以上の大きさのテキストフィールドを別領域に保存するストレージエンジンとして、Falcon, PBXTがあるとのこと。ちなみに、HDDが一秒間に処理できるランダムI/Oはせいぜい数百ぐらいなので、とても遅いですと。

あとは実データを引かずにCovering Index(インデックスだけを読む検索)でうまく処理する方法もあるそうで、

• テーブルのレコードにアクセスする必要がなくなるので、高速になる
• Indexのサイズが大きくなるので、更新のコストが高くなる
• Limit句を使うときにも効果がある

というメリットデメリットがあるそうです。

• メモリを十分に確保してダイレクトI/Oを活用する
• オンライン処理のあとに、バッチ処理で巨大なテーブルに対してフルスキャンするのは問題がある
• バッチ処理によるバッファプールが占有され、オンラインのバッファプールが追い出されてしまうため
• OOM Killerに注意する
• ダイレクトI/Oを使うとプロセス内にデータが置かれるので、プロセスのサイズが大きくなる
• DBサーバとしてはファイルシステムキャッシュを縮小してほしい
• # echo 0 > /proc/sys/vm/swappiness = 0
• -> Direct I/Oとセットで使うことが多い
• cpで大きいファイルをコピー
• cpに対してファイルシステムキャッシュが使われる
• InnoDBのプロセスのデータがスワップに追い出される->これは避けたい
• ファイルシステムはext3
  • もっとも使われていて安全
  • dir_index, noatime(relatime)
  • xfsはDirect I/Oだと並列で書き込める
  • xfsは巨大なファイルのコピーがはやい
  • でもxfs使っている人少なすぎなので、おすすめできないｗ
• 監視の方法
  • iotop: プロセス単位でI/O量を取る kernel 2.6.20以降
  • ネットワーク統計: MySQL Cluster使う人には必要かも
  • mtstat: 一秒おきに受信/送信byte数を表示
  • /proc/net/dev をみればわかる情報
• SSD
  • ランダムリードはHDD: 200回にたいして、25000回のI/O (Intel X25E)
  • 書き込み性能は製品による差が激しい
  • write cache必須
  • バッテリーで守れていることが重要。RAIDコントローラに任せるものとSSD自身で持つものがある(RAID Controllerの場合はそれがSSDに対応していることが重要)
  • SSDは並列性が重要。Crystalなんとかのベンチはシングルプロセスの話なのであてにならない
  • PCI-E型SSDにも注目 -> I/Fの速度が速い(300MB -> 2GB)

途中から殴り書きですが、TIMESTAMP型が4byteとDATETIMEの半分で済むことにこの日初めて知りました。その他Covering Indexなど、知らなかったテクニックなのでとても勉強になりました。あとSSDは本当もうすぐそこまで来ていて、これを入れるだけで数倍DBのI/Oが速くなることを考えるとすごいなぁと。しかし色々ベンチ取られていて、すごく説得力のあるお話でした。この人にコンサル頼んだらいくらかかるんだろう…

Redmineのヘビーユーザではないのですが、Redmine勉強会に参加してきました。「ブログに書くまでが勉強会」ということで、雑記ながらログを残しておきます。それにしても大き過ぎず小さ過ぎずのいい勉強会でした。

30分ぐらい遅刻したので最初のyandodさんの発表は聞き逃してしまいました。

Redmine活用術　- 孤独なシス管の記録

kirara_397さん

• Tracはプロジェクトが複数ある場合に管理が大変だったのでRedmineに移行した
• 「トラブル」「要望」「タスク」等にカテゴライズ
• rails環境を構築するまでがそこそこ大変
• カレンダーやガントチャートがプロジェクト毎でしか表示できない→統合表示したい…
• Excel管理に慣れている人には壁があって理解されない…

活用する上で工夫したポイント

• 用語を分かりやすくした（チケット＝課題など）→Redmineの日本語化ファイルを変更するだけ
• ActiveDirectoryアカウントでログインできるようにした→LDAPでもログインできる
• Windowsなのでサービス化した(mongrel_service)

人生も1つのプロジェクトである

• RedmineでGTD
• 【元ネタ】Web2.0ナビ：意外と使われていない「個人用trac」活用のすすめ
• 「世界Redmine」構想→”Redmedia”

Redmineの現実的な利用法

tsuyoshikawaさん(資料)

夢

• 全工程の一元管理
• アジャイル

現実

• 工程管理には向いてないので、そこは結局Excelでガントチャート
• PukiWIki書いてた
• 使ってたのはプログラマだけ

Redmineはコミュニケーション促進ツール

• チケット
• 文書
• ニュース
• Wiki
• リポジトリ
• 通知
• メール、RSS

チケット

• 「分類」って属性だけ追加
• チェンジセットまぁ便利 (ref #n, fix #n)
• カスタムクエリまあ便利

ニュース

• リーダーとしての方針を伝える
• プロジェクトの大きな変化（遅延など）を知らせる

文書

• 運用の取り決め
• コーディング規約とか

Wiki

• いらない子ｗ
• PukiWiki記法に慣れてるし
• ソースのせる用のテンポラリ領域として使用

リポジトリ

• 空気。とまっててもコミッタ以外は気付かない

活動

• 全ての活動ログ
• 一番大事
• アクティビティ・ストリーム
• さぼっている人が一発でわかるw

まとめ

• ウォーターフォールの工程管理には向いていない
• 使い方はかなり自由度が高いので、ルール最低限でとにかく使わせてみましょう
• 大事なのは活動をRSS登録すること

完璧なRedmineなど存在しない

junoさん(資料)

18 projects
1,696 tickets
22 users

なぜTracをやめたか
→管理画面の機能が貧弱

Redmine移行にあたってやったこと

• マニュアルの作成
• 段階的な導入(走っているプロジェクトはTracのまま)
• 自分が率先して使う

Textile記法ないわー

• Markdownが使いたい(WordPressでも使ってる)
• Markdown Extraが使いたい。redmine_markdown_extra_formatterというのがある

CSVで一括インポート

• PMからの要望 (Excel派)
• redmine_importer
• ExcelRedmineAddIn

楽しく利用してもらうための細工

• ユーザーアイコン
• Gravatarを利用する。デフォルトで使える。ユーザが自由に画像を変更できる。ただしメールアドレスをGravatarに登録する必要がある
• Local avatars Pluginを利用する。これだと画像はRedmineサーバ上に格納される

他にも

• favicon.icoをちゃんと作る
• グラフィカルなプラグイン(Gompertanなど)
• スニペット共有プラグイン(redmine_codebook)→検索の対象にならないのがネック

パッチのプラグイン化

• 通知メールのSubjectを変更する。UTF-8で長いSubjectのメールが文字化けする
• バージョンアップのたびにソースを直す必要がある
• 参考文献：Plugin Tutorial、Plugin Internals(こっちがいい)
• alias_method_chainを使いこなすことがポイント

LT – CSVユーザー一括登録プラグインを作ってみた話

shrkwさん(資料)

BTS使用歴

• Trac
• GLPI
• Backlog

Ruby歴2日目だったが、Redmineのほうがrailsにのっかっている分、Tracよりプラグイン作りやすい。

ってかRedmineでCSVのユーザ情報をまとめて登録するスクリプトのエントリーが紹介されていた!!

ユーザを一発で登録できるプラグインを作成したので、そのデモ。

懇親会

中華料理屋にて懇親会。自分たちのテーブルはおそらく一番Redmineを使っていない人たちが集まったテーブルのようでした。「言語は何使ってる？」「DBはMySQL派？ポスグレ派？」「OSは？」「バージョン管理は？Git？SVN？」みたいな会話が飛び交い、Redmineの話はほとんどしませんでしたw あと、意外に影舞ユーザが多いことが判明したのも大きな収穫でした。ほら、任天堂でも影舞が使われているらしいし…やっぱりシンプルなものが受け入れられるのだなぁと。

雑感

• 「活動」は自分の作業報告をする上でうまく使えたらいいなぁと
• みんなRedmineを改造して使っているということがわかって、それが邪道な使い方じゃないんだなぁとわかったのがよかったです。そういう意味では、「モンキーパッチをプラグイン化してRedmine本体のバージョンアップに備える」というjunoさんの路線はすごくいい気がしました。
• Redmineはデザインにもっと良くした方が… ってことを言っている人がいて全く同感でした
• あとはRedmine本家の開発体制が「独裁主義なんじゃ」という話がありました。実際のところメインの人以外でコミッターっているのでしょうか…