2009年6月 5日

[mysql 14894] Re: バッチ処理のUPDATEでmysqld got signal 11が発生する 【再発】他に類似事象?有り

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

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

In message "[mysql 14893] Re: バッチ処理のUPDATEでmysqld got signal
11が発生する 【再発】他に類似事象?有り",

Kaname Kuji(Y7)様wrote...
>KK@xxxxx です。
>
>この処理に、インデックスは不要なように見えますね。
>DBすらいらない。シークエンシャルファイルをCOBOLで
>バッチ処理、みたいな感じの処理ですね。
>
>インデックスをとったテーブルでやってみたらいかがでしょうか?
>
>
>----- Original Message -----
>From: ""浅山雄三"" <ALCYONE@xxxxx>
>To: <ml@xxxxx>
>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@xxxxx です。
>> >
>> >実行環境の性能ももう少し知りたいところですが
>> >補助のテーブルや処理を使って、
>> >複数処理に分けるとか、SQLやINDEXの見直しが
>> >貢献する状況のように感じられます。
>> >
>> >ロールバックが必要なのですね?
>> >処理をexplainにかけるとどこが総なめ処理になっているかなどが
>> >わかるかと思いますが、いかがでしょうか。
>> >
>> >----- Original Message -----
>> >From: ""浅山雄三"" <ALCYONE@xxxxx>
>> >To: <ml@xxxxx>
>> >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^)浅山雄三

投稿者 xml-rpc : 2009年6月 5日 12:53
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/85612
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。