困った事

32.4GBの攻防戦→訂正→32.994GBの攻防戦

片桐　継（Tugu Katagiri） — Tue, 02 Dec 2008 00:21:00 GMT

それは開発用サーバーのSQLServer2005で、ちょっと前から困っていたことのお話。

問題：ディスクは50GBしかないのに、msdbが33GBもある。そのせいで、テストモジュールを最低限まで削ってもテスト動かすとすぐに残り容量100MB以下に。うーん、でいんじゃらす。

なので、ちょっと本気を出して、msdbの圧縮について、対処することにした。

まずは原因となっているだろうテーブルの洗い出し。

SELECT isnull(sum(  p.rows ),0) as RowCounts,s.name as TableName
 FROM sys.partitions p
INNER JOIN sys.objects s ON s.object_id = p.object_id
LEFT JOIN  sys.allocation_units a ON  p.partition_id = a.container_id
 WHERE p.index_id  in(0,1) and p.rows is not null and a.type = 1
 group by s.name
 order by isnull(sum(  p.rows ),0) desc

で、msdbの全テーブルの行数をテーブルごとに列挙してみると、行数が800万件超えてるテーブルを発見

問題のテーブルは　sysxmitqueue

ServiceBroker の処理キューを貯めておくところなんだけどどうやら未処理のままデータを溜め込んでいるらしい。そういや、このサーバーでBrokerのテストしたことあったなー。って、ずいぶん前だな、、つか、そのせいかorz

なので、さくっとBroker再構築

ALTER DATABASE [msdb] SET SINGLE_USER
  WITH ROLLBACK IMMEDIATE
GO

ALTER DATABASE [msdb] SET NEW_BROKER
  WITH ROLLBACK IMMEDIATE
GO

ALTER DATABASE [msdb] SET MULTI_USER
GO

で、その後、msdbを圧縮。おおっ！33GB→6MBに！

ディスクが空いた。一安心ｗ

さぁ、温泉だ！＜違っ

片桐　継（Tugu Katagiri） — Mon, 10 Nov 2008 23:58:00 GMT

今週末に迫った、東京勉強会＃２６　LT大集合！

よいこの皆はもう申し込んだかな？

んー？返事が小さいぞぉ？

そんな片桐もレッドゾーン３番目に登壇、超ブリザード級ドン引きワールドを展開するつもりだっ！

今週末は、溜池山王で片桐と握手っ！＜違っ

さて、その後は、11/29（土）、わんくま温泉ツアー！

露天風呂付き温泉別荘一棟借り切っていっちゃうぞー！

なんて、ハイテンションしてるけど、仕事はもう修羅場なのよ。

0e43333

1e3

とかいう文字列がFloat型Double型にキャストできる、なんて事実が全ての元凶……

甘く見てたよ、暗黙の型変換orz

やっちゃったらしい

片桐　継（Tugu Katagiri） — Tue, 23 Sep 2008 01:27:00 GMT

やりたかったこと

Hyper-V上のXPsp３仮想マシンでDVDを再生

やってしまったこと

全然動かないので、色々といぢり、DVD再生用ソフトからDMAを有効にして再起動してみた

その結果

Hyper-V上でOSが起動しなくなった

そしてオチ

フツーのDVD-ROM上で再生しようとしていたDVDがブルーレイだったｗ

ただいま、仮想マシン再構築中……orz

もうしません、ごめんなさい

FireFox3 炎の狐３代目

片桐　継（Tugu Katagiri） — Wed, 18 Jun 2008 00:07:00 GMT

24時間ダウンロード数ギネス挑戦！
といってたから、0:00からダウンロードできるんだと思って、今まで寝ずに待ってたorz
そうじゃないらしいので、寝ます

あ、ちなみに、日本時間では、AM:2:00　開始です。なので、6/19　AM2:00までが記録をとる時間ってことですね

ダウンロード公式ページはこっち
http://www.spreadfirefox.com/ja/worldrecord/
ここのリンクからのダウンロードでないとカウントされないんだってさ

あほえい

片桐　継（Tugu Katagiri） — Wed, 11 Jun 2008 21:47:00 GMT

「処理」って打ちたかった

でも、左手だけがビミョーに左にイッコずれてた

今は反省している

みなさま有難うございました

片桐　継（Tugu Katagiri） — Sun, 01 Jun 2008 14:10:00 GMT

訳判らんセッションを訳判らんカッコで話していた片桐です。

みなさま、雨の中、たくさんの人に来ていただき、有難うございました。

お嬢さんのダンス発表会ではネットの向こうからの弾幕有難うございました。

何か一つでも、「来て良かった」「見て良かった」があると幸いです。

そんな私は「乱暴で不快を与える存在」である己について、しばらく考えていると思います。

むー。器用じゃないもんなー。まぁしばらくセッションやる隙間ないし、大人しくしているからその点については安心してくださって良いのだけれど。

ずんちゃらっちゃ～、ずんずんずん、ずんちゃらっちゃ～

