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

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

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

投稿記事by kimono » 2006/2/11 10:24

おはようございます。kimonoです :)
今、展示会中なのですが :oops:
ちょっと昨日より、表題のエラーが出て、メインのzenが開かなくなってしまっておりました。xoopsや、他のzenは問題ありませんでしたが・・・
とりあえず、セッションがたまり過ぎか何かで固まっているのかと思い、サーバーを再起動などしてもダメで、phpmyadminでzen_sessionsを削除して、前にバックアップとって置きました、構造の部分を入れなおしましたところ、復帰しましたが、原因は不明です。
取り急ぎ報告まで :o
アバター
志田
記事: 526
登録日時: 2005/5/15 14:14
お住まい: 東京都
連絡を取る:

投稿記事by 志田 » 2006/2/11 13:05

reapir tableとかで直るかもしれません。
http://dev.mysql.com/doc/refman/4.1/ja/ ... table.html


Zen Cartのバグではないと思います。
アークウェブ http:/www.ark-web.jp
きものリメイク comachi http://comachi-kimono.jp
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/13 11:23

おはようございます。kimonoです :)
ふむふむバグではないのですね。それは大変よかったです :P
とりあえずは前記の方法で復帰しましたので、まぁよかったので。ちなみに、セッションなので、修正しなくてもとりあえずは問題はないので、志田さんの方法はまた何かあった際の勉強になりますので、覚えておきたいと思います。大変ありがとうございます。
ちなみに。昨日も一日MySQLのみが落ちてて(サーバー自体や、アパッチ、メールは問題なかった)全てのサイトが見れない状態になっていて、昼に会社に来て、サーバーをシャットダウンし、それで復帰させました。。。どんどんひどくなってきて、本当にどうすればいいんだろ・・・ちょっとしたこのようなことも全てナーバスになっちゃいます :cry:
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

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

木下です。

kimono さんが書きました:ちなみに。昨日も一日MySQLのみが落ちてて(サーバー自体や、アパッチ、メールは問題なかった)全てのサイトが見れない状態になっていて、昼に会社に来て、サーバーをシャットダウンし、それで復帰させました。。。どんどんひどくなってきて、本当にどうすればいいんだろ・・・ちょっとしたこのようなことも全てナーバスになっちゃいます :cry:


cron でMySQLの稼動状態を調べて落ちているようなら再起動させる
というのもありかも。

でも、利用している人が登録した情報が途中で消えてしまうと不味いでしょうから対処療法だけでなく
MySQLが落ちてしまうのが何故なのか根本原因を
突き止めないといけないんでしょうね。

MySQLのプロセスが多く起動してメモリー等のリソース不足に陥るからかな?
MySQLのプロセス1個のみではどの程度のメモリーを使用しているのでしょう?

サーバーのメモリー量を増やすとか
ソートバッファー等のプロセス毎に確保される設定を少なくして
同時稼動できるプロセス数を増やすことで軽減されるかもしれません。
-----
木下 敏夫
http://www.tktools.jp/

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

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

SHOW PROCESSLIST

を使うと、怪しいクエリーがわかるかもしれません。

参考) http://dev.mysql.com/doc/refman/4.1/ja/ ... slist.html

もしかすると、処理にすごく時間がかかっているクエリーがあって、それにリソースをとられて落ちているのかもしれないです。
アークウェブ http:/www.ark-web.jp

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

投稿記事by kimono » 2006/2/13 15:03

こんにちわ。kimonoです :)
前からお話しているこちらのスレッドが関連性が相当強そうです。
http://zen-cart.jp/bbs/viewtopic.php?t= ... highlight=
前にもお話していますようにSHOW PROCESSLIST はかなりのsleepが発生しております。現在の状況。
ID ユーザー ホスト データベース コマンド 時間 状態 実行した SQL 照会
停止 786 root localhost zen Sleep 273 --- ---
停止 787 root localhost zen Sleep 184 --- ---
停止 788 root localhost zen Sleep 1387 --- ---
停止 790 root localhost zen Sleep 1387 --- ---
停止 836 root localhost zen Sleep 237 --- ---
停止 837 root localhost zen Sleep 1091 --- ---
停止 840 root localhost zen Sleep 270 --- ---
停止 841 root localhost zen Sleep 206 --- ---
停止 846 root localhost zen Sleep 233 --- ---
停止 847 root localhost zen Sleep 253 --- ---
停止 848 root localhost zen Sleep 982 --- ---
停止 851 root localhost zen Sleep 257 --- ---
停止 859 root localhost zen Sleep 11 --- ---
停止 862 root localhost zen Sleep 52 --- ---
停止 900 root localhost zen Sleep 634 --- ---
停止 1016 root localhost mysql Query 0 --- SHOW PROCESSLIST

