1016 Can't open file: 'zen_sessions.MYI' (errno: 145)

古いバージョンのZen Cartについて不具合が見つかった場合はこちらで情報を共有してください。
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/14 16:25

うむむ。。。
エラーログ確認してみましたが、File does not existと再起動時のcaught SIGTERM, shutting downなどしか見つかりませんね縲鰀 :cry:
ちなみにFile does not existのほとんどは_vti_bin/owssvr.dllとMSOffice/cltreq.aspがないよって言ってます。
アバター
志田
記事: 526
登録日時: 2005/5/15 14:14
お住まい: 東京都
連絡を取る:

投稿記事by 志田 » 2006/2/14 17:09

/var/log/messagesなどを見てますか?

MySQLのエラーログがどこかにありませんか?
アークウェブ http:/www.ark-web.jp
きものリメイク comachi http://comachi-kimono.jp
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/14 17:57

/var/log/messagesはFTP ログ ファイルで確認しましたが、問題はなさそうです。
先ほど確認したのはWeb ログになります。

そこでサーバー会社にmysqlのエラーログのありかを聞き、telnet接続でlessコマンドで確認してみました。ながっ!!かなりの量が・・・
昨日、落ちたときのログを見ますと
060213 20:30:07 mysqld restarted
060213 20:30:08 InnoDB: Started; log sequence number 0 43744
/usr/local/libexec/mysqld: ready for connections.
Version: '4.1.11' socket: '/tmp/mysql.sock' port: ●●●● FreeBSD port: mysql-se
rver-4.1.11_1
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=8388600
read_buffer_size=131072
max_used_connections=6
max_connections=200
threads_connected=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443390
K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

pure virtual method called
Fatal signal 6 while backtracing
060214 08:59:08 mysqld started
060214 8:59:09 InnoDB: Started; log sequence number 0 43744
/usr/local/libexec/mysqld: ready for connections.
Version: '4.1.11' socket: '/tmp/mysql.sock' port: ●●●● FreeBSD port: mysql-se
rver-4.1.11_1
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=8388600
read_buffer_size=131072
max_used_connections=9
max_connections=200
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443390
K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

060214 09:53:02 mysqld restarted

そのときの状況です。昨日の夜8:30頃に再起動され、落ち、その後私が朝8:59頃まで動いていなかった模様です。その後も9:53に再起動がおきの繰り返しです。
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

投稿記事by kino » 2006/2/14 18:00

木下です。

kimono さんが書きました:key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=9
max_connections=200
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443390
K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.


この計算成り立ってる?
-----
木下 敏夫
http://www.tktools.jp/

