舘山 様

貫井（ぬきい）です

回答ありがとうございます。

> 必要以上に大きなメモリ設定ではなくシステムにあった設定も必要になると思い
> ます。
> MySQL自体だけでなくライブラリでのメモリリークも考えられると思うのですが
> この辺は　外部のツールで定期的にとっておくしかなさそうですね
> sysstatで残しておくとか　mrtg や　nagios / zabbix などの外部ツールで
> 視覚化しておくと解決の一つにつながる可能性もあります
>

なるほど
OSレベルでの状況確認も必要となるということですね

いろいろ、お知恵をいただきましてありがとうございます。

現状同じエラーが再発していない状況ですので、今後発生時の対策含め
監視体制の見直し等を考えていきます。

以上

(2013/11/24 17:50), 舘山 聖司 wrote:
> 舘山です
> 
> メモリは確かに　最大接続時と思うのですが、この時のメモリの消費がどうなっ
> ているかな？と思いました
> 必要以上に大きなメモリ設定ではなくシステムにあった設定も必要になると思い
> ます。
> MySQL自体だけでなくライブラリでのメモリリークも考えられると思うのですが
> この辺は　外部のツールで定期的にとっておくしかなさそうですね
> sysstatで残しておくとか　mrtg や　nagios / zabbix などの外部ツールで
> 視覚化しておくと解決の一つにつながる可能性もあります
> 
> /tmp は　他の用途で使われて足りなくなるケースもあります
> スレーブへの転送が該当時間に行われていないのならこの件は大丈夫とは思いま
> す。行レベルリプリケーションであることから大きなデータになった場合でも
> 十分な/tmpの容量が確保されているなら問題はないでしょう
> 
> 
> 予想だけでは解決につながらないので、原因追究すべきと思った際には自分なり
> にシステムの状態をつかんでおく手段も必要ということになるわけです。
> 
> もっとも　mysqlの開発陣であればmysqld の吐いたログだけで解決できるケース
> もあるでしょうけど...
> 
> (2013/11/18 22:25), Tsuyoshi Nukii wrote:
>> 舘山 様
>>
>> 貫井（ぬきい）です
>>
>> ご回答いただきましてありがとうございます。
>>
>>> １）　メモリは十分でしょうか？
>>> 　　　ログの情報では mysqldで　約18GB必要と言ってます
>>
>> この件ですが、最大接続時の計算なのかと考えていました。
>>
>> 実際その時間帯には、外部からの接続が発生していない状況であり
>> 接続数が無ければ、メモリーの消費はもっと低いのかと考えており
>> ました。
>> 接続が無い場合でも、それほどのメモリーを消費するものなので
>> しょうか？
>>
>>
>>> ２）　スレーブを行 ベースレプリケーションとのことです
>>> 　　　ので　/tmp は十分な容量がありますか？
>>
>> 約8Gの容量を設定していますので、十分だと考えております。
>>
>>
>> 以上、よろしくお願いします。
>>
>> (2013/11/16 13:14), 舘山 聖司 wrote:
>>> 舘山です
>>>
>>> 念のためです
>>>
>>> １）　メモリは十分でしょうか？
>>> 　　　ログの情報では mysqldで　約18GB必要と言ってます
>>> 　　　実際に　32GBなどのサーバでも他のプロセスなどに
>>> 　　　利用されていてぎりぎり使えないなどもありますので
>>> 　　　もしバックアップ専用などであれば　もっと
>>> 　　　key_buffer_size などを含めて小さく調整してみては
>>> 　　　どうでしょう？
>>> 　　　バックアップ専用でなければ当然パフォーマンスに
>>> 　　　影響しますのでこの辺は調整しなければならなくなる
>>> 　　　でしょう。
>>>
>>> ２）　スレーブを行 ベースレプリケーションとのことです
>>> 　　　ので　/tmp は十分な容量がありますか？
>>> 　　　RedHat などでは割と少ないパーティションになってい
>>> 　　　る可能性もあり、この変で　リプリケーションの展開に
>>> 　　　必要なサイズを使えない可能性があります
>>> 　　　リプリケーションのbinlog展開で、mysqlのデータに割
>>> 　　　り当てたディレクトリを使っていないケースがCentOS
>>> 　　　で見受けたことあるもので...
>>> 　　　ステートメントベースとちがって多くのbinlog展開に
>>> 　　　なるのでこの辺もわりと見落としてたことあります。
>>>
>>> 検証済みとは思いますが、ダンプ情報だけでこれらの情報が含まれていなかった
>>> ので発言してみました。
>>>
>>>
>>>
>>> (2013/11/13 12:23), Tsuyoshi Nukii wrote:
>>>> yoku様
>>>>
>>>> 貫井（ぬきい）です
>>>>
>>>>
>>>> ご回答いただきましてありがとうございます。
>>>>
>>>> 今回、問題となったテーブルは、InsertとUpdateのみで運用しています
>>>> ので条件が合わないように思えます。
>>>>
>>>> インデックスの項目が更新対象となっているので、このあたりでなにか
>>>> あるのですかね。
>>>>
>>>> 以上
>>>>
>>>
>>>
>>
>>
> 
> 


-- 
 株式会社 ベストリザーブ
   貫井 剛 （ぬきい つよし）

   mailto:nukii@xxxxxxxxxx
      URL:http://www.bestrsv.com
      TEL:06-6253-3800
      FAX:06-6253-3801