ちなみに、プロセス1個の容量の見方は分かりません :cry:
メモリーの状況は。
query cache size 8388608
key_buffer_size 8388600
sort_buffer_size 2097144

今、phpmyadminでランタイム情報を確認しましたところ、1時間前にも落ちてその時は自動で復帰した模様です。どうやら最近は1時間や30分に1回落ちて、再起動を繰り返しているようで、ひどくなると再起動すらせずにただ落ちっぱなしになる模様です。

照会統計を見ますと、照会タイプ selectが53.51 %で一番利用されている模様です。

前に志田さんが
http://www.zen-cart.jp/bbs/viewtopic.ph ... 4%A4%A4%C6
でいっていました

コード: 全て選択

<?php
echo nl2br(`ps -xa`);
?>

をしますと。
PID TT STAT TIME COMMAND
1 ?? Is 0:00.04 /sbin/init --
5612 ?? IN 0:00.15 /usr/local/libexec/mysqld --defaults-extra-file=/var/
5626 ?? IN 0:00.52 /usr/local/libexec/mysqld --defaults-extra-file=/var/
5660 ?? IN 0:00.17 /usr/local/libexec/mysqld --defaults-extra-file=/var/
5662 ?? IN 0:00.38 /usr/local/libexec/mysqld --defaults-extra-file=/var/
6862 ?? IN 0:01.57 /usr/local/libexec/mysqld --defaults-extra-file=/var/
6885 ?? IN 0:01.17 /usr/local/libexec/mysqld --defaults-extra-file=/var/
7017 ?? IN 0:00.44 /usr/local/libexec/mysqld --defaults-extra-file=/var/
7023 ?? IN 0:01.81 /usr/local/libexec/mysqld --defaults-extra-file=/var/
7308 ?? IN 0:00.55 /usr/local/libexec/mysqld --defaults-extra-file=/var/
7319 ?? IN 0:00.27 /usr/local/libexec/mysqld --defaults-extra-file=/var/
7327 ?? IN 0:00.79 /usr/local/libexec/mysqld --defaults-extra-file=/var/
7433 ?? IN 0:00.94 /usr/local/libexec/mysqld --defaults-extra-file=/var/
8006 ?? IN 0:00.74 /usr/local/libexec/mysqld --defaults-extra-file=/var/
8044 ?? IN 0:01.84 /usr/local/libexec/mysqld --defaults-extra-file=/var/
8481 ?? IN 0:00.31 /usr/local/libexec/mysqld --defaults-extra-file=/var/
13224 ?? S 1:22.84 /usr/local/apache/bin/httpsd
13544 ?? S 1:27.15 /usr/local/apache/bin/httpsd
14436 ?? Ss 0:00.04 proftpd: kimono - 222.158.247.228: IDLE (proftpd)
14539 ?? S 0:00.00 sh -c ps -xa
14540 ?? R 0:00.00 ps -xa
69025 ?? Ss 0:00.65 /usr/sbin/syslogd -ss
69039 ?? Ss 0:00.36 /usr/sbin/inetd -wW
69041 ?? Is 0:00.29 /usr/sbin/cron
69044 ?? Ss 0:02.18 /usr/sbin/sshd
69049 ?? Ss 0:03.88 sendmail: accepting connections (sendmail)
69052 ?? Is 0:00.05 sendmail: Queue runner@00:30:00 for /var/spool/client
69073 ?? Ss 0:04.33 /usr/local/apache/bin/httpsd
69104 ?? S 4:27.89 /usr/local/apache/bin/httpsd
69105 ?? S 4:21.17 /usr/local/apache/bin/httpsd
69107 ?? S 4:55.98 /usr/local/apache/bin/httpsd
69108 ?? S 4:38.51 /usr/local/apache/bin/httpsd
69110 ?? I 0:00.04 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-f
69119 ?? IWs 0:00.00 /usr/local/sbin/saslauthd -a pam -n 1
69124 ?? Ss 0:18.82 /usr/local/urchin5/bin/urchind
69169 ?? S 4:26.31 /usr/local/apache/bin/httpsd
69176 ?? S 4:31.68 /usr/local/apache/bin/httpsd
69177 ?? S 4:41.03 /usr/local/apache/bin/httpsd
69182 ?? S 4:37.17 /usr/local/apache/bin/httpsd
69183 ?? S 4:13.12 /usr/local/apache/bin/httpsd
69185 ?? S 4:30.22 /usr/local/apache/bin/httpsd
69236 ?? S 4:56.72 /usr/local/apache/bin/httpsd
69237 ?? S 4:29.87 /usr/local/apache/bin/httpsd
69238 ?? S 4:27.48 /usr/local/apache/bin/httpsd
91602 ?? SN 0:00.33 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91607 ?? SN 0:00.41 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91608 ?? IN 0:00.00 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91609 ?? IN 0:00.00 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91610 ?? IN 0:00.00 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91611 ?? IN 0:00.00 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91614 ?? SN 0:01.48 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91615 ?? SN 0:01.02 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91616 ?? IN 0:00.00 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91617 ?? SN 0:05.55 /usr/local/libexec/mysqld --defaults-extra-file=/var/
91621 ?? IN 0:00.00 /usr/local/libexec/mysqld --defaults-extra-file=/var/

