yoku ts.
yoku0****@gmail*****
2013年 9月 27日 (金) 19:04:07 JST
すとーさん こんばんは、yokuです。 ちなみにこれ、valgrindサポートしたmysqldだと有意な情報取れたりしますか？ # valgrind --leak-check=full bin/mysqld --datadir=./data --user=mysql ==30899== Memcheck, a memory error detector ==30899== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==30899== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==30899== Command: bin/mysqld --datadir=./data --user=mysql .. ==30899== 40 bytes in 1 blocks are possibly lost in loss record 33 of 67 ==30899== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==30899== by 0x77C481: my_malloc (my_malloc.c:38) ==30899== by 0x908D09: _lf_alloc_new (lf_alloc-pin.c:509) ==30899== by 0x909EF2: lf_hash_insert (lf_hash.c:371) ==30899== by 0x7D853D: find_or_create_file(PFS_thread*, PFS_file_class*, char const*, unsigned int) (pfs_instr.cc:966) ==30899== by 0x7E086A: get_thread_file_name_locker_v1 (pfs.cc:1313) ==30899== by 0x768673: search_default_file_with_ext (mysql_file.h:803) ==30899== by 0x76908F: search_default_file (default.c:670) ==30899== by 0x76931B: my_search_option_files (default.c:321) ==30899== by 0x7695BA: my_load_defaults (default.c:576) ==30899== by 0x57E832: mysql_install_plugin(THD*, st_mysql_lex_string const*, st_mysql_lex_string const*) (sql_plugin.cc:1800) ==30899== by 0x572AD9: mysql_execute_command(THD*) (sql_parse.cc:4365) .. ==30899== LEAK SUMMARY: ==30899== definitely lost: 0 bytes in 0 blocks ==30899== indirectly lost: 0 bytes in 0 blocks ==30899== possibly lost: 23,280 bytes in 132 blocks ==30899== still reachable: 394,470,294 bytes in 22 blocks ==30899== suppressed: 0 bytes in 0 blocks ==30899== Reachable blocks (those to which a pointer was found) are not shown. ==30899== To see them, rerun with: --leak-check=full --show-reachable=yes ==30899== ==30899== For counts of detected and suppressed errors, rerun with: -v ==30899== ERROR SUMMARY: 45 errors from 45 contexts (suppressed: 12 from 9) yoku ts. 2013年9月27日 13:00 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > In <5243D****@rozet*****> > "[groonga-dev,01823] Re: mroongaのメモリーリーク（の疑い）について" on Thu, 26 Sep 2013 16:16:36 +0900, > 磯部 和広 <k-iso****@rozet*****> wrote: > >> ＞2. /proc/${mysqldのPID}/mapsの中身（大きいです。） >> >> こちらについては大きいので、 >> >> [groonga-dev,01742] Re: 仮想メモリサイズを超えるmroongaのインデックス構 >> 築について >> >> ＞もし、データを提供していただけるようであれば、 >> ＞groon****@groon***** 宛にご連絡頂ければと思います。groonga開 >> ＞発チームに届くメールアドレスです。 >> >> こちら宛てに、gzipして添付させていただきます。 > > ありがとうございます！ > 受け取りました。 > > groongaのデータベースのために使っているメモリよりも、それ以 > 外のために動的に割り当てたメモリの方がたくさんありました。 > > % zcat maps.gz | ruby -e "ARGF.each_line {|line| range = line.split[0]; file = line.split[5]; low, high = range.split(/-/); usage = high.to_i(16) - low.to_i(16); puts %Q[#{usage}\t#{file}]}" | sort -r -n | cat -n > 1 6442438656 > 2 227237888 > 3 67108864 > ... > 435 67108864 > 436 67104768 > ... > 536 12582912 /var/lib/mysql/mysql/mroonga.data/NEW_UMI3.mrn.0000103 > 537 12582912 /var/lib/mysql/mysql/mroonga.data/NEW_UMI2.mrn.0000106 > 538 12582912 /var/lib/mysql/mysql/mroonga.data/NEW_UMI2.mrn.0000105 > 539 12582912 /var/lib/mysql/mysql/mroonga.data/NEW_UMI2.mrn.0000103 > 540 12582912 /var/lib/mysql/mysql/mroonga.data/NEW_UMI1.mrn.0000103 > ... > > なので、groongaのデータベースを扱う以外のところでなにかメモ > リを使っていることがわかります。 > >> 11GBのデータをロードして、Selectオンリーで使っていると >> 18GB強のメモリがMySQL配下の何かで浪費されています。 > > 「何か」というのをまずは切り分けたいですよねぇ。 > > mroongaのところであればmroongaを調べないといけないですし、 > mroonga以外のところであればそっちを調べないといけません。 > > うーん、MySQL管理のメモリがどのくらいあるのかがわかるといい > んですけど。。。 > > > -- > 須藤 功平 <kou****@clear*****> > 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270) > > groongaサポート: > http://groonga.org/ja/support/ > パッチ採用はじめました: > http://www.clear-code.com/recruitment/ > コミットへのコメントサービスはじめました: > http://www.clear-code.com/services/commit-comment.html > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
