調べた事

やまたのおろちが酒を飲む～片桐的VB.NETスレッドプログラミング～その３

片桐　継（Tugu Katagiri） — Sat, 27 Dec 2008 21:27:00 GMT

やまたのおろちが酒飲んでます。あいかわらずの飲兵衛です。

その１

http://blogs.wankuma.com/esten/archive/2008/12/03/162607.aspx

ここでは、ただ首一本がガブガブ飲むだけだったんだけど、それじゃ他の首が飲ませろとうるさいので、全部の首がせーのっ！で飲めるようにして

その２

http://blogs.wankuma.com/esten/archive/2008/12/09/163043.aspx

となったわけだけれども、コメントでツッコミがあったように、これだけでは全く持って、ダメダメプログラミングなわけですｗ。はい、わざとです。

では、どうしようか？　リファクタする？

でもその前に、まだやっておかなくちゃいけないことがあるんだわ。

やまたのおろちが飲みたい酒ツボが１つだったときにどうなるかって話。

Imports System
Imports System.Threading

Module OrochMTA

    Delegate Sub DrinkingSAKE()

    '酒ツボは一つ
    Private sakeTubo As Integer

    '酒ツボの残り
    Private sakeNokori As Integer

    <MTAThread()> _
  Public Sub Main()

    '酒ツボに酒を準備
    sakeTubo = 50000
    sakeNokori = sakeTubo

    '本体で首が別々に酒飲みするのを身構える

        Dim ts As New ThreadStart(AddressOf OrochiDrinking)

        Dim workerThread As New Thread(ts)

        workerThread.SetApartmentState(ApartmentState.MTA)

        workerThread.Start()

        workerThread.Join()

        Stop

  End Sub

    Private Sub OrochiDrinking()

        'まずは首を八本で飲んでみる
        Dim headCount As Integer = 8

        '酔っ払い待ち行列を首の数だけ準備
        Dim yoppa(headCount - 1) As WaitHandle

        For i As Integer = 1 To headCount

            '飲んだ首から酔っ払いへと
            yoppa(i - 1) = HeadDrinking(i).AsyncWaitHandle

        Next

        '全部の首が酔っ払いになるまで待機
        WaitHandle.WaitAll(yoppa)

    End Sub

    Private Function HeadDrinking(ByVal headNo As Integer) As IAsyncResult

        '指定した番号の首に酒を飲ませる
        Dim myHead As New OrochiHead(headNo)

        Dim gubi As New DrinkingSAKE(AddressOf myHead.Drink)

        '酒飲み開始とともに、酔っ払い待ち行列へ戻す
        Return gubi.BeginInvoke(Nothing, Nothing)

    End Function

    'おろちの首をクラス化
Private Class OrochiHead

    Private meNumber As Integer

    '何番目の首なのかを保存
    Public Sub New(ByVal headNo As Integer)

        meNumber = headNo

    End Sub

    '酒を飲むメソッド
    Public Sub Drink()

        Dim sakeZuki As New Thread( _
          New ThreadStart(AddressOf DrinkSAKE)) ' 

        sakeZuki.Start()
        sakeZuki.Join()

          Console.WriteLine("ぷはーっ！ {0}番目の首、飲み終わり！", meNumber)

    End Sub


  ' 酒のみスレッド
  Private Sub DrinkSAKE()

        Dim totalDrunk As Integer = 0
        Dim nowDrink As Integer

        Dim oneDrink As New Random
        Dim oneBreath As New Random

        '酒ツボの中の酒を飲み干す
        While (sakeNokori > 0)

            '一回飲むたびに息継ぎ
            Thread.Sleep(oneBreath.Next(30, 60))

            '一回ぐび
            nowDrink = oneDrink.Next(1, 100)

            '全部でどれくらい飲んだ？
            sakeNokori -= nowDrink

            Console.WriteLine("{0}番目の首が {1} リットル ぐびっ : 残り {2} リットル", meNumber, nowDrink, sakeNokori)


        End While

  End Sub

End Class

End Module

ぱっと見、これだけに見えるよね？

でも、これが落とし穴。

CPUの数が多い時、スレッドはどのCPUで管理されるかはOS次第。でもそのバラバラに動いているスレッドの処理が一箇所のアドレスにある値を読み出して書き出すわけだから、「今ある酒の量が本当に正しい」かどうか判らなくなる。これが小さなスレッドと一瞬で終わるプログラムなら気がつかないかもしれない。でも、沢山のCPU、スレッドで動いたときこの落とし穴ははっきりと結果にでてくるんだよね。

