浅山です。いつもお世話になります。

  全文検索の下処理としてやってます。



In message "[mysql 14893] Re: バッチ処理のUPDATEでmysqld got signal    
11が発生する  【再発】他に類似事象？有り",
Kaname Kuji(Y7)様wrote...
 >KK@IB です。
 >
 >この処理に、インデックスは不要なように見えますね。
 >DBすらいらない。シークエンシャルファイルをCOBOLで
 >バッチ処理、みたいな感じの処理ですね。
 >
 >インデックスをとったテーブルでやってみたらいかがでしょうか？
 >
 >
 >----- Original Message ----- 
 >From: ""浅山雄三"" <ALCYONE@xxxxxxxxxx>
 >To: <ml@xxxxxxxxxx>
 >Sent: Friday, June 05, 2009 12:16 PM
 >Subject: [mysql 14892] Re: バッチ処理のUPDATEでmysqld got signal 
11が発生する 
 > 【再発】他に類似事象？有り
 >
 >
 >>  浅山です。いつもお世話になります。
 >>
 >>  下記のような処理をしています。
 >>
 >> (1)Aテーブルを順に読み出し、レコード毎に全VARCHARフィールドと
TEXT
 >> フィールドの値を連結し、それをBテーブルのXフィールドにINSERT。件
数は
 >> 約20万件。
 >>
 >> (2)上記(1)を全件処理した後、BテーブルのXフィールドを順に読み出
し、
 >> Ngramデータを生成。そのデータをYフィールド（LONG TEXT属性）に
 >> UPDATE。UPDATEは1件当たり十キロバイト〜数十キロバイト。
 >>
 >>
 >>  UPDATEのSQL文は、
 >>
 >> update Bテーブル
 >> set Yフィールド = '〜〜Ngramデータ〜〜'
 >> where PRI_KEY = PRI_KEY_DATA
 >>
 >> です。
 >>
 >>  類似事象にもあるように、FULL TEXT INDEXが絡んでいるかと・・・。
 >>
 >>
 >>
 >>
 >> In message "[mysql 14891] Re: バッチ処理のUPDATEでmysqld got 
signal
 >> 11が発生する  【再発】他に類似事象？有り",
 >> Kaname Kuji(Y7)様wrote...
 >> >KK@IB です。
 >> >
 >> >実行環境の性能ももう少し知りたいところですが
 >> >補助のテーブルや処理を使って、
 >> >複数処理に分けるとか、SQLやINDEXの見直しが
 >> >貢献する状況のように感じられます。
 >> >
 >> >ロールバックが必要なのですね？
 >> >処理をexplainにかけるとどこが総なめ処理になっているかなどが
 >> >わかるかと思いますが、いかがでしょうか。
 >> >
 >> >----- Original Message ----- 
 >> >From: ""浅山雄三"" <ALCYONE@xxxxxxxxxx>
 >> >To: <ml@xxxxxxxxxx>
 >> >Sent: Friday, June 05, 2009 10:49 AM
 >> >Subject: [mysql 14890] Re: バッチ処理のUPDATEでmysqld got 
signal
 >> 11が発生する
 >> > 【再発】他に類似事象？有り
 >> >
 >> >
 >> >>  浅山です。いつもお世話になります。
 >> >>
 >> >>  その後メモリ量をどんどん減らしていっても発生してしまいます。
 >> >>
 >> >>  環境は少し違いますが類似事象を下記URLで見つけました。
 >> >> 【URL】
 >> >> http://sourceforge.jp/projects/senna/lists/archive/dev/2005-August/000117.html
 >> >> （DELETEでもUPDATEでもダメ）
 >> >>
 >> >>  上記はバージョン4.1ですがこのバグが改修されていないとか、
5.1.32
 >> で
 >> >> Bug#42634に対処したけど実はちゃんと改修されていない？というよ
う
 >> なこ
 >> >> とはないでしょうか。
 >> >>
 >> >>
 >> >>
 >> >>
 >> >> In message "[mysql 14889] Re: バッチ処理のUPDATEでmysqld got
 >> signal
 >> >> 11が発生する  【再発】",
 >> >> 浅山雄三様wrote...
 >> >> >  浅山です。いつもお世話になります。
 >> >> >
 >> >> >  一旦は解決したと思ったんですが、また発生してしまいました。
 >> >> >  メモリ使用量を減らす方向で考えていますが、それ以外に何か手
立
 >> てが
 >> >> あ
 >> >> >りましたら教えてください。
 >> >> >
 >> >> >
 >> >> >【エラー・ログ】
 >> >> >090528  6:46:26 - mysqld got signal 11 ;
 >> >> >This could be because you hit a bug. It is also possible 
that
 >> this
 >> >> >binary
 >> >> >or one of the libraries it was linked against is corrupt,
 >> >> improperly
 >> >> >built,
 >> >> >or misconfigured. This error can also be caused by
 >> malfunctioning
 >> >> >hardware.
 >> >> >We will try our best to scrape up some info that will 