のような感じです。

また、show global variables like "%timeout";の状況は
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| connect_timeout | 5 |
| delayed_insert_timeout | 300 |
| innodb_lock_wait_timeout | 50 |
| interactive_timeout | 28800 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| sync_replication_timeout | 0 |
| wait_timeout | 28800 |
+--------------------------+-------+
9 rows in set (0.01 sec)

です。
スレッドがばらばらになってしまいましたので、ちょっと整理してみました。
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

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

木下です。

kimono さんが書きました:ちなみに、プロセス1個の容量の見方は分かりません :cry:


コード: 全て選択

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


で判るかも。
-----
木下 敏夫
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/13 15:39

木下です。

kimono さんが書きました:メモリーの状況は。
query cache size 8388608
key_buffer_size 8388600
sort_buffer_size 2097144


http://itpro.nikkeibp.co.jp/members/ITP ... 56109/?P=2

key_buffer_size は全コネクション で共通だけど
sort_buffer_size はコネクション毎なので
値が多すぎるのかも。

それとは逆に query cache size はまだ小さいのかも知れません。
http://dev.mysql.com/doc/refman/4.1/ja/query-cache.html
SHOW STATUS の
Qcache_lowmem_prunes
を見て判断するのかな。
-----
木下 敏夫
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/13 16:15

コード: 全て選択