つまり、一つの酒ツボから複数の首が酒を飲むわけだけど、実際に、首の動きを制御しているのは、CPU。だから、CPUが複数あると、本当の意味で「同時に」首が酒を飲むことができるわけで、そうなると、酒ツボから飲んだ→残りこんだけ、という動きも本当の意味で「同時に」起きちゃうことになるの。そうなっちゃうと、今の酒の残り、は本当に正しい！ということがこのままだといえなくなっちゃうんだ。たとえば残り１００リットルから、ある首Aが２０リットル飲んで、ある首Bが１０リットル飲んだ。この時、本当だったら残りは７０リットルのはずなんだけど、２個のCPUがあるときに、Aの「100-20」の計算を１CPU、Bの「100-10」の計算を１CPUがそれぞれに同時にしちゃったら結果は「80」もしくは「90」として格納、これ、プログラム的には正しい動作なんだもの。見えないだけで、実はやまたのおろちの首はおもいっきり絡まってて、絡まったなりに酒を飲んだツモリになってたりしてるってことだよね。

厄介なのは、これ、必ず再現できると限らないんだ。

VisualStudioのデバッガをつかってブレークポイントを仕掛けて止めただけでも、マルチスレッドプログラミングは直列の処理に最適化されてしまうので、ステップするとうまくいっちゃったりとかする。「なんで？何が悪いの？」がさっぱり判らなくなっちゃう。

おそろしいよね、それって。

だから、スレッド間でやり取りする値、読み出したり書き出したり更新したりする時には、必ずスレッド間で同期を取れるように作ってあげないといけない。

マルチスレッドが難しいのはこの考え方があるからで、実はこれを回避するための処理クラスやステートメントが、ちゃんと用意されてたりするのね。

それが、InerLockedクラス、そして、SyncLockステートメントブロック

じゃ、こいつらを使って、やまたのおろちに行儀良くお酒を飲んでもらおうと思う。ついでに、リファクタってやつもやってみるってことで、それは次回ねｗ

実はまだ出てない新キャラがいるんだ、スサノオってのがｗｗｗ

やまたのおろちが酒をのむ～片桐的VB.NETスレッドプログラミング～その１

片桐　継（Tugu Katagiri） — Wed, 03 Dec 2008 22:56:00 GMT

やまたのおろちって本体一つに八つの首があるんだって。３だとキングギドラで、４がヒュドラで、16だとミズノエリュウ、だったと思うの。で、このたくさんの首の一つ一つがドラゴンの顔になってて、口があって……。まぁ、ようするに、そんな彼らに酒を飲んでもらおうというコンセプトで、スレッドプログラミングの話をしてみようと思うんだ。

まずはシングルスレッドのお話。

まずはシンプルに、ふつーのシングルスレッド。代表の一本の首だけが飲ンベって想定で。流れとしては一本の首がごきゅごきゅと酒ツボを飲み干すっと。

Imports System.Threading

Module OrochSTA

  Public Sub Main()

    Dim hontai As New Thread( _
      New ThreadStart(AddressOf DrinkSAKE)) ' 

    hontai.Start()
    hontai.Join()

      Console.WriteLine("ぷはーっ！")

        Stop
  End Sub

  ' 酒のみスレッド
  Private Sub DrinkSAKE()

        '酒ツボの中の酒の量
        Dim totalSAKE As Integer = 1000

        Dim totalDrunk As Integer = 0
        Dim nowDrink As Integer

        Dim oneDrink As New Random
        Dim oneBreath As New Random

        '酒ツボの中の酒を飲み干す
        While (totalDrunk <= totalSAKE)

            '一回飲むたびに息継ぎ
            Thread.Sleep(oneBreath.Next(30, 60))

            '一回ぐび
            nowDrink = oneDrink.Next(1, 100)
            Console.WriteLine("{0} リットル ぐびっ", nowDrink)

            '全部でどれくらい飲んだ？
            totalDrunk += nowDrink

        End While

  End Sub

End Module

この場合、酒飲みはまだ一個の首でやってる。酒ツボも一つだけだから、さくーっとのんで終わり。で、つぎに、このおろちの首をクラス化して、その一本の首に酒を飲ませてみる。これが大事な前フリｗ。あとで首がたくさんになるからね。