hopefully
 >> >> help
 >> >> >diagnose
 >> >> >the problem, but since we have already crashed, something is
 >> >> >definitely wrong
 >> >> >and this may fail.
 >> >> >
 >> >> >key_buffer_size=536870912
 >> >> >read_buffer_size=2097152
 >> >> >max_used_connections=27
 >> >> >max_threads=200
 >> >> >threads_connected=2
 >> >> >It is possible that mysqld could use up to
 >> >> >key_buffer_size + (read_buffer_size + sort_buffer_size)
 >> >> *max_threads =
 >> >> >1344758 K
 >> >> >bytes of memory
 >> >> >Hope that's ok; if not, decrease some variables in the
 >> equation.
 >> >> >
 >> >> >thd: 0x7ec0c220
 >> >> >Attempting backtrace. You can use the following information 
to
 >> >> find
 >> >> >out
 >> >> >where mysqld died. If you see no messages after this, 
something
 >> >> went
 >> >> >terribly wrong...
 >> >> >stack_bottom = 0x804563b8 thread_stack 0x30000
 >> >> >Trying to get some variables.
 >> >> >Some pointers may be invalid and cause the dump to abort...
 >> >> >thd->query at 0x7eb7f2c0 is an invalid pointer
 >> >> >thd->thread_id=723
 >> >> >thd->killed=NOT_KILLED
 >> >> >The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html
 >> >> >contains
 >> >> >information that should help you find out what is causing 
the
 >> >> crash.
 >> >> >090528 06:46:26 mysqld_safe Number of processes running now: 
0
 >> >> >090528 06:46:26 mysqld_safe mysqld restarted
 >> >> >InnoDB: The log sequence number in ibdata files does not 
match
 >> >> >InnoDB: the log sequence number in the ib_logfiles!
 >> >> >090528  6:46:28  InnoDB: Database was not shut down 
normally!
 >> >> >InnoDB: Starting crash recovery.
 >> >> >InnoDB: Reading tablespace information from the .ibd 
files...
 >> >> >InnoDB: Restoring possible half-written data pages from the
 >> >> >doublewrite
 >> >> >InnoDB: buffer...
 >> >> >090528  6:46:29  InnoDB: Started; log sequence number 0
 >> 468460087
 >> >> >090528  6:46:29 [Note] Event Scheduler: Loaded 0 events
 >> >> >090528  6:46:29 [Note] /opac/pp/mysql/bin/bin/mysqld: ready 
for
 >> >> >connections.
 >> >> >Version: '5.1.32'  socket: '/tmp/mysql.sock'  port: 3306  
MySQL
 >> >> >Community Server (GPL)
 >> >> >
 >> >> >
 >> >> >In message "[mysql 14888] Re: バッチ処理のUPDATEでmysqld got
 >> >> signal
 >> >> >11が発生する",
 >> >> >浅山雄三様wrote...
 >> >> > >  浅山です。いつもお世話になります。
 >> >> > >
 >> >> > > >key_buffer_size=2147483648　←2GB
 >> >> > > >
 >> >> > > >このkey_buffer_sizeを1.5GBあるいは1GBくらいに減らして
 >> >> > > >見てはどうでしょう。
 >> >> > >
 >> >> > >  512MBにしてみたところ、SIGNAL11は発生しませんでした。
 >> >> > >
 >> >> > >  ということで解決しました。皆様ありがとうございました。
 >> >> > >
 >> >> > >（※バッチを何本もはしらせたので返事がおそくなってしまいま
し
 >> >> た。）
 >> >> > >
 >> >> > >
 >> >> > > 2009年5月27日 09:19:43 (^o^)浅山雄三
 >> >> > >
 >> >> > >
 >> >> > >
 >> >> > >
 >> >> > >
 >> >> >
 >> >> >
 >> >> > 2009年5月28日 12:46:16 (^o^)浅山雄三
 >> >> >
 >> >> >
 >> >> >
 >> >> >
 >> >> >
 >> >>
 >> >>
 >> >> 2009年6月5日 10:37:42 (^o^)浅山雄三
 >> >>
 >> >>
 >> >>
 >> >>
 >> >> __________  ESET NOD32 Antivirus からの情報, ウイルス定義デー
タ
 >> ベースのバージョン 4132 (20090604) __________
 >> >>
 >> >> このメッセージは ESET NOD32 Antivirus によって検査済みです。
 >> >>
 >> >> http://canon-its.jp
 >> >>
 >> >>
 >> >>
 >> >
 >> >
 >> >
 >> >
 >> >
 >>
 >>
 >> 2009年6月5日 11:57:45 (^o^)浅山雄三
 >>
 >>
 >>
 >>
 >> __________  ESET NOD32 Antivirus からの情報, ウイルス定義データ
ベースのバージョン 4132 (20090604) __________
 >>
 >> このメッセージは ESET NOD32 Antivirus によって検査済みです。
 >>
 >> http://canon-its.jp
 >>
 >>
 >> 
 >
 >
 >
 >
 >


 2009年6月5日 12:52:19 (^o^)浅山雄三