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

  下記のような処理をしています。

(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^)浅山雄三