大阪府産業デザインセンターデザイン専門員 ( http://bmb.oidc.jp/index.php?topic=-m-D14 )
奥様ショップ 店長 ( http://okusama-shop.com/ )
電脳ドロップシッピング 店長 ( http://d-064.d-shipping.net/ )
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

投稿記事by kino » 2006/2/14 18:18

木下です。

kimono さんが書きました:key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=9
max_connections=200
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443390
K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.


http://dev.mysql.com/doc/refman/4.1/ja/ ... ables.html
key_buffer_size インデックスブロックはバッファされ、すべてのスレッドによって共有される。key_buffer_size は、インデックスブロック用に使用されるバッファのサイズである。

インデックス処理(すべての読み取りと複数書き込み)のパフォーマンスを向上させるため、この値は可能な限り大きくする。主に MySQL を実行する 256M マシンでは、64M が一般的である。ただし、これを大きくしすぎると(たとえば、メモリ合計の 50% 以上など)、システムがページングを開始し、処理速度が非常に遅くなる可能性がある。MySQL ではデータ読み取りをキャッシュしないため、OS ファイルシステムのキャッシュ用に領域を確保しておくことが必要である。

と書かれてるから key_buffer_size はまだ1桁ぐらい上げられそうです。

例えば

key_buffer_size = 43M
その上で
(443M - 43M) / 200 (max_connections) => 2MB
なので
read_buffer_size=1048576
sort_buffer_size=1048576

としても計算は成り立ちそうですね。

max_connections を 100 ぐらいまで下げて
その分
key_buffer_size = 43M
read_buffer_size=2097152
sort_buffer_size=2097152

もしくは
key_buffer_size = 243M
read_buffer_size=1048576
sort_buffer_size=1048576

とするのも良いのかも
-----
木下 敏夫
http://www.tktools.jp/

大阪府産業デザインセンターデザイン専門員 ( http://bmb.oidc.jp/index.php?topic=-m-D14 )
奥様ショップ 店長 ( http://okusama-shop.com/ )
電脳ドロップシッピング 店長 ( http://d-064.d-shipping.net/ )
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/14 18:26

えっとここに足りない数字はsort_buffer_sizeですね。
こちらはまだ変更していないので、2097144です。
ということは、
8388600 + (131072 + 2097144)*200 = 454,031,800なので
=443390Kにはならないですね。なんとなく文章を読みますと、多い場合はいくつかの変数を減少させてくださいというような感じだと思いますので、例えば、max_connectionsなどを元の100に減少させるというのでしょうかね?

ということで100に減らして、mysqlの再起動してみました。
これでどうなのでしょうか?ちょっと様子見でしょうか?
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/14 18:30

その後の

コード: 全て選択

<?php
echo nl2br(`top -n 1`);
?>

の状況です。
last pid: 78019; load averages: 0.00, 0.01, 0.03 up 155+16:01:09 18:28:47
39 processes: 1 running, 38 sleeping

Mem: 1521M Active, 184M Inact, 233M Wired, 68M Cache, 199M Buf, 5968K Free
Swap: 4096M Total, 2122M Used, 1974M Free, 51% Inuse


PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
78019 www 34 0 1424K 784K CPU0 0 0:00 1.00% 0.05% top
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/15 09:52

おはようございます。kimonoです。昨日の夜また数回落ちてたみたいですが、pconnectのサイトがテストで一つしか変えていなかったため、先ほど全てを変更し、query cache sizeも33554432に変更してみました。朝の2時過ぎからはアクセス数が少なかったためか、落ちてなく、なんともいえない状態ですが、もう少し様子を見てみようと思います :)
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/16 09:37

おはようございます。kimonoです :)
一応、昨日変える前にquery cache sizeを67,108,864にしてから帰ったのですが、、、また会社に来て見ましたら、mysqlが落ちたまま復帰してない状態でした :cry:
これは。。。何か別の問題でしょうか?sqlもやはり頻繁に落ちている模様ですし、厳しいなぁ・・・
アバター
志田
記事: 526
登録日時: 2005/5/15 14:14
お住まい: 東京都
連絡を取る:

投稿記事by 志田 » 2006/2/16 12:12

実はディスク容量が足りない、とかそういうことはないですか?
アークウェブ http:/www.ark-web.jp

きものリメイク comachi http://comachi-kimono.jp
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/16 12:31

本当に親身に考えていただき、いつも大変有難うございますm(__)m
ディスク容量は総容量が15750 MBに対し、1205.46 MB の利用です。
また、SQLに関してはデータが15.1 MB に、インデックス数が 3.6 MB で合計18.7 MB です。
せっかくなので、サーバー変数と設定値も公開してみます。
変数 セッション値 グローバル値
back log 50 50
basedir /usr/local/ /usr/local/
bdb cache size 8388600 8388600
bdb home /var/db/mysql/ /var/db/mysql/
bdb log buffer size 32768 32768
bdb logdir
bdb max lock 10000 10000
bdb shared data OFF OFF
bdb tmpdir /var/tmp/ /var/tmp/
binlog cache size 32768 32768
bulk insert buffer size 8388608 8388608
character set client utf8 latin1
character set connection utf8 latin1
character set database latin1 latin1
character set results utf8 latin1
character set server latin1 latin1
character set system utf8 utf8
character sets dir /usr/local/share/mysql/charsets/ /usr/local/share/mysql/charsets/
collation connection utf8_general_ci latin1_swedish_ci
collation database latin1_swedish_ci latin1_swedish_ci
collation server latin1_swedish_ci latin1_swedish_ci
concurrent insert ON ON
connect timeout 5 5
datadir /var/db/mysql/ /var/db/mysql/
date format %Y-%m-%d %Y-%m-%d
datetime format %Y-%m-%d %H:%i:%s %Y-%m-%d %H:%i:%s
default week format 0 0
delay key write ON ON
delayed insert limit 100 100
delayed insert timeout 300 300
delayed queue size 1000 1000
expire logs days 0 0
flush OFF OFF
flush time 0 0
ft boolean syntax + -><()~*:""&| + -><()~*:""&|
ft max word len 84 84
ft min word len 4 4
ft query expansion limit 20 20
ft stopword file (built-in) (built-in)
group concat max len 1024 1024
have archive NO NO
have bdb YES YES
have blackhole engine NO NO
have compress YES YES
have crypt YES YES
have csv NO NO
have example engine NO NO
have geometry YES YES
have innodb YES YES
have isam NO NO
have ndbcluster NO NO
have openssl YES YES
have query cache YES YES
have raid NO NO
have rtree keys YES YES
have symlink NO NO
init connect
init file
init slave
innodb additional mem pool size 1048576 1048576
innodb autoextend increment 8 8
innodb buffer pool awe mem mb 0 0
innodb buffer pool size 8388608 8388608
innodb data file path ibdata1:10M:autoextend ibdata1:10M:autoextend
innodb data home dir
innodb fast shutdown ON ON
innodb file io threads 4 4
innodb file per table OFF OFF
innodb flush log at trx commit 1 1
innodb flush method
innodb force recovery 0 0
innodb lock wait timeout 50 50
innodb locks unsafe for binlog OFF OFF
innodb log arch dir
innodb log archive OFF OFF
innodb log buffer size 1048576 1048576
innodb log file size 5242880 5242880
innodb log files in group 2 2
innodb log group home dir ./ ./
innodb max dirty pages pct 90 90
innodb max purge lag 0 0
innodb mirrored log groups 1 1
innodb open files 300 300
innodb table locks ON ON
innodb thread concurrency 8 8
interactive timeout 28800 28800
join buffer size 131072 131072
key buffer size 8388600 8388600
key cache age threshold 300 300
key cache block size 1024 1024
key cache division limit 100 100
language /usr/local/share/mysql/english/ /usr/local/share/mysql/english/
large files support ON ON
license GPL GPL
local infile ON ON
log OFF OFF
log bin OFF OFF
log error
log slave updates OFF OFF
log slow queries OFF OFF
log update OFF OFF
log warnings 1 1
long query time 10 10
low priority updates OFF OFF
lower case file system OFF OFF
lower case table names 0 0
max allowed packet 1048576 1048576
max binlog cache size 4294967295 4294967295
max binlog size 1073741824 1073741824
max connect errors 10 10
max connections 100 100
max delayed threads 20 20
max error count 64 64
max heap table size 16777216 16777216
max insert delayed threads 20 20
max join size 4294967295 4294967295
max length for sort data 1024 1024
max relay log size 0 0
max seeks for key 4294967295 4294967295
max sort length 1024 1024
max tmp tables 32 32
max user connections 0 0
max write lock count 4294967295 4294967295
myisam data pointer size 4 4
myisam max extra sort file size 2147483648 2147483648
myisam max sort file size 2147483647 2147483647
myisam recover options OFF OFF
myisam repair threads 1 1
myisam sort buffer size 8388608 8388608
net buffer length 16384 16384
net read timeout 30 30
net retry count 1000000 1000000
net write timeout 60 60
new OFF OFF
old passwords ON ON
open files limit 4000 4000
pid file /var/db/mysql/obitastar.co.jp.pid /var/db/mysql/obitastar.co.jp.pid
port 3306 3306
preload buffer size 32768 32768
protocol version 10 10
query alloc block size 8192 8192
query cache limit 67108864 67108864
query cache min res unit 4096 4096
query cache size 67108864 67108864
query cache type ON ON
query cache wlock invalidate OFF OFF
query prealloc size 8192 8192
range alloc block size 2048 2048
read buffer size 131072 131072
read only OFF OFF
read rnd buffer size 262144 262144
relay log purge ON ON
relay log space limit 0 0
rpl recovery rank 0 0
secure auth OFF OFF
server id 0 0
skip external locking ON ON
skip networking OFF OFF
skip show database OFF OFF
slave net timeout 3600 3600
slave transaction retries 0 0
slow launch time 2 2
socket /tmp/mysql.sock /tmp/mysql.sock
sort buffer size 2097144 2097144
sql mode
storage engine MyISAM MyISAM
sql notes OFF OFF
sql warnings OFF OFF
sync binlog 0 0
sync replication 0 0
sync replication slave id 0 0
sync replication timeout 0 0
sync frm ON ON
system time zone JST JST
table cache 64 64
table type MyISAM MyISAM
thread cache size 0 0
thread stack 196608 196608
time format %H:%i:%s %H:%i:%s
time zone SYSTEM SYSTEM
tmp table size 33554432 33554432
tmpdir
transaction alloc block size 8192 8192
transaction prealloc size 4096 4096
tx isolation REPEATABLE-READ REPEATABLE-READ
version 4.1.11 4.1.11
version bdb Sleepycat Software: Berkeley DB 4.1.24: (April 1, 2005) Sleepycat Software: Berkeley DB 4.1.24: (April 1, 2005)
version comment FreeBSD port: mysql-server-4.1.11_1 FreeBSD port: mysql-server-4.1.11_1
version compile machine i386 i386
version compile os portbld-freebsd4.7 portbld-freebsd4.7
wait timeout 28800 28800
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

投稿記事by kino » 2006/2/16 13:18

木下です。

kimono さんが書きました:おはようございます。kimonoです :)
一応、昨日変える前にquery cache sizeを67,108,864にしてから帰ったのですが、、、また会社に来て見ましたら、mysqlが落ちたまま復帰してない状態でした :cry:
これは。。。何か別の問題でしょうか?sqlもやはり頻繁に落ちている模様ですし、厳しいなぁ・・・


外出中なので概略だけ。

ここ数日本業の方でもMySQLのチューニングをやってたので
その経験から。
まず、 my.cnf を見直しましょう。
メモリーが1.5GBあるので
    my_huge.cfg
が参考になるはず。
    locate my_huge.cfg
で保存されている場所を探して内容を比較してみてください。

それと DBは MyISAM ではなく InnoDB を
使われているようなので通常コメントになっている
先頭に InnoDB と付いている行も有効にする必要があるはず。

それと telnet 若しくは ssh でサーバーに入って作業できるのであれば
top
で状況を確認しながら管理画面の作業等を行ってみてください。
CPUの稼働率が可也多くなってませんか?

こちらでは(ZenCartではないけど)
結果のレコード数が多いサブクエリーを含むSELECTを実行させると
CPU1個だと100%になって他の作業ができなくなることがありました。

複数のCPUをつんでいる場合は50%とかになってもう一方のCPUが
他の作業を行っいサーバーとしては問題なく動作しているように見え
るかもしれないけど実際にはCPUが延々と作業をしていて待たされて
いるのかも知れない。
MySQL 若しくは httpd を再起動した直後の稼働率と管理作業等
を行っているときの稼働率でなにか違いが判るかも。

それ以外には・・・
phpMyAdmin の 「MySQLの状況」 (だったかな?)
のページで赤色で示されている項目は有りませんか?
そこに書かれている説明が可也役に立つと思います。
-----
木下 敏夫
http://www.tktools.jp/

大阪府産業デザインセンターデザイン専門員 ( http://bmb.oidc.jp/index.php?topic=-m-D14 )
奥様ショップ 店長 ( http://okusama-shop.com/ )
電脳ドロップシッピング 店長 ( http://d-064.d-shipping.net/ )
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/16 16:06

すいません。わざわざ教えていただいたのに、ほとんど分かりませんでした :oops:

まず、my.cnfの中は何も設定してなく、空っぽの状態です。
前は色々弄ったのですが、今回全て削除しております。

次にmy_huge.cfgが分かりませんでした。
telnetでfind / -type f -name my_huge.cfgとやっても何も出てきません。
同様にlocate my_huge.cfg とやっても何も出てきません。
php.iniの中も確認してみましたが、それらしいものがありませんでした。

それと DBは MyISAM ではなく InnoDB を
使われているようなので通常コメントになっている
先頭に InnoDB と付いている行も有効にする必要があるはず。

これに関してもどこで設定しているのかわかりませんでした。
php.iniにも該当の場所はなさそうでした。
一応、phpmyadminのストレージエンジンに記述はありましたので、掲載してみます。
ストレージエンジン 説明
MyISAM Default engine as of MySQL 3.23 with great performance
HEAP Alias for MEMORY
MEMORY Hash based, stored in memory, useful for temporary tables
MERGE Collection of identical MyISAM tables
MRG_MYISAM Alias for MERGE
ISAM Obsolete storage engine, now replaced by MyISAM
MRG_ISAM Obsolete storage engine, now replaced by MERGE
InnoDB Supports transactions, row-level locking, and foreign keys
INNOBASE Alias for INNODB
BDB Supports transactions and page-level locking
BERKELEYDB Alias for BDB
NDBCLUSTER Clustered, fault-tolerant, memory-based tables
NDB Alias for NDBCLUSTER
EXAMPLE Example storage engine
ARCHIVE Archive storage engine
CSV CSV storage engine
BLACKHOLE Storage engine designed to act as null storage

中を見ますと、
MyISAMは
Default engine as of MySQL 3.23 with great performance

MyISAM は、この MySQL サーバーのデフォルトストレージエンジンです。

データポインターサイズ 4 バイト
自動修復モード OFF
一時ソートファイルの最大サイズ 2,048 MB
インデックス作成用一時ファイルの最大サイズ 2,048 MB
リペアスレッド 1
ソートバッファーサイズ 8,192 KB

InnoDBは
Supports transactions, row-level locking, and foreign keys

[ 変数 | InnoDB ステータス ]

InnoDB は、この MySQL サーバーで利用可能です。

データホームディレクトリ
データファイル ibdata1:10M:autoextend
自動拡張の追加増加量 8
バッファー蓄積サイズ 8,192 KB

という状況でした。

また、topはこちらがそうかもしれないので掲載いたします。
ランタイム情報になります。
このMySQLサーバーは 0 日 0 時間 11 分 18 秒 間動作中で、2006 年 2 月 16 日 15:52 に起動しています。
サーバートラフィック: このテーブルは MySQL サーバーが起動してからのネットワークトラフィックの統計を表示します。
トラフィック &oslash; 時毎
受信済 5,283 KB 28,053 KB
送信 8,155 KB 43,300 KB
合計 13,438 KB 71,353 KB
接続 &oslash; 時毎 %
失敗しました 0 0.00 0.00 %
中断 0 0.00 0.00 %
合計 212 1,125.66 100.00 %


照会統計: 起動から 31,111 照会がサーバーに送られています。 合計 &oslash; 時毎 &oslash; /分 &oslash; /秒
31,111 165,191.15 2,753.19 45.89

照会タイプ &oslash; 時毎 %
admin commands 0 0.00 0.00 %
alter db 0 0.00 0.00 %
alter table 0 0.00 0.00 %
analyze 0 0.00 0.00 %
backup table 0 0.00 0.00 %
begin 0 0.00 0.00 %
change db 855 4,539.82 2.77 %
change master 0 0.00 0.00 %
check 0 0.00 0.00 %
checksum 0 0.00 0.00 %
commit 0 0.00 0.00 %
create db 0 0.00 0.00 %
create function 0 0.00 0.00 %
create index 0 0.00 0.00 %
create table 0 0.00 0.00 %
dealloc sql 0 0.00 0.00 %
delete 165 876.11 0.53 %
delete multi 0 0.00 0.00 %
do 0 0.00 0.00 %
drop db 0 0.00 0.00 %
drop function 0 0.00 0.00 %
drop index 0 0.00 0.00 %
drop table 0 0.00 0.00 %
drop user 0 0.00 0.00 %
execute sql 0 0.00 0.00 %
flush 0 0.00 0.00 %
grant 0 0.00 0.00 %
ha close 0 0.00 0.00 %
ha open 0 0.00 0.00 %
ha read 0 0.00 0.00 %
help 0 0.00 0.00 %
insert 144 764.60 0.47 %
insert select 0 0.00 0.00 %
kill 0 0.00 0.00 %
load 0 0.00 0.00 %
load master data 0 0.00 0.00 %
load master table 0 0.00 0.00 %
lock tables 0 0.00 0.00 %
optimize 0 0.00 0.00 %
preload keys 0 0.00 0.00 %
prepare sql 0 0.00 0.00 %
purge 0 0.00 0.00 %
purge before date 0 0.00 0.00 %
rename table 0 0.00 0.00 %
照会タイプ &oslash; 時毎 %
repair 0 0.00 0.00 %
replace 0 0.00 0.00 %
replace select 0 0.00 0.00 %
reset 0 0.00 0.00 %
restore table 0 0.00 0.00 %
revoke 0 0.00 0.00 %
revoke all 0 0.00 0.00 %
rollback 0 0.00 0.00 %
savepoint 0 0.00 0.00 %
select 17,415 92,469.03 56.36 %
set option 373 1,980.53 1.21 %
show binlog events 0 0.00 0.00 %
show binlogs 34 180.53 0.11 %
show charsets 34 180.53 0.11 %
show collations 34 180.53 0.11 %
show column types 0 0.00 0.00 %
show create db 0 0.00 0.00 %
show create table 0 0.00 0.00 %
show databases 3 15.93 0.01 %
show errors 0 0.00 0.00 %
show fields 0 0.00 0.00 %
show grants 5 26.55 0.02 %
show innodb status 2 10.62 0.01 %
show keys 0 0.00 0.00 %
show logs 0 0.00 0.00 %
show master status 0 0.00 0.00 %
show new master 0 0.00 0.00 %
show open tables 0 0.00 0.00 %
show privileges 0 0.00 0.00 %
show processlist 0 0.00 0.00 %
show slave hosts 0 0.00 0.00 %
show slave status 0 0.00 0.00 %
show status 4 21.24 0.01 %
show storage engines 25 132.74 0.08 %
show tables 20 106.19 0.06 %
show variables 79 419.47 0.26 %
show warnings 0 0.00 0.00 %
slave start 0 0.00 0.00 %
slave stop 0 0.00 0.00 %
truncate 0 0.00 0.00 %
unlock tables 0 0.00 0.00 %
update 831 4,412.39 2.69 %
update multi 0 0.00 0.00 %


その他の変数の状態
変数 値
Binlog cache disk use 0
Binlog cache use 0
Created tmp disk tables 291
Created tmp files 3
Created tmp tables 589
Delayed errors 0
Delayed insert threads 0
Delayed writes 0
Flush commands 1
Handler commit 0
Handler delete 55
Handler discover 0
Handler read first 4822
Handler read key 211091
Handler read next 5484385
Handler read prev 36
Handler read rnd 6407
Handler read rnd next 5105308
Handler rollback 2
Handler update 47490
Handler write 10417
Key blocks not flushed 0
Key blocks unused 7066
Key blocks used 202
Key read requests 606290
Key reads 705
Key write requests 3091
Key writes 583
Max used connections 11
変数 値
Not flushed delayed rows 0
Open files 128
Open streams 0
Open tables 64
Opened tables 629
Qcache free blocks 1
Qcache free memory 66992424
Qcache hits 10877
Qcache inserts 15185
Qcache lowmem prunes 0
Qcache not cached 2190
Qcache queries in cache 53
Qcache total blocks 140
Rpl status NULL
Select full join 175
Select full range join 0
Select range 65
Select range check 0
Select scan 6708
Slave open temp tables 0
Slave running OFF
Slave retried transactions 0
Slow launch threads 0
Slow queries 1
Sort merge passes 0
Sort range 495
Sort rows 10184
Sort scan 1144
Ssl accept renegotiates 0
変数 値
Ssl accepts 0
Ssl callback cache hits 0
Ssl cipher
Ssl cipher list
Ssl client connects 0
Ssl connect renegotiates 0
Ssl ctx verify depth 0
Ssl ctx verify mode 0
Ssl default timeout 0
Ssl finished accepts 0
Ssl finished connects 0
Ssl session cache hits 0
Ssl session cache misses 0
Ssl session cache mode NONE
Ssl session cache overflows 0
Ssl session cache size 0
Ssl session cache timeouts 0
Ssl sessions reused 0
Ssl used session cache entries 0
Ssl verify depth 0
Ssl verify mode 0
Ssl version
Table locks immediate 22739
Table locks waited 29
Threads cached 0
Threads connected 1
Threads created 211
Threads running 1
アバター
志田
記事: 526
登録日時: 2005/5/15 14:14
お住まい: 東京都
連絡を取る:

投稿記事by 志田 » 2006/2/16 20:29

サーバーのプランはVPSでしたっけ?

メモリ1.5Gかもしれないですが、それは共用なので、もっとすくないのでは?
VPSの仕様として一定のメモリ以上を食うとプロセスを落されるとか。
アークウェブ http:/www.ark-web.jp

きものリメイク comachi http://comachi-kimono.jp
アバター
がと
記事: 207
登録日時: 2005/10/04 05:26
お住まい: 東京
連絡を取る:

投稿記事by がと » 2006/2/16 22:43

また、topはこちらがそうかもしれないので掲載いたします。

topはこの話題の1ページ目の結果がそうですね。
last pid: 39618; load averages: 0.19, 0.12, 0.10 up 154+13:46:10 16:13:43
54 processes: 1 running, 53 sleeping

Mem: 1461M Active, 220M Inact, 233M Wired, 93M Cache, 199M Buf, 3928K Free
Swap: 4096M Total, 1938M Used, 2158M Free, 47% Inuse

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
69185 www 18 0 23328K 15676K lockf 0 4:56 2.10% 2.10% httpsd

と、いう結果ですからプロセスは54と極普通の数量しか動いていないのに使用中のメモリが
1461Mで空きが殆ど無し、スワップも1938Mほどしています。
何かメモリをバカ食いしているようですね。
sshかtelnetでログインしてtopと入力すると上の結果とともにリソース食ってるプロセスの
トップ20位が出てくるのでそれを見ると何がメモリを大量消費しているかわかります。
でも、もしかするとこれは共用サーバでFreeBSDのjail環境になっているのですかねぇ?

で、my_huge.cfgですが、目的のファイルの拡張子はcnfです。
これはmysqlが野良portsでなくFreeBSDの標準portsでインストールされているなら
/usr/local/share/mysqlに存在する可能性が高いです。
ただ、上にもあるようにメモリがアップアップですからhugeは使わない方が良いかと
思われます。
メモリがこんな状態というのは極めて好ましくありませんのでサーバー会社に連絡して
改善して貰った方がいいかと思われます。共用サーバだったら誰かが誤った使い方を
しているかもしれませんし。
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/17 11:30

うむむ。かなり困りましたね縲怐B。。
皆さんに公共の場を借りてこのように相談していることを大変申し訳なく、また大変ありがたく感じております。

とりあえず、topを実行させ、ずっと動いているのですが、とりあえず、スクリーンショットしてみました。
画像
画像
画像
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

投稿記事by kino » 2006/2/17 15:10

木下です。

色々とフォローありがとうございます。

/usr/local/share/mysqlに存在する可能性が高いです。
ただ、上にもあるようにメモリがアップアップですからhugeは使わない方が良いかと
思われます。
メモリがこんな状態というのは極めて好ましくありませんのでサーバー会社に連絡して
改善して貰った方がいいかと思われます。共用サーバだったら誰かが誤った使い方を
しているかもしれませんし。


そうか、共有サーバーだとメモリー使用量を減らしておく必要がありそうですね。
-----
木下 敏夫
http://www.tktools.jp/

大阪府産業デザインセンターデザイン専門員 ( http://bmb.oidc.jp/index.php?topic=-m-D14 )
奥様ショップ 店長 ( http://okusama-shop.com/ )
電脳ドロップシッピング 店長 ( http://d-064.d-shipping.net/ )
アバター
がと
記事: 207
登録日時: 2005/10/04 05:26
お住まい: 東京
連絡を取る:

投稿記事by がと » 2006/2/17 21:26

topコマンドのオプションの指定の仕方も書いておいたら良かったですね。
FreeBSDならtopコマンドのオプションは-bでリアルタイムに変化する表示をやめます。
-Sを指定するとシステム関係のプロセスも表示します。-oに続けてcpuを指定すると
CPUを食ってるランキング表示、-oに続けてresを指定するとリソースを食ってる順となります。
最後に数字でプロセスのランキングを何位まで表示するかの指定となります。
だからこんな指定をするといいです。
top -bS -ores 50
これで、表示されたプロセスにswappedというのが付いていたら要注意です。
何がスワップされているかによって影響度は全然違いますが。

で、前回のtopの結果と今回のtopの結果を見比べるとプロセス数がかなり減っています。
何でしょうね。
それにプロセスを見た感じでは悪さをしているようなのが見当たりません。
でも、メモリの状態は全く改善していないようです。
お腐れ様とかJabba the Hutt (Pizza the Hutt)みたいなプロセスが居ることを期待!?
したのですが、mysqldにしてもhttpd(httpsd)にしても私のとこより遥かにスリムです。

やっぱり別のユーザーが怪しいかと。
他人が動かしているプロセスが見えないようにしてあるようなのでやはりjailが使われて
いる感じですね。
あ、FreeBSDのjail自体は凄くいいものですよ。念のため。
FreeBSDの中で複数のFreeBSDが動いているようなイメージです。
運営側はユーザーをそれぞれの仮想マシンに閉じ込めることができるのでセキュリティ面の
管理が楽ですし、ユーザー側も専用マシンを与えられているかのように制約が少ない
環境を
得ることができます。
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/18 09:36

おはようございます。kimonoです :)
ふむふむ縲鰀 :?
一応、top -bS -ores 50の結果です。
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
94831 mysql 18 11 129M 21176K pause 1 0:04 0.00% 0.00% mysqld
94828 mysql 2 14 129M 21176K select 1 0:01 0.00% 0.00% mysqld
94829 mysql 2 14 129M 21176K select 1 0:01 0.00% 0.00% mysqld
94821 mysql 2 11 129M 21176K select 1 0:00 0.00% 0.00% mysqld
94822 mysql 2 11 129M 21176K poll 1 0:00 0.00% 0.00% mysqld
94825 mysql 18 14 129M 21176K pause 1 0:00 0.00% 0.00% mysqld
94824 mysql 18 14 129M 21176K pause 0 0:00 0.00% 0.00% mysqld
94830 mysql 18 14 129M 21176K pause 0 0:00 0.00% 0.00% mysqld
94823 mysql 18 14 129M 21176K pause 1 0:00 0.00% 0.00% mysqld
94832 mysql 18 12 129M 21176K pause 0 0:00 0.00% 0.00% mysqld
94826 mysql 18 14 129M 21176K pause 1 0:00 0.00% 0.00% mysqld
87809 www 18 0 24452K 15280K lockf 1 2:21 0.00% 0.00% httpsd
87740 www 18 0 24204K 14652K lockf 0 2:14 0.00% 0.00% httpsd
88028 www 18 0 23528K 14384K lockf 0 1:57 0.00% 0.00% httpsd
88040 www 18 0 23252K 14276K lockf 0 2:13 0.00% 0.00% httpsd
87800 www 18 0 23336K 14264K lockf 0 2:16 0.00% 0.00% httpsd
87739 www 18 0 23260K 14232K lockf 0 2:18 0.00% 0.00% httpsd
87741 www 18 0 22956K 14184K lockf 0 2:00 0.00% 0.00% httpsd
87743 www 18 0 23048K 14068K lockf 0 2:30 0.00% 0.00% httpsd
87813 www 18 0 23096K 13996K lockf 0 2:18 0.00% 0.00% httpsd
87812 www 18 0 22744K 13900K lockf 0 2:14 0.00% 0.00% httpsd
87742 www 18 0 22844K 13804K lockf 0 2:09 0.00% 0.00% httpsd
87815 www 18 0 22500K 13652K lockf 0 2:12 0.00% 0.00% httpsd
87808 www 18 0 22968K 13488K lockf 0 2:25 0.00% 0.00% httpsd
87814 www 2 0 21884K 12724K select 1 2:20 0.00% 0.00% httpsd
88039 www 18 0 22312K 12300K lockf 0 2:11 0.00% 0.00% httpsd
87719 root 2 0 12908K 4024K select 1 0:02 0.00% 0.00% httpsd
28048 root 2 0 2240K 1244K select 1 0:00 0.00% 0.00% telnetd
28049 root 10 0 1308K 980K wait 1 0:00 0.00% 0.00% login
28111 root 18 0 1340K 952K pause 1 0:00 0.00% 0.00% csh
87694 root 2 0 4336K 920K select 1 0:02 0.00% 0.00% sendmai
28104 kimono 18 0 1316K 884K pause 1 0:00 0.00% 0.00% tcsh
87691 root 2 0 2432K 876K select 1 0:06 0.00% 0.00% sshd
28184 root 33 0 1448K 820K CPU0 1 0:00 0.00% 0.00% top
87697 smmsp 18 0 3008K 564K pause 1 0:00 0.00% 0.00% sendmai
87678 root 2 0 932K 344K select 1 0:01 0.00% 0.00% syslogd
87689 root 10 0 980K 308K nanslp 1 0:00 0.00% 0.00% cron
87687 root 2 0 1072K 220K select 1 0:00 0.00% 0.00% inetd
87745 mysql 10 0 652K 192K wait 1 0:00 0.00% 0.00% sh
87769 root 10 0 376K 176K nanslp 0 0:10 0.00% 0.00% urchind
1 root 10 0 536K 32K wait 1 0:00 0.00% 0.00% init
87755 root 2 0 1068K 0K accept 0 0:00 0.00% 0.00% <saslau
swappedはなさそうですね縲怐B
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/25 18:03

こんにちわ。kimonoです :)
そう言えば、これだけ騒がせて置いて、報告を忘れていました :shock:
えっと、、、先日kinoさんに来ていただき、サーバーの設定をやっていただきましたところ、ほぼ問題ないようになりました。
一応、私がわかる範囲内で報告しますと、共有サーバーであったが、一つずつが別々のような仕組になっていて、2Gのメモリーを利用することが出来た。それを前提にmysql一つ一つへのメモリーの割り当てを増やしてもらった。古いメモリーの割り当てになっていたので、うちの用途にあわせて調整してもらった。
プラス、ずっと志田さんとかにも言われていたのによくわかっていなかったzenのindex貼りをした。かなり多く張りました。
結果、落ちなくなりました。
実際に作業をしていただいたkinoさんを始め、アドバイスを頂きました皆様方本当に大変有難うございましたm(__)m

“1.3.0.x公式版の不具合情報” へ戻る