ISUCON8に1人で参加してきました
ISUCON7は3人チームで参加しましたが、今回は1人参加も可能ということで、ぼっち参加してきました。
1人参加は枠数が限られていたので、慌てて申し込んだ結果、実は見たことのない「RE: ゼロから始めるISUCON 」に。
結果は最高スコア32,596、最終スコア26,873で予選落ちではあるものの、去年の反省を活かした動きである程度のスコアが出せたのは良かったです。
ただ、正直手が付けられていない箇所が多すぎて、不完全燃焼感も。
# 後日の検証でLBだけ有効にしたら79,356でましたが、不安定だし、たらればですね。(でも書いちゃう)
やったことと感想
事前に決めていたこと
1人参加、かつアプリ寄りの人間のため、迷ってる暇はなさそう。インフラ側の変更は最低限にして、アプリの改修を優先しよう。
ISUCON7でも使用したkataribe, pt-query-digest, netdataは今回も使いたいな。特に前回の教訓を元にネットワークの帯域には気を付けよう。
1人だと自由に本番環境を使えるから、手元環境で動作させる必要は無いよね。いつも使ってるdotfilesを本番に入れられる準備はしておこう。
前回同様、複数台構成の可能性もあるし、普段のサーバ(tmux入り)からwindow/paneを切ってつなごう。
事前準備
- 初期設定・計測用スクリプトの準備
- tmuxのwindow/pane切り分け
- 最終手順の手順書準備(不要サービス停止、ログ抑制)
チューニング方針
環境を確認した瞬間「出題DeNAじゃん!!」と叫んでしまったのですが……十分考えられる選択だったよね。
nginxに置き換えた人も多かったようですが、設定をみたら割と読みやすかったのと、事前方針を思い出してh2oのまま行くことにしました。
(Evernoteからnginxインストール/設定手順を取り出してダウンロードまでは掛けたんですが)
チューニングの手順としてはpt-query-digestで重い部分を洗い出して修正していくという基本的なもの。
一通りコードを読んでget_events
/get_event
が重いことは明らかだったんですが、呼んでいる箇所が多すぎて挙動を変えづらいのが難点でしたね。
結局、cancelの扱いがクエリを複雑にしているので、現在の予約状況を示すテーブルを新しく切って対応しました。
current_reservations( id, event_id, sheet_id, num, rank, user_id, reserved_at, reservation_id )
非正規化の極みとばかりに、どんどん必要になったカラムを増やしていきましたが、最終的にはcurrent_reservations
自身がボトルネックになってしまっていたのがちょっと残念かな。
(対応した順番としてはこっちが先ですが)残席数管理はredisにしました。
残席自体もredisのsetで管理しようと考えたんですが、何故か残席のsetじゃなくて、予約席のsetを作ろうと考えてしまい、そうするとreserved_at
をどこに持とう?とか考えて、結局RDBにしてしまいました。
atomicなpop処理ができれば、redisだけでロックの代替ができたのかな?
後は細かいところをあれこれと弄っていました。
- get_event
は呼び出し元によってはdetail
が要らないので、with_detail
引数を増やしたり
- sheets
情報をpython中にハードコーディング
- sha256の計算をhashlib
でやってみたり
- kataribe的にloginが重いと言われたからやってみたけど、ストレッチングも無いのでそもそも重くないかも
- テーブルへのindex追加
- get_login_user
を呼ぶ必要のない場所があったので削除
- mysqlをserver3に移動
悔やまれる点
- admin側が全然見られなかった
- lock問題についてはそこまで悩まされなかったが、理解して回避したというより、運よく回避した、という感じが強い
- 実際、スコアが不安定で、failすることもあった
- 明らかにここ変えたい、という場所に手が回らなかった
order by rand()
- h2oのLBが
/etc/hosts
でできることを知らなかった /etc/hosts
に2レコード書いてping
飛ばすところまではやったけど、ダメだったのであきらめた。h2o本体で試すべきだった。- ISUCON7予選のトラウマから50Mbpsのグローバル帯域を気にしすぎた
課題・環境について
ポータルがすごく便利。ベンチマークも全く待ち時間が無く、とても快適でした。
課題としては面白かったものの、lockが主題になるとスコアが安定しないのが難点か。
修正が役に立ったのかどうかがもひとつ判断できず、ツライ時間が続いたりしました。
サーバについては、終了後にベンチ環境まで含めて1週間公開してくれるというのがすごくありがたいです。
時間切れで試せなかった場所とか、ロックの関連とかいろいろ見てみたいと思います。
サーバ提供のConoHa GMOインターネット株式会社さまと、このはちゃんには足を向けて眠れませんね!
1人参加のメリット・デメリット
さて、せっかくの1人参加ということで、1人参加のメリットとデメリットも書いておこうと思います。
ISUCON9で1人枠が用意されるかはわかりませんが、参加を考えている人は参考にしてください。
メリット
- 自宅から参加できる(いつものPC、いつものキーボード、移動時間0分)
- 本番環境を自由にカスタマイズ可能(zsh, vim)
- 本番環境で直接作業ができる(gunicornをフロントで起動)
- ベンチマーク実行時とかに他の人の確認を取る必要が無い
- 何をやったか、どこまで終わったかが常に把握できる
デメリット
- 手が足りない
- 嵌ったときにグーグル先生にしか頼れない
- 改修してもスコアが出ない時間が続くと気持ちが折れやすい
- 知識のカバー範囲が足りない
- アプリ1人、インフラ1人、計測&方針決定1人のチームが強そう
- 打ち上げがちょっと寂しい
出遅れたけどBingoカード生成問題書いてみた
RSS整理してたら再発見したので書いてみた。 回答締切どころか既に模範解答まで出てるけどまぁ、それはそれ。
class Bingo def self.generate_card values = (1..75).each_slice(15).map(&:shuffle).transpose.first(5) values[2][2] = '' header = %w(B I N G O) ([header] + values).each do |row| puts row.map { |col| col.to_s.rjust(2) }.join(' | ') end end end Bingo.generate_card
行列を転置することで割ときれいに書けた気がする。満足。
H-IIA 102型のΔVを計算してみた
Twitterを見ていたらH-IIA 102構成なんてのが話に出ていたのでちと計算。
今までこの類の計算したことないのでググりつつ。違ってもご愛嬌。
さて、まずは公式サイトから各種の値を調べてみよう。
http://www.jaxa.jp/projects/rockets/h2a/index_j.html
第一段 | SRB-A(2本合算) | 第二段 | フェアリング(4S) | |
---|---|---|---|---|
重量 | 114トン | 151トン | 20トン | 1.4トン |
推進薬重量 | 101.1トン | 130トン | 16.9トン | |
構造体重量 | 12.9トン | 21トン | 3.1トン | 1.4トン |
推力 | 1098kN | 5040kN | 137kN | |
燃焼時間 | 390秒 | 100秒 | 530秒 | |
比推力 | 440秒 | 283秒 | 448秒 |
SRB-Aは数字を見る限り高圧型ですね。
さて計算開始。
SRB-A燃焼終了まで
最初は1段目とSRBが同時燃焼するので比推力がややこしい。
ググったらこんなQAが引っかかったのでそのまま式を使わせてもらおう。
http://okwave.jp/qa/q4133393.html
Isp = (F_B + F_L) / (F_B×Isp_L + F_L×Isp_B)×Isp_B×Isp_L Isp = (5040 + 1098) / (5040 * 440 + 1098 * 283) * 283 * 440 ≒ 302.3秒
合算した比推力は302.3秒とでた。うん、感覚的にもあってるっぽい。
打ち上げ時質量
さて、質量を求めます。
1段目、SRB2本、フェアリングで114 + 154 + 1.4 = 269.4t。ペイロードは……とりあえず空で。
SRB燃焼終了時質量
打ち上げ100秒後にSRBが燃焼停止するのでこの時点の質量を求めます。
1段目はMECOまで390秒。推進薬101.1トンの25.6%ほどを消費したとみて、残りの推進薬は75.2トンほど。
エンジン、タンク等の構造体含めて88.1トンですね。SRBは全推進薬を消費したので21トン。
合計で88.1 + 21 + 1.4 = 110.5トンですかね。
ΔVの計算
ツィオルコフスキーの公式からΔVを求めると
9.8m/s^2 * 302.3 * ln(269.4 / 110.5) = 2640m/s
SRB-A分離から1段目燃焼終了まで
残りは1段目が頑張る。
初期質量
SRB-Aを分離したので残りの質量は88.1 + 1.4 = 89.5トンほど。
MECO時質量
打ち上げから390秒後にMECO。この時点の質量は12.9 + 1.4 = 14.3トンぐらい。
実際には途中でフェアリングを放棄しますが、まぁ、ペイロード替わりってことで。
ΔVの計算
同じくツィオルコフスキーの公式からΔVを求めると
9.8m/s^2 * 440 * ln(89.5 / 14.3) = 7908m/s
合計で2640 + 7908 = 10548m/sか。
……あれ、思ったより速い。
もっとボロボロの結果がでて、「やっぱりSSTOは無理だったよ(知ってた)」となると思ったんだが……
重力損失とか空気抵抗とか考えるとSSTOは厳しいにしても、ここまで速度が出せるとはびっくり。
何か計算間違いしている可能性もあるけど気にしない。
まぁ、そうは言っても
3トンのペイロード積んだ場合
9.8m/s^2 * 302.3 * ln(272.4 / 113.5) = 2593m/s 9.8m/s^2 * 440 * ln(92.5 / 17.3) = 7229m/s
2593 + 7229 = 9822m/sとなるので、やはり実用的なSSTOはまだ先の様子。
おまけ:通常のH-IIA 202(ペイロード5トン)の場合
初期質量:114 + 151 + 20 + 1.4 + 5 = 291.4 SRB燃焼終了時質量:88.1 + 21 + 20 + 1.4 + 5 = 135.5 ΔV = 9.8m/s^2 * 302 * ln(291.4 / 135.5) = 2266 SRB分離後質量:88.1 + 20 + 1.4 + 5 = 114.5 MECO時質量:12.9 + 20 + 1.4 + 5 = 39.3 ΔV = 9.8m/s^2 * 440 * ln(114.5 / 39.3) = 4611 1段目/フェアリング分離後質量:20 + 5 = 25 SECO時質量:3.1 + 5 = 8.1 ΔV = 9.8m/s^2 * 448 * ln(25 / 8.1) = 4948 2266 + 4611 + 4948 = 11825
流石。
Ctrl + Shift + SpaceでScanSnap Managerのダイアログが開いてしまう場合の対策
2) PfuSsMon32.cfg ファイルを、メモ帳などで開き、以下の項目
(IsRegist_HotKey=0)を追加してください。[CONFIG_C]
IsRegist_HotKey=0
http://aide-memoire.seesaa.net/article/20699317.html
リンク先は2006年の記事なので、ScanSnap ManagerかSpanSnap本体のバージョンアップに伴って場所が変わっているようだ。
iX500に付属してきたScanSnap Managerの場合、同ディレクトリのSsCommon.cfgに同様の設定を書くことで抑止できた。
例で学ぶ所得税と年末調整(ついでに復興税)
会社によって時期は違うようですが、そろそろ年末調整の書類を提出した人が多いかと思います。でも、年末調整の仕組みや所得税の仕組みをちゃんと知っている人は少ないのではないでしょうか?会社務めをしていると会社側で計算してもらえるため、あまり関わることはありませんが「理由はわからないけど引かれてる」のは、なんとなく気持ち悪いものです。
ということで、とあるサラリーマン「Aさん」を仮定して所得税を計算してみたいと思います。
Aさんの例を使った計算は青文字で書くことにします。
なお、独学で調べただけなので勘違いしている箇所があるかもしれません。あしからず。
あと、全部の分野を1エントリで書くのは無理なので、ほどほどに一般的な「Aさん」を仮定します。
まずは「Aさん」の設定
そもそも年末調整って?
支払い済みの所得税と、実際の所得税を差し引きして調整するための仕組みです。
住民税は「昨年の収入」に対してかかる税金のため、既に金額が確定していますが、所得税は「今年の収入」に対してかかる税金のため、12月の給与明細が出てこないと税金の額が確定しません。*1
しかし、年末や年度末になってから一括で所得税を徴収すると、国としても収入が読みづらく不安定になりますし、徴収される側としても年末にいきなり大金が持っていかれるのは困ります。そのため、毎月の給料や賞与(ボーナス)の支給時に所得税を引いた額を支給しています。これが源泉徴収です。
では所得税って?
その名の通り「所得」に対してかかる税金です。分かりやすく言えば収入に対してかかる税金ですが、収入全額にかかるわけではなく、様々な「控除」が存在します。
所得税=(収入 − 控除) × 税率
収入の種類や、家族構成などによって控除の種類は異なりますが、大抵のサラリーマンは「給与収入」のみを考えれば良いでしょう。「給与収入」は普段目にする「給与」「賞与(ボーナス)」の合計額になります。(手取り額ではなく、色々引かれる前の金額)
この「給与収入」は幅広く、月の給料、ボーナス、住宅手当、食事手当、職能給などを全て含みます。ただし、通勤手当だけはちょっと取り扱いが特殊です。今回は概算ということでAさんは通勤手当なしで給与収入600万としておきます。
Aさんの場合:
給与収入 = 6,000,000円
それでは、様々な控除について一つずつ見ていきたいと思います。
給与所得控除
まずは給与所得控除です。
自営業者などであれば「収入−仕入原価−経費」で利益(所得)が求まりますが、サラリーマンの場合は「経費」というものがはっきりしません。そのため、給与収入を得ている人の場合は、以下の表に従って計算した金額を「給与所得控除」とすることになっています。
給与収入 | 給与所得控除額*2 |
---|---|
〜1,800,000円 | 収入金額×40%(650,000円に満たない場合には650,000円) |
1,800,000円〜3,600,000円以下 | 収入金額×30%+180,000円 |
3,600,000円〜6,600,000円以下 | 収入金額×20%+540,000円 |
6,600,000円〜10,000,000円以下 | 収入金額×10%+1,200,000円 |
10,000,000円〜 | 収入金額×5%+1,700,000円 |
180万や360万といった境目で40%から30%、20%へ一気に変化しますが、その分補正が入っているので下図の青線(給与所得控除額)、赤線(給与所得控除後の金額)共に滑らかに変化していきます。
Aさんの場合:
給与所得控除額 = 6,000,000円 × 20% + 540,000円 = 1,740,000円
給与所得控除後の金額 = 6,000,000円 − 1,740,000円 = 4,260,000円
……と求めておいて何なのですが、660万以下の場合は早見表があります。
しかも、実際には4,000円単位で端数が切り捨てられたりするので、こっちの表の方が正確です。
http://www.nta.go.jp/shiraberu/ippanjoho/pamph/gensen/nencho2012/pdf/79-87.pdf
健康保険料
健康保険料、介護保険料、厚生年金保険料については、4月〜6月の収入に応じて金額が変わったり、4月と9月に金額の更新があったりとややこしく、これだけで1エントリ書けてしまうため、ここでは概算で求めてみたいと思います。
さて、まずは健康保険組合の話から。健康保険組合には、もともと国が運営していた「全国健康保険協会」通称「協会けんぽ」と、業界団体やグループ企業などが集まって運営する私設の健康保険組合、この二種類が存在します。
勤務先が参加している健康保険組合によって保険料率が異なり、協会けんぽの場合は勤務先の住所によって異なりますが9.85%〜10.16%(平成24年)、それ以外の健康保険組合の場合は協会けんぽより1〜2%程度安く設定されています。
また、大抵の保険組合では会社側と労働者側が半分ずつ払うことになっているため(労使折半)、労働者の負担額は給与の5%前後となります。
Aさんの場合(概算):
給与収入 = 6,000,000円
健康保険料率 = 9.97%(協会けんぽ、東京)、労使折半により4.985%
年間の健康保険料 = 給与収入 × 健康保険料率 = 6,000,000円 × 4.985% = 299,100円
厚生年金保険料
サラリーマンの場合は第2号被保険者という区分になるため、厚生年金保険料の支払いが発生します。
平成24年の保険料率は16.766%ですが、毎年0.354%ずつ引き上げられ、平成29年に18.3%となることが既に決定されています。
これも労使折半のため、労働者の負担額は給与の8.383%となります(平成24年の場合)
雇用保険料
4月に改定されて1.55%→1.35%になりましたが、今回は概算なので1.35%一律で計算してみます。労働者負担が0.5%、会社負担が0.85%と決められているので、労働者の負担額は給与の0.5%となります。少ないように見えますが一年分をまとめるとそれなりの額になります。
生命保険料控除
今年から税制が変わりましたが、平成23年末より前に契約した保険の場合は、旧制度のまま変更無しです。
ここでは旧制度の計算式で行こうと思います。
年間の支払保険料等 | 控除額 |
---|---|
〜25,000円 | 支払保険料等の全額 |
25,000円〜50,000円 | 支払保険料等×1/2 + 12,500円 |
50,000円〜100,000円 | 支払保険料等×1/4 + 25,000円 |
100,000円〜 | 一律50,000円 |
Aさんの場合:
月額保険料 = 6,000円
年間の保険料 = 6,000円 × 12ヶ月 = 72,000円
生命保険料控除額 = 72,000円 × 1/4 + 25,000円 = 43,000円
扶養控除
これはよく聞く控除項目だと思います。
生計を共にしている家族の中で収入が103万以下の人がいれば、一人につき38万円の控除が受けられます。
パートに出ている主婦が103万円以下に抑えようとするのは、これが理由ですね。
Aさんの場合:
専業主婦の妻:380,000円
医療費控除
医者にかかった際の費用や、入院費用、通院時の交通費、薬代などを合計して10万円を超えている場合、超えた部分が控除額となります。といっても、健康保険によって三割負担ですむため、大病しない限りはなかなか到達しません。
なお、年末調整の時点ではその年の医療費は確定していないため、翌年三月に確定申告を行うことになります。
所得税の計算
他にも控除は存在しますが、サラリーマンに影響の大きい所はだいぶ出そろったので今回はこれぐらいにしておきましょう。さて、Aさんの所得税を計算してみたいと思います。
所得税 =(収入 − 控除) × 税率
まずは収入から控除を引いて「課税対象額」を求めるところまで。
所得税率
所得税は累進課税制度になっているため、所得に応じて5%〜40%まで税率が上がる仕組みになっています。
課税対象額 | 所得税 |
---|---|
〜195万円 | 5% |
195万円〜330万円 | 10% − 97,500円 |
330万円〜695万円 | 20% − 427,500円 |
695万円〜900万円 | 23% − 636,000円 |
900万円〜1,800万円 | 33% − 1,536,000円 |
1,800万円〜 | 40% − 2,796,000円 |
195万円を超えた途端に2倍の税率になるように見えますが、実際には195万を超えた部分だけが10%の税率となるようになっています。
というわけで、Aさんの所得税は160,342円となりました。100円未満は切り捨てられるので160,300円ですね。
所得税額が分かったので、年末調整で還付される金額も求められます。
還付額 = 源泉徴収で今まで払ってきた所得税額 − 所得税額
今回の記事では健康保険料、厚生年金保険料などを概算で求めているため、多少の誤差がありますが、毎月の給与明細を元にじっくり計算すれば返ってくる金額を1円単位で当てることもできるようになります。
復興税(住民税部分)
収入に関係なく年1000円
合計すると、年収400万で年間3000円程度、年収600万で年間4500円程度の負担増となるようです。
復興税は期間が長く所得税は25年、住民税は10年に渡って負担が発生しますが、一年当たりの金額で見るとそう大きくは無いようです。
宇宙開発イベントスケジュール
世界中で打ち上げられるロケットの打ち上げ予定やISS関連のイベントを日本時間に変換して表示するサイトを作ってみました。
宇宙開発イベントスケジュール
大分前に話があって作ったんですが、ブログでは初お披露目。
思ったよりも頻繁に打ち上がっているでしょ?
中国の打ち上げは予定が載らないことも多いので、実際にはこれよりも多め。週あたり1〜2機は打ちあがってますね。
最近の打ち上げはネットでライブ中継されることが多いので、チャンスがあったら以下の中継サイトとかを見てみると面白いです。
- 定番のNASA TV ( http://www.nasa.gov/multimedia/nasatv/index.html )
- ニコニコ動画の宇宙コミュニティ放送 ( http://com.nicovideo.jp/community/co5956 )
以下、裏側でやっていること。
ruby 1.9.3 + libharu 2.1.0 + 手軽に高橋メソッドな PDF v2
高橋メソッドをやろうと思う
↓
Google Docsのプレゼンテーションはフォントサイズに限界値があることを知る
↓
変換ツール(手軽に高橋メソッドな PDF v2)を見つける
↓
結構古いので動かすのに手間取る
↓
動いた←いまここ