Imports System.Threading

Module OrochSTA

  Public Sub Main()

    Dim myHead As New OrochiHead

        myHead.Drink()

        Stop
  End Sub

    'おろちの首をクラス化
Private Class OrochiHead

    '酒を飲むメソッド
    Public Sub Drink()

        Dim sakeZuki As New Thread( _
          New ThreadStart(AddressOf DrinkSAKE)) ' 

        sakeZuki.Start()
        sakeZuki.Join()

          Console.WriteLine("ぷはーっ！")

    End Sub


  ' 酒のみスレッド
  Private Sub DrinkSAKE()

        '酒ツボの中の酒の量
        Dim totalSAKE As Integer = 1000

        Dim totalDrunk As Integer = 0
        Dim nowDrink As Integer

        Dim oneDrink As New Random
        Dim oneBreath As New Random

        '酒ツボの中の酒を飲み干す
        While (totalDrunk <= totalSAKE)

            '一回飲むたびに息継ぎ
            Thread.Sleep(oneBreath.Next(30, 60))

            '一回ぐび
            nowDrink = oneDrink.Next(1, 100)
            Console.WriteLine("{0} リットル ぐびっ", nowDrink)

            '全部でどれくらい飲んだ？
            totalDrunk += nowDrink

        End While

  End Sub

End Class

End Module

で、首をクラス化することで、首が酒を飲む、というメソッドがラッピング。こうすると首一本のやるべきことが明確になる。そこで、飲ンベ首をデリゲートに登録して、さらに別スレッドで飲ませるように書き換えてみる。

Imports System
Imports System.Threading

Module OrochSTA

    Delegate Sub DrinkingSAKE()

  Public Sub Main()

    '本体で首が別々に酒飲みするのを身構える

        Dim ts As New ThreadStart(AddressOf OrochiDrinking)

        Dim workerThread As New Thread(ts)

        workerThread.SetApartmentState(ApartmentState.STA)

        workerThread.Start()

        workerThread.Join()

        Stop

  End Sub

    Private Sub OrochiDrinking()

        'まずは首を八本で飲んでみる
        Dim headCount As Integer = 8

        '全部の首が酒を飲み干す
        For i As Integer = 1 To headCount

            HeadDrinking(i)

        Next

    End Sub

    Private Sub HeadDrinking(ByVal headNo As Integer)

        '指定した番号の首に酒を飲ませる
        Dim myHead As New OrochiHead(headNo)

        Dim gubi As New DrinkingSAKE(AddressOf myHead.Drink)

        '酒飲み開始とともに、酔っ払い待ち行列へ戻す
        gubi.Invoke()

    End Sub

    'おろちの首をクラス化
Private Class OrochiHead

    Private meNumber As Integer

    '何番目の首なのかを保存
    Public Sub New(ByVal headNo As Integer)

        meNumber = headNo

    End Sub

    '酒を飲むメソッド
    Public Sub Drink()

        Dim sakeZuki As New Thread( _
          New ThreadStart(AddressOf DrinkSAKE)) ' 

        sakeZuki.Start()
        sakeZuki.Join()

          Console.WriteLine("ぷはーっ！ {0}番目の首、飲み終わり！", meNumber)

    End Sub


  ' 酒のみスレッド
  Private Sub DrinkSAKE()

        '酒ツボの中の酒の量
        Dim totalSAKE As Integer = 1000

        Dim totalDrunk As Integer = 0
        Dim nowDrink As Integer

        Dim oneDrink As New Random
        Dim oneBreath As New Random

        '酒ツボの中の酒を飲み干す
        While (totalDrunk <= totalSAKE)

            '一回飲むたびに息継ぎ
            Thread.Sleep(oneBreath.Next(30, 60))

            '一回ぐび
            nowDrink = oneDrink.Next(1, 100)
            Console.WriteLine("{0}番目の首が {1} リットル ぐびっ", meNumber, nowDrink)

            '全部でどれくらい飲んだ？
            totalDrunk += nowDrink

        End While

  End Sub

End Class

End Module

さて、こんなカンジで、首の一本一本が順番に酒を飲んで、順番に飲み終わり、をシングルスレッドで動いてるってことに置き換えてもこれだけの方法があったりする。でもね、飲ンベ首が増えたら、待たせるとウルサイから皆せーの！で飲んじゃいなYO！ってことで並列化させようと思うんだ。これがマルチスレッドでの動き。それはまた次にね

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） — Wed, 17 Sep 2008 13:28:00 GMT