片桐　継（Tugu Katagiri） — Thu, 24 Apr 2008 23:32:00 GMT

かぜのっなかのすっばるぅ～♪

それは結合テスト終盤の、全てのモジュールを通して確認するテストでの、出来事だった

ふとテスターの手が止まり、叫んだ

「結果が、あいません！」

致命的な、バグ、だった（語尾下がり）

「結合テストをやりなおさないと」

このリーダーの一言に、場が、凍った

ひと月かけてやったテストを、やりなおすのか？
うん、まぁ、よくあるよくあ……あっちゃならんだろっ！
スケ４月いっぱいだぞ！
残り何日だと思ってんだよっ！

地獄で音楽の絶えない片桐が、手をあげて、言った

「全モジュール通しテストの途中での障害対応なら、対応後にテストをやり直せばすむんじゃね？」

方針が、決まった（語尾下がり）

そぉげんのぺがっさす～♪

壊れててごめんなさい　ｍ（＿＿）ｍ

あのね、電源がね～

片桐　継（Tugu Katagiri） — Wed, 23 Apr 2008 00:32:00 GMT

頭に毛が三本しかないんだよ～＜違っ

組み立てPCなんですが、コードつないでスイッチいれても、電源が入りません

たぶん、スイッチをつなぐコードのつなぎ方がヘンなんだと思うの

部品に白と橙のコードがある場合、どっちが「＋」？

プラスチックの先端に「▼」って書いてあるのは「＋」「－」のどっち？

PW+とPW-に、あわせて刺せばよいんだとは思うの

悩む～

マーズアタック！ MARS ATACK!

片桐　継（Tugu Katagiri） — Wed, 26 Mar 2008 00:01:00 GMT

あー、それなんて六神合体？＜違っ

今は、やまだのおろちの何が悪いねん、ギドラの何が強いねん、と模索のための調査中。引力光線でも出とんのかマヂで。トレースとってパフォーマンスログとって、いっぱいいっぱいの数字をEXCELで一覧にしつつ脳みそがコネコネしてます。そろそろグルテンが粘りそうです。

で、Ｘ星人な気分で妖星ゴラスを目の前に、片桐はここでガス抜きする（笑）、いや、させてください（おいこら）

判ったのは、おろちがまだギドラに圧勝していた頃（まちがっても木下藤吉郎ではない）、確かに接続プロセス番号（SPID）は一つだけだった。つまり単純に考えると、仕事のためにSPIDを増やして処理させることはギドラにとっては高速化の道であったのに、おろちにとっては鈍足化の道だったって事になる。まぁたぶん、色んな原因要素があるのだろうけれども、ここは単純な結果論から責めるとそうなるｗ。ギドラでは確実にできていた仕事が、おろち上においてギドラとの相対速度で処理出来なくなった理由がSPIDの増殖にあるのなら、やはりそれはMTAの大罪、SPIDを増やして処理をすることでパフォーマンスが劣化した、という結論になってしまうのだが、周りはそもそもそれを認めない（おろちが早いに決まってんだろう！　８ＣＰＵだぜ？　めもりすっげーんだぜ？　ＭＴＡなんだぜ！　並列化なんだぜ！的に）

でも、ここで疑問。

まず、最初に組んだプロトタイプは、Endxxxxシリーズを使った、ただのＡＤＯ非同期アプリだった。こいつがおっそろしく処理が早かったのがそもそもの始まり。ベストタイム７分52秒をたたき出したのはこの形式だったから。で、これに調子こいてそこから規模？が大きくなり、ちいさなプログラムがいつのまにかMTAのスレッドクラスに成長し、スレッド処理とは何ぞや的鎧クマーな世界が展開、気がつけば釣られ踊らされてしまったぷろぐらま♪ってっゆっかー♪そうゆうことで～♪こっちに戻ってきたら、他人～？みたいな～？（壊）
MTAアプリで動かすのと、ADO非同期メソッドで動かすのと何が違うのか？　恐らくはそこが今回の一つのポイントだと思ってて、これをうまく検証、切り分けられれば何かがわかる予感はしてる。でもそこまでサンプル作ってる余裕がない（＾－＾；；　でも、そんな中にあっても、実は今、（こんなこともあろうかと）そういう抜本処理方式変更対応を抜きにしてできる限りの範囲で片桐がさらに育て上げているギドラのプログラムは、初代ギドラの約1.5倍の処理速度が出ている。これは実は、

スキーマバインドビューの生成タイミングを変更
クラスタインデックスの列項目と非クラスタインデックスの付加列の見直し
サーバーのパラレルしきい値を変更

をしているだけのバージョン。サーバーオプションはカンタンにいじる事がゆるされないのでこれはまぁ忘れるとしても、ビューとインデックスの見直しだけでも効果があることがわかっているにも関わらず、実際にその処理時間もトレース情報も提示しているにも関わらず、それは「ユーザーとの仕様取り決めに無いから」と却下されており、片桐苦境。では、仕様変更についてネゴを取れるように計るのかといえば、これも却下。まぁ諸般オトナの事情ってヤツだね。先に仕様書だしちってるからｗ