<?php
echo nl2br(`top -n 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

でしたが、全く意味がわかりません :oops:

query cache size は今、query cache limit ともに、16777216に変更してみました。

ちなみに。
さきほどとまた今、2回mysqlが落ちました。。。 :cry:
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

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

木下です。

kimono さんが書きました:
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


えーと

サーバーは 1.5GBのメモリーを積んでいて
Swapとして4G準備している
で、2GB使っていて
あと2GB残ってるよ・・・
実メモリーは 4MBだけ Free

うーん、かなりしんどそうな状況ですね。
特に Apache一個のプロセスに 23MB使っていてMySQLにもそれなりに
使っているだろうから1接続辺り 30縲怩T0MBのメモリーを必要と考えると
同時に20件つながれるだけで1Gのメモリーが必要となる気がします。

httpdのキープアライブを短くするとかして不要になったプロセスは
直ぐに破棄するようにしないといけないのかな?

結構メモリーに対してシビアなチューニングが必要かも。
最近のメモリーの価格を考えると
メモリー増やすのが一番手っ取り早い解決法かもしれません。
-----
木下 敏夫
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/13 17:29

う縲怩B。。そうなんですかぁ :cry:
解説大変ありがとうございます。

ちなみに、現在はVPSサーバーのため、メモリーの増設などは出来ない状態です;;
それならと思い、専用サーバーを確認してみましたが、2台あり、片方は1G、片方は2Gでそれぞれ増設は不可能ということでした。ただ、VPSと違い、1台丸まるなので、どのように割り振っても全く問題ないとのことでしたが・・・

query cache size 変えてみましたが、上限があるためか、やはり状況は変わらず、さっきもまた落ちましたね;;
自社サーバーの構築を考えなきゃいけないのかなぁ・・・ :cry:

とりあえずは、30分に一度は最低落ちている状態なので、sleepの時間が8時間で切断するようになっているのをもっと早くなんとかした方がいいのでしょうかね・・・早くとは言っても30分じゃきついか・・・ :?
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

投稿記事by kimono » 2006/2/13 18:42

む!
ちょっとだけ気づいたことがありましたので、報告です。
今、ずっとphpmyadminを眺めていたのですが、普通にzenの商品ページなどを見たり、買い物したり、色々やってみましたが、sleepが出ませんでした。
・・・ただ、申し訳ないのですが、zoxの104はquery_factory.phpの14行目がif ($zf_pconnect=='false') { になっていなかったため、sleepが多発しておりました。こちらは修正しました。
と、あることに気づきました。じゃあどこでsleepが・・・???
管理画面でした :shock:
管理画面にアクセスした瞬間に、sleepが発生します!そこで、何か作業したりしなくても、一つのページを開く度に、sleepが一つ増えていきます。今までスタッフが作業していたり、他の会社が作業していたりしてて、何も動いていないときがなかったので、テストできなかったのですが、やっとわかりました。
すいません、報告が遅くなりまして・・・ :cry:
何か分かれば幸いです。
アバター
志田
記事: 526
登録日時: 2005/5/15 14:14
お住まい: 東京都
連絡を取る:

投稿記事by 志田 » 2006/2/13 18:54

apacheを再起動するとsleepが消えるということは、pconnectを使用しているんだと思います。

http://jp.php.net/manual/ja/features.pe ... ctions.php

PHPをマルチプロセスWebサーバー(現在は Apacheのみが含まれます)のモジュールとして実行する方法です。マルチプ ロセスサーバーは、通常、実際にWebページを送信する複数のプロセス(子) を管理するプロセス(親)を有しています。リクエストがクライアントから 来ると、親プロセスは、他のクライアントにすでに送信を行っていないク ライアントの一つに渡します。このため、同じクライアントが2番目のリク エストをサーバーに送信した際に最初のではなく他の子プロセスにより送 信が行われる可能性があります。 持続的接続がオープンされているとき、SQL サービスにリクエストを行う それぞれのページは SQL サーバへの確立された接続を再利用することが できます。


apacheを落すと、持続的接続を保持している親プロセスが消え、結果的に、全部切断されて、sleepが消える、ということではないかと思います。

この問題はzen-cart-v1.2.0-l10n-jp-5で修正しています。
https://sourceforge.jp/projects/zencart ... -_Changes/

がとさんも報告されていますが、英語版Zen Cartは、逆に常にpconnectを使わず、通常のconnectを使用する、というバグがありますので、そのためにsleepが発生しないのだと思います。


でも、query_factory.phpは、

includes/classes/db/mysql/query_factory.php

の1つしかなくて、管理側もエンドユーザー側も同じプログラムを使っていると
思いますが、なんでエンドユーザー側は大丈夫で管理側はだめなんでしょうね。
アークウェブ http:/www.ark-web.jp

きものリメイク comachi http://comachi-kimono.jp
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

投稿記事by kino » 2006/2/13 19:58

木下です。

志田 さんが書きました:でも、query_factory.phpは、

includes/classes/db/mysql/query_factory.php

の1つしかなくて、管理側もエンドユーザー側も同じプログラムを使っていると
思いますが、なんでエンドユーザー側は大丈夫で管理側はだめなんでしょうね。


いっそのこと query_factory.php の

コード: 全て選択

      $this->link = @mysql_pconnect($zf_host, $zf_user, $zf_password);


コード: 全て選択

      $this->link = @mysql_connect($zf_host, $zf_user, $zf_password);

にしてしまって持続的接続をしないようにしてしまったほうがいいのかも知れませんね。
-----
木下 敏夫
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/14 00:30

ちょうど、pconnectの話題が出て都合もいいですし、こちらに書きます。
前回 http://zen-cart.jp/bbs/viewtopic.php?t=2035 ではmysqlの側で
timeoutまでの時間を短くすればよいかと考えたのですが、それではアクセス数が増えれば
結局同じことになるので解決策にはなりませんので忘れて下さい。
っていうか前回はmysqlのことばかり考えていたので他の解決方法に考えが廻りません
でした。

zencartの日本語版でpconnect(持続接続)が何処かで使用されているのが原因なら、
それが解決するまではphp.ini側で持続接続を使用できなくする、または持続接続数を
制限するというのはどうでしょう。
デフォルトでは下のようになっていると思いますが、これでは無制限に持続接続してしまう
ので持続接続を不許可にするなら上の行の値をOff、Onでいいけど制限数を設定
したいなら下の行を-1(無制限)から制限したい値に変更。
mysql.allow_persistent = On
mysql.max_persistent = -1

これでしのぐというのが良いかと思います。
ただし、php.iniを変更できないレンタルサーバではダメですが。
アバター
kino
記事: 893
登録日時: 2005/5/15 19:39
お住まい: 京都
連絡を取る:

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

木下です。

がと さんが書きました:zencartの日本語版でpconnect(持続接続)が何処かで使用されているのが原因なら、
それが解決するまではphp.ini側で持続接続を使用できなくする、または持続接続数を
制限するというのはどうでしょう。


そうですね。
特に管理画面だけということらしいから
接続数を数個に限定してしまってもいいのかも。

サーバーでSWAPが発生しない程度まで
メモリーの使用量が削減できたら
レスポンスも可也素早く感じるようになるかも。
-----
木下 敏夫
http://www.tktools.jp/

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

投稿記事by 志田 » 2006/2/14 02:39

うーむ、pconnectを使っているのは今回修正した一箇所だけのはずなんですが…

これはZen Cart日本語版(というか英語版1.2.0)のバグなので、
対処療法ではなく、ちゃんと解決したいものです。

admin/includes/configure.php

では、

define('USE_PCONNECT', 'false'); // use persistent connections?

のように、pconnectはfalseになっていますよね?
アークウェブ http:/www.ark-web.jp

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

投稿記事by kimono » 2006/2/14 09:54

おはようございます。kimonoです :)
また、昨日の夜20時頃にmysqlが落ち、今度は再起動すらせずに、先ほどまで固まっておりました。。。MySQLが停止した時にMySQLプロセスが正常終了せずに
残ってしまったと思いますとのサーバー会社の返答です。

define('USE_PCONNECT', 'false'); // use persistent connections?はなっております。同じ現象が、一つのサーバーに入れている、2つのzen、hiraさんのzox共におきていますので、設定ではないと思います。。。
で、とりあえず、ChangeLogを参考に試しに英語版と同じく設定してみました。
query_factory.php line34-38
if ($zf_pconnect == 'false') {
$this->link = @mysql_connect($zf_host, $zf_user, $zf_password);
} else {
$this->link = @mysql_pconnect($zf_host, $zf_user, $zf_password);
}

if (!$zf_pconnect == 'false') {
$this->link = @mysql_connect($zf_host, $zf_user, $zf_password, true);
} else {
$this->link = @mysql_connect($zf_host, $zf_user, $zf_password, true);
}

そうすると、pconnectを使っていないため当然と言えば当然ですが、お客様側の画面、管理画面共に全くsleepが発生しないようになりました。
ただ、その後2013 Lost connection to MySQL server during queryと、またmysqlが落ちましたが :cry: 更新を押して復帰はしました・・・問題はこれだけではなくメモリー不足もあるのでしょうね;;
アバター
kimono
記事: 1995
登録日時: 2005/9/27 13:30
お住まい: 大阪府大阪市天王寺区上本町
連絡を取る:

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

今日半日ぐらい上記の状態でサイトの更新も行っておりますが、基本的に大きな問題は起きていないみたいです。
上記の変更(日本語の常時接続をなくし、英語版と同様にする方法)は何か問題がございますでしょうか?ただ、常時接続をONにした場合、されないとかそれだけの問題ならばいいのですが・・・。
ちなみに、その後プロセスにsleepはたまらない模様です。mysql自体は時々落ちて再起動している模様ですが :oops:
アバター
志田
記事: 526
登録日時: 2005/5/15 14:14
お住まい: 東京都
連絡を取る:

投稿記事by 志田 » 2006/2/14 15:36

kimono さんが書きました:今日半日ぐらい上記の状態でサイトの更新も行っておりますが、基本的に大きな問題は起きていないみたいです。
上記の変更(日本語の常時接続をなくし、英語版と同様にする方法)は何か問題がございますでしょうか?ただ、常時接続をONにした場合、されないとかそれだけの問題ならばいいのですが・・・。
ちなみに、その後プロセスにsleepはたまらない模様です。mysql自体は時々落ちて再起動している模様ですが :oops:


sleepというのは持続的接続を利用する場合は正常な状態ですから、
落ちていたのはsleepのせいではなかったわけですね。

pconnectの対応については問題ないと思います。

僕が修正した方法でも常にpconnectになってしまうようなら
それはそれで問題なんですけどね ^^; …

なんかエラーログとかでてないでしょうか?
アークウェブ http:/www.ark-web.jp

きものリメイク comachi http://comachi-kimono.jp

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