和菓子大好きです。

玉子、とくに黄身の摂取を控えなくてはならない私にとって、ささやかに楽しむ季節の和菓子は最高の娯楽です。

これからの時期は、ススキやもみじをあしらった上菓子やおはぎが幸せな頃。
それだけに一連の平成米騒動は我慢ならないものがあります。

http://www.asahi.com/national/update/0917/TKY200809160331_10.html
ここに、事故米が流通したとされる業者の一覧がでています。
施設への給食と和菓子製造が多いことに簡単に気づくでしょう。
名前から察するに、きっと家族単位、家単位でひっそりと長く続けてきた地域の老舗なんかも含まれてるんじゃないでしょうか？

「うわ、ここで買っちゃいけない」
なんて簡単に思ってませんか？
でも、それ、ちょっとまってやってください。
この発表そのものに、違和感を感じませんか？

末端、つまり消費者に直接関係するのは確かにこれらの会社の製品であり、お店であり、施設なのでしょう。けれど、どこから、どうやって、どの経路で、事故米がここまで流れたのか。そもそも、誰から誰へこの米がどういう名称で取引されてここまできたのか、その経緯がまったくここから読み取れません。それではまるで、この一覧の上流にある卸会社、流通会社については情報隠蔽のようにも感じ取れてしまいます。私はその報道形式がとても不気味で、納得ができないのです。

個人的に思うのですけれど、この一覧にある施設の関係者、お店、製造会社の関係者、私達消費者と同様に被害者なのではないですか？
そういう疑問をもって、ちょっとだけ頑張って情報収集してみました。グーグル先生のおかげでそれなりに情報は得られるのだから確かに今は情報化社会なのかもしれない。

でも一方で、そういう努力、そういう発想や行動力を持たない人は与えられた情報だけで満足？して、ヒステリックに「ここはダメ！」「ここでは買わない！」で終わっちゃうんじゃないかなぁとふと思う（笑）
で残念な事に、そういう人が増えている昨今なワケですが（汗）

というわけで、がんばって農水省のPDFを探して、ダウンロードして、読んで、色々と情報が得られました。
大本営発表だからどこまで真実なのかは当事者じゃないからわからないけど……すくなくとも何も知らないよりはマシ。
でも探すの大変だったよ、全部の関連PDFを時系列で読まないと理解できないんだもの＜おい

最終的に、事故米の流れはツリービューにできる、と思ったのですよ。そうしたらもっとたくさんの人に簡単にわかりやすく情報を伝える事ができるのに、なぜそれを避けるのかしら……

和菓子好きとして、本当に今回の事は許せないなぁ、図にしてみようかな……って、あれ？　誰か来た？

ある図書室のお話

片桐　継（Tugu Katagiri） — Sat, 14 Jun 2008 23:47:00 GMT

その図書室は不思議な図書室です。

利用したい人はそこに本棚を作り、いろんな本を自由に置いて使うことができます。大きな分厚い本、小さな薄い本、それも自由。ただし、必ず司書さんを通して本を置いたり退けたりしなければならない、というルールが存在します。つまり、本棚を作った後は、利用者が直接触ることはできないってことです。図書室はとても固いセキュリティに護られているんですよ。

さて、そんな本棚には４つの棚があり、本の配置には厳格な決まりがあります。
本の大きさや分厚さがある一定サイズを超えていた場合、必ず一番下の棚に本を置き、それ以外は必ず上から置く、というルールです。

それでは実際に、一つ本棚を作って、司書さんに、分厚い図鑑を置く事からお願いしてみましょう。

司書さんは一番下の棚にその図鑑をおきます。大きい本ですからね。

今度は、小さな本をお願いしました。

司書さんはその本を一番上の棚に置きます。小さいですもん。

まぁそんなこんなで、何冊か色んな本を司書さんにお願いした後、使用者にはもう読まない本がでてきているでしょう。早速お願いして退けてもらいます。が、ここはあくまでも、「使わないよ宣言」にすぎません。司書さんは非効率な仕事は好まないので、すぐに本を処分しないのです。とりあえず、「使わない」ラベルを貼って、まだ本棚に置きっぱなしにしておきます。