ようするにだ、カンタンに言えば、おろちに新しいプログラム処理を入れる＝プログラムを置き換える＝理由が必要→ギドラがおろちより早いという事実を表に出さねばならない、という図式が目の前にあり、問題をややこしくしているというわけだ。ギドラ＞おろちの原因を突き止め、いつかのＮＵＬＬ事件を引き起こしてくれた人向けに納得できる資料を作り上げて会議を設けて説得し、はじめて、何か働きかけられるってことらしいんだな（遠い目）

なんか、ちめーてきなバグでないかなー。そしたらガサーッと入れ替えてやるんだが＜おい

てなわけで、この戦い、恐らくは長いと思う。いっそヴァルハラまで持ってくかー？　
でもそこはほら、危機迫る納期越えの記憶～♪失意にのまれ立ち尽くす狂おしき日々～♪

閑話休題

そんな中、みつけたのが、MARS。（やっとタイトルの話らしい）

MultipleActiveResultSets　というらしい

くわしくは、作った人？のブログとか
http://blogs.msdn.com/dataaccess/archive/2005/08/02/446894.aspx
いつもの橙色のページとか

むぅ、どんなかんじやろ。実装してみたら、ギドラで2分かかってた処理が２分掛からなくなってまた10秒ほど縮まりよったけれどもｗ　育て上げた新ギドラのプログラム、こいつが、やまだのおろちでどれだけのパフォーマンスをたたき出すのかは見てみたい。（本題終わり）

でも今、片桐には、おろちを直接触る権限がない（つ＿；）
ボスに許可とって作業依頼書作ってスタンプリレーしなきゃならんのよ……

-----業務連絡～

某対応のツールとして、Office2007を買っちまいました＜ぉ
所持金尽きたよ（笑）飯代がんばって倹約だよ、つか、オブ熱どーするよ、おいら（笑）
いや、何とかなるさ。金が無いなら稼げば良い（By楽俊）＜この言葉好きだｗ

でもそれよかさらなる問題は、これを動かす事のできるマシンが我が家にいるのかどうか、って事　（＾－＾；；；；
PentuimDのメモリ640MBが最良スペックなんだけど、XP乗っけて使える？
昔にソラリス評価用に分捕ってきたつぎはぎマシンで蓋もちゃんと閉まらん子なんやけど（＾＾；

-----

いぢょ、やまだのおろちvsキングギドラ、キングギドラ圧勝の現実に凌駕している現場よりお送りしました。そして片桐は密かに、カイザーギドラを育成中（おい）

あー、なんだかファイナルウォーズ見たくなってきた（笑）

PS．
ええい、中ボスはクリストファー・リーに決まっとる！　危ないときに「キター！」とお約束なのはイアン・マッケランのクマだろーが！クマ軍団率いて崖から駆け下りてくるんだよっ！！（握り拳）　などと思いながら見てしまった「黄金の羅針盤」ｗ　某ゲームの映画化だと真面目に信じた自分はオバカですｗ
それにしても洋画で描かれるオヤジ達って、んっとに良い仕事するよなぁ（笑）

キングギドラvsやまたのおろち

片桐　継（Tugu Katagiri） — Sat, 22 Mar 2008 01:56:00 GMT

両方とも、東宝……いや、んなことーはどーでもいい＜おい

さて、今回のお話は、SQLServerでのパフォーマンスの話です。

あるレコードは300万件ほどあるデータ。テーブルに入ってて、別のテーブルへと全件をINSERTします。

サーバーAはCPU２個、メモリ４Gの64bit

サーバーBはCPU８個、メモリ32Gの64Bit

さて、処理を早く終えるのはどちら？

→今現在、サーバーBはサーバーAの約５倍の時間がかかってます。

で、mxbさん、はつねさん、とっちゃんさんに相談して、色々とヒントをもらいました。ステゴサウルス胡桃の脳なりに考えたというか理解したのは、

首一本ごとに均等に酒を飲もうとしたとき、キングギドラが二つの酒ツボから酒を飲み干すのと、やまたのおろちが二つの酒ツボから酒を飲み干すのとでは、実はキングギドラの方が早く飲み干せるんじゃないのかな？ってこと

酒を飲むとき、キングギドラの待ち首は１本で、常に三本のうち二本は酒を飲める。片や、おろちの方は八本のうち二本しか酒が飲めないから、六本が待ち。確かに、トータルで同じ酒の量を飲む時、首の多いおろちの方が首一本分の飲む酒の量は少なくて済むけれど、首が飲める酒ツボを取り合ってしまって、結局は効率よく酒が飲めない

なら、どうすれば、やまたのおろちは酒を効率よく飲めるんだろう。簡単に考えれば、酒ツボを増やして、一つあたりの酒ツボの酒を減らして均してしまえば早くなると思う。じゃ、どうすれば、酒ツボを増やすことができるんだろうか。

来週はここら辺りを探っていかねばなるまい（＾－＾；；