やがて、一番上の棚がいっぱいになり、頼まれた本が入らなくなりました。司書さんは、ここではじめて「使わないラベル」が貼られた本を棚からどけて、残った一番上の棚の本を二番目の棚に移動させます。こうして、もう一度、上の棚で本を並べて仕事を続けます。

繰り返して、また上の棚がいっぱいになりました。司書さんは二番目の棚で「使わないラベル」の本をどけてさらに一つ下の棚に置き、一番目の棚で「使わないラベル」になった本をどけてその開いた二番目に入れ、一番上の棚を空けます。

さらに、また上の棚がいっぱいになりました。司書さんは三番目の棚の「使わないラベル」の本をどけて間をつめ、二番目の棚の「使わないラベル」の本をそこへ移し、入りきらないものを二番目に残します。そこへ一番上の棚の「使わないラベル」の本をどけた残りの本を移し、さらに上の棚を使えるようにしようとします。

……でも、さらに本が来たら……

司書さんは「これ以上仕事はできません」と返事をし、一切の仕事を拒否します。一度本棚を撤去して、再度本棚を作り直すことから始めましょう。

本棚＝プロセスメモリ空間
一番目の棚＝GC　ジェネレーション0
二番目の棚＝GC　ジェネレーション1
三番目の棚＝GC　ジェネレーション2
四番目の棚＝ラージオブジェクトヒープ
司書さんの仕事＝.NetFramework のガベージコレクタ制御
本＝プログラムで使用するオブジェクトメモリ

はい、簡単で超大雑把なGCのお話でした（＾＾；

Hyper-V が　RC1　になってまふ

片桐　継（Tugu Katagiri） — Wed, 21 May 2008 23:58:00 GMT

ダウンロードは以下で

http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=7edaa89f-9f64-488d-93c0-858d2d8799df

といっても、日本語対応となるのはもうちょっと後？

今年の夏にむけて順調に？近づいてきてる感じです。それよか、LinuxIntegrationKitが早く正式公開しないかなー。試したくてウズウズなんですけど（笑）

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

片桐　継（Tugu Katagiri） — Thu, 10 Apr 2008 20:04:00 GMT

その発端
http://blogs.wankuma.com/esten/archive/2008/03/22/129035.aspx

FinalWars その１
http://blogs.wankuma.com/esten/archive/2008/04/09/132463.aspx

オブジェクトのブロッキングで絡まってしまったおろちの首。絡まらないで仕事をさせるには、ロックをはずせば良い。そう考えた胡桃の脳な私は、ちょこっと細工をした。

「インデックスの行ロック」「インデックスのページロック」

チェックボックスをOFF。インデックスを再構築して、再び、おろちで仕事。

でも、止まる。おんなじところで「ScanStart/End」。いや、こんどの場合は

利用状況の画面に「X」がさらに倍にどばーーっ！

最悪やん！

なんでやねーーんっ！

しかもトランザクションロックが動いて、ブロッキングも頻繁してえらいことに。で、このロック、運悪くTransactionScopeの中、はい、DTSががーーーーーっつり掴んでます。強制終了なんて効きやしねぇ。あー、もう、ど・う・に・も・とまらない～（号泣）SQLServer強制再起動（恐）
周りに謝りまくり、始末書もどき書き、ごめんなさい会議までやっちゃう羽目に（大汗）これで一日丸つぶれ（はぁと）

というわけで、これはやっちゃいけないことだったんだね。うん、反省。ちょっと色々といぢりすぎた。

で、気持ちを切り替えて、

別の方面からのアプローチ。問題のSQLの実行プランをだしてみた。実行プランは出てくる。「なーんだ、ちゃんと解析できてるやん」とホッとしたのもつかの間、ふと、比べていて気がついた。おろちとギドラ、同じレコード同じテーブル同じ件数同じデータでありながら、実行プランが微妙に違う。

ギドラはテーブル副問い合わせにはクラスタインデックスを使用せず、おろちはそこにクラスタインデックス。両方とも内部パラレル処理なのは同じなんだけど……

何で違うん？

ギドラとおろちはテーブル構成も一緒、作りも一緒。違うのはCPUの数、メモリの量。それに……それに、実行回数（爆死）で、はたと考えた。テスト機のギドラはそりゃもう、とんでもない回数をこなしてきた百戦錬磨の練りこまれた統計情報を持っている。一方おろちは、必要な時に必要な回数だけをピンポイントに実行してきた、いわば世間知らずな深窓のおぜうさまｗ

まさか、まさかぁ、ねぇ？　なんて思いながら、蓋を開けてみた。

　統　計　情　報　それはパンドラの箱ｗ

うそぉぉん。全然違う、チャウチャウチャウチャウ！ちゃいすぎぢゃっ！　回数をこなしたギドラがこのSQLを実行するときに選択する最適なプラン、クラスタインデックスを外のDで使い内側のSではあえて別のインデックス（まぁちょっと似てるようなやつなんだけど、スキーマバインディングしていたビューのクラスタインデックスｗ）を使っていた理由はそこかぁ！（意義ありぃっ！びしぃっ！画面が揺れるっってくらいの衝撃ｗ）。恐らくはテストで張ったりはずしたりしたインデックスの情報さえも残すのかナンなのか、ギドラはすでにロックをうまくすりぬける方法をマスターしていてそれを駆使して仕事をする荒業をやってのけていた。さすがギドラだぜ！空間移動で光りながら現れてピロピロピロだぜ（昭和）！地球守護聖獣千年龍王だぜ（平成）！引力光線吐きまくって空飛ぶぜ（共通ｗ）！

さらに、その観点から再度両方のProfilerログを見直して、ふと、気づいた。ブロッキングが頻発していたおろちの自動統計情報更新処理はトランザクションロックタイムアウトでことごとくダウンして中断。バックグラウンド処理のために、誰にも注意を払われていなかったのだけれど、これがジワジワと効いていて、気がつけば必要な情報がろくに揃ってない状態になっていたらしい。そんな中で、それでも首はある限りの情報で仕事を計画し、働こうとして、でもやっぱり首が絡まって……かわいそう、なんてかわいそうなんだ！やまだのおろち！

ひととおり同情したら、基本に立ち返ろう。

問題のSQLにある外SQLのDと副問いSQLのS、ギドラがやろうとしたように異なるインデックスで実行すれば、おろちでも早くなれるはず。確かにSQLServerは与えられているリソースの中で最適な方法で処理をしようとプランをつくるけど、しょせんはロジック、機械、AIじゃない。人間がなんとかしようとしなければ、結局はハコの中で動作する０と１の電気信号にすぎないと思うの。そこをキチンと把握して、うまく仕事ができるようにしてやらないとイカンのではない？

というわけで

UPDATE D SET D.ID = S.ID FROM HOGE1 D , (SELECT　A1,A2,A3, ROW_NUMBER over (Order by A1 ) as ID FROM HOGE1 WHERE A4 is null ) S WHERE D.A1 = S.A1 AND D.A2 = S.A2 AND D.A3 = S.A3

HOGE1テーブル用に、クラスタインデックス（A1,A2,A3）とは別に、A1とA4の非クラスタ（付加列A2,A3）を追加。そして最重要？おろちのメンテ。DBCC　CHECKDBと統計情報更新とインデックス再構築を手動で実行！ついでにSQLServerも再起動！で、まっさら？なギドラとおろち、再び、ゴング！

ギドラで実行→５分４２秒、うん、なんか、心持ち早い（笑）
おろちで実行→１分５３秒、うおー！すげーーーっ！はええぇぇっっ！

というわけで、おろち、復活。つか、前より早くなってねぇかい？

あらためて、ProFilerとパフォーマンスモニターでチェックしてみたところ、新しいインデックスが参戦したことで統計情報が一新されたらしくHOGE1の処理をしていた他のSQLまでもが高速化（笑）統計情報更新もロックタイムアウトすることなく全ての処理を美しく完了。ブラボー♪それってなんて素敵だし爽やかなチューニング！！（自画自賛！）

つまりはだ、おろちでは

副問い合わせと本体が同一テーブルのUPDATEを行おうとしたときに統計情報の不足から同一のテーブルしかも同一のインデックスを使って処理を行うプランが作成され、それを実行しようとして自分で自分の使いたいリソースをロックして自分で自分をロック解除待ちにしてしまい、それによってその接続プールのトランザクションがロック状態。マルチスレッド上の別のSQL実行もそのトランザクション処理を待ってしまうために統計情報自動更新の処理さえもトランザクションタイムアウトを発生して全体が鈍足化してしまっていた。CPUとメモリが豊富なマシンでは同時に走る事のできるスレッドの数もふえるため、少ないマシンに比べてロック待ちとなる処理も増える。

ということだったんだな。おろち、てめぇ、らめぇ（笑）

やらなくちゃいけなかったこと

同一テーブルへの処理であっても、副問い合わせを使うということは別テーブルをメモリというか一時テーブルに展開するのと同意。なので、本体処理と別のインデックスを提供もしくはスキーマバインドビューをつかって競合を避けさせる必要がある。その処理が複数CPUによるパラレル処理を実行プランに持つ場合、自身のリソース同士のブロッキングを引き起こしやすい状況になることも考慮すること。そして、サーバーでの統計情報更新、インデックスの再構築、データベースファイルおよびトランザクションログファイルの適切なメンテナンスはデータベースサイズが大きくなり、かつ使用するCPUとメモリが多いほど不可欠な作業、怠ると劣化鈍足化の原因になる。

小回りなギドラにくらべ、おろちはずっと手のかかる構ってチャンだったわけだね。だからこそ、きちんと手をかけてやればそれだけの働きもするってことで（笑）
まぁ、これで、おろちはギドラに勝った……んだけどさ。おろちの追加インデックス作成の申請を通せるのかどうかは、大人の事情だな。でもね、一つ、すごいこと。この実行テストの後に追加したインデックスを削除したとしても、それ以降ロックを起こした実行プランを使うことは全く起きなかった、どころか、回数を重ねれば重ねるほど高速化して、最後には1分10秒台に。ギドラで57分掛かっていたデータ処理も最終的には16分で処理するところまでやりきれた。なんだかもう、カイザーギドラおろちモードってカンジだったね、ラストは（謎）プランキャッシュとリコンパイルを徹底的に意識したSQL文を作って処理させたというのはあるにせよ、それにしても統計情報の蓄積とプランキャッシュの有効活用によって起きる効果ってのはホント絶大なんやねぇ。それゆえに、うまくいかないとボロボロにもなるわけだがｗ　うん、良い経験をした、ってことにしておこう（笑）

今回、読みまくって、脳みそを胡桃味噌に発酵させてくれたモノたち

Microsoft SQL Server 2005 のクエリオプティマイザが使用する統計情報
http://www.microsoft.com/japan/technet/prodtechnol/sql/2005/qrystats.mspx

SQL Server 2005 のバッチのコンパイル、再コンパイル、およびプランのキャッシュに関する問題
http://www.microsoft.com/japan/technet/prodtechnol/sql/2005/recomp.mspx

ぷらす、SQLServer2005 Books Online & TechNet & MSDN あちこち

以下、海の向こうのサイト（おい）

よく出入りしている、SQLServerPeformance.com の記事から、

統計情報更新について
http://www.sql-server-performance.com/tips/update_statistics_p1.aspx

インデックスを作って使う時のツボ系ｗ
http://www.sql-server-performance.com/tips/index_main.aspx

パフォーマンスチューニングのツボ。とりあえずひととおりｗ
http://www.sql-server-performance.com/tips/performance_main.aspx

後、ここいらの本。めっちゃ勉強になった良書。SQLServerいぢるなら読んどいて損はないです。でも日本語版ないよね……翻訳してみたいくらいなんだけど（笑）

Inside Microsoft SQL Server 2005: Query Tuning and Optimization
http://www.amazon.co.jp/Inside-Microsoft-SQL-Server-2005/dp/0735621969/ref=sr_1_1?ie=UTF8&s=english-books&qid=1207789032&sr=1-1

Inside Microsoft SQL Server 2005: T-sql Querying
http://www.amazon.co.jp/Inside-Microsoft-SQL-Server-2005/dp/0735623139/ref=pd_sim_fb_img_1

いぢょ♪

やまだのおろちvsキングギドラ　FinalWars その１

片桐　継（Tugu Katagiri） — Wed, 09 Apr 2008 21:45:00 GMT

やまだのおろちのスペック
　CPU８個
　メモリ32G

キングギドラのスペック
　CPU２個
　メモリ４G

それ以外は全部一緒。OSも設定もほとんど一緒。まぁ本番擬似サーバーと開発サーバーだから、似ててないと困るんだけど、色々と。
そもそもの話、キングギドラで６分の処理が、おろちで30分近くかかること、から全ての話は始まった。

SQLServer2005でのモニター

使うもの。
　パフォーマンスモニタ
　SQLServer2005 ProFiler　と　利用状況画面

おろちとギドラのそれぞれで、同じログ情報を取得します。

　パフォーマンスモニタで監視するもの

Memory\Available MBytes
Memory\Cache Faults/sec
Memory\Page Reads/sec
Memory\Pages/sec
Memory\Pool Nonpaged Bytes
PhysicalDisk(_Total)\Avg. Disk Queue Length
PhysicalDisk(_Total)\Avg. Disk Read Queue Length
PhysicalDisk(_Total)\Avg. Disk sec/Read
PhysicalDisk(_Total)\Avg. Disk sec/Transfer
PhysicalDisk(_Total)\Avg. Disk Write Queue Length
Process(_Total)\Private Bytes
Process(_Total)\Working Set
Processor(_Total)\% Privileged Time
Processor(_Total)\% Processor Time
Server\Pool Nonpaged Peak
Server\Pool Paged Failures
System\Context Switches/sec
System\Processor Queue Length

　SQLServer2005　ProFilerで監視するもの

SQL:StmtStart/Completed
SQL:BatchStart/Completed
SP:StmtStart/Completed
Data File Auto Grow/Shrink
Log File Auto Grow/Shrink
Lock:Cancel/Deadlock/Timeout
Degree of Parallelism
Server Memory Change
Scan Started/Stoped

　まぁ、こんなもん。で、実際にとってみたわけですよ。
　ちなみに、SQLServerでのSQL構文実行プロセスは

●SQLServerのSQL実行動作

　SQL構文の解析
　コンパイル有無の判断
　実行プランの策定
　SQL構文実行
　取得結果展開

おおざっぱにこんなカンジ。なんで、これらの動きの時に、メモリやCPUがどう動き、接続プールがどうなっていてSQLServer内部で何が起きているのかをとりあえず記録にとるってことからとりあえず。

で、実際にギドラとおろちで動かした結果。やっぱおろち、遅い、つか、んんん？止まってないか？こいつ？

　SQLServerには利用状況を表示できる画面があるのだけれど、そこには、この問題のSQLを実行しようとしているプロセスがいる。こいつが延々とRunnableとSuspendを繰り返していたのだけれど、ProfilerにはそのSQLのSQLｓｔｍｔSTARTが表示されていない。さらにProFiler画面をよく見てみると、ScanStarted/Stopedを延々と繰り返していて無限ループっぽい動き。んでもって、もつっと利用状況画面から問題のプロセスをあけてみると、件のプロセスではSch-SとXがどばーーっ！
つまり、確かにSch-S（SchemaScan）してるんだよね。ProFilerの動きとあってる。SQLServerにしてみたら、実行プラン作るために必要な情報をScanしてんのにうまく情報を取れなくて、諦めないでひたすら仕事。探し物はナンですか～♪と見てみると、微妙にロック要求（Ｘ）が出てる、そのオブジェクト。つまり、自分で自分にロックして自分で自分を探してる、それなんて自虐？。クラスタインデックスオブジェクトでガッツリロック掛かってんじゃん、インデックスよめねーよ！おろちの首、絡まってます～（笑）。そのせいで恐ろしく時間がかかっていたわけだね。その他はまぁらくちん♪ってカンジで動いてくれてたのに。

　で、その止まっているSQL

UPDATE D SET D.ID = S.ID FROM HOGE1 D , (SELECT　A1,A2,A3, ROW_NUMBER over (Order by A1 ) as ID FROM HOGE1 WHERE A4 is null ) S WHERE D.A1 = S.A1 AND D.A2 = S.A2 AND D.A3 = S.A3

みたいな、自テーブルのある条件で連番したレコードの番号で自テーブルのIDをセットする、みたいな自虐なUPDATESQLだったのさ。該当レコードは数万ってとこかな。クラスタインデックスはA1,A2,A3。うん、勘の良い人っつか、某パパさんとかにはこの辺りでもうすでにネタばれだと思うんだ。

でもね、当時の私はここで、んじゃ、このオブジェクトロックはずせば良いんじゃね？としか考えなかったわけ（笑）＜単純な胡桃脳ｗ

　ああ、地獄のはじまりだったさ（笑）

やまだのおろちvsキングギドラ　FinalWars予告編

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

えーっと、つまりですね……いちおの解決はしました。

キーワードは、「インデックス」そして「トランザクション」

詳しく書くと時間かかるので、きっちりまとめてからアップしようかと思っています。

にしても、深いわ～、.NetFrameworkのプログラミングって……（遠い目）

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