質問 > 管理機能 > 大量の規格登録でエラーが出るが、規格を削除したら |
管理機能
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
horai |
投稿日時: 2020/6/19 20:03
対応状況: 確認中
|
半人前 登録日: 2013/3/20 居住地: 投稿: 15 |
大量の規格登録でエラーが出るが、規格を削除したら ▼テンプレート
[EC-CUBE] 2.12.2 [レンタルサーバ] さくらインターネットの共用 [PHP] 使用しているPHPのバージョン [データベース] 使用しているDB名、バージョン 現時点、商品登録点数212、規格1登録数107、規格2登録数12で回しているサイトですが 規格からの在庫処理を行うと、500エラーが出てきます。 以前も同じことがあったので おそらくmax_input_varsとmemory_limitだろうと思って とりあえずは対応しなければと思い max_input_vars = 250000 memory_limit = 20M post_max_size = 20M ↓ max_input_vars = 2500000 memory_limit = 50M post_max_size = 50M まで引き上げたのですが、500エラーがシステムエラーに変わり、 エラーもやはり Maximum execution time of 30 seconds exceeded on~ が出ています。 これはやはり規格の数の問題かと思っているのですが、 管理画面上から使わない規格を削除したり、使わない商品を削除することで DBへの負荷を減らすことは可能なのでしょうか。 実際DBにはdel_flagが立っていてデーターとしては残っているように思えますので 減らしたからと言って処理が入っているのではないかと思っています。 いっそのこと、dbから使用しない規格の行を削除する、ということをしたら(かなり乱暴と思いますが) 少しは負荷を減らすことができるのでしょうか。 |
468 |
投稿日時: 2020/6/20 10:56
対応状況: −−−
|
神 登録日: 2008/10/26 居住地: 投稿: 3217 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら エラーの内容からメモリー制限ではなく、実行時間の制限のほうに引っかかっているのかと思います。
実行時間制限はmax_execution_timeで設定されていると思いますので とりあえずその時間を延ばしてみては如何でしょうか? あと処理が重たくなっている原因は規格1(分類)の件数が多い事かと思います。 細かく分ける事ができないか検討された方が良いかもしれません。
|
horai |
投稿日時: 2020/6/22 20:56
対応状況: −−−
|
半人前 登録日: 2013/3/20 居住地: 投稿: 15 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら >468様
ご回答いただきありがとうございます。 アドバイス頂いたmax_execution_timeを伸ばしてみたところ、 まだ改善はありませんが、何とかなるかもしれない感じがしてきましたので頑張ってみます。 >あと処理が重たくなっている原因は規格1(分類)の件数が多い事かと思います。 >細かく分ける事ができないか検討された方が良いかもしれません。 こちらクライアントに提案させていただきました。 この細かく分ける件ですが、現在「カラー」という項目で107登録されているのを、カラー50にし、新たに「サブ」という規格を作りこちらに57を引っ越すような感じで考えています。 この場合、分割した57項目を「カラー」から削除した場合、不可は減るものなのでしょうか。 DB上ではdel_flagが立っているだけなので、カラーは50項目だけど結局107項目を見に行っていることになるのではないかと気になっています。 |
nanasess |
投稿日時: 2020/6/24 15:53
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2303 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら 1商品につき規格1登録数107、規格2登録数12が付与されているのでしょうか?
それほど大量のデータが登録されているわけではなさそうですので、ちょっと工夫すれば改善されそうな気がしています。 現在、2.17.x へ提案中の修正ですが、こちらを適用することで改善されませんでしょうか? https://github.com/EC-CUBE/ec-cube2/pull/362/files |
horai |
投稿日時: 2020/6/24 20:10
対応状況: −−−
|
半人前 登録日: 2013/3/20 居住地: 投稿: 15 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら >nanasesss様
回答ありがとうございます。 >1商品につき規格1登録数107、規格2登録数12が付与されているのでしょうか? 1商品につき規格1は約5個前後が選ばれており、規格2は約5個選ばれている感じです。 >現在、2.17.x へ提案中の修正ですが、こちらを適用することで改善されませんでしょうか? アドバイスありがとうございます。 見せていただいたこの修正は、2.12.2でも動く修正でしょうか。 ちょうど107の規格1をクライアントと相談し、60までに減らすため、管理画面から削除しようとしていたところです。 削除の上、このgitの内容を行ったほうがよろしいでしょうか。 |
nanasess |
投稿日時: 2020/6/25 12:17
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2303 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら 2.12.2 にコピペで適用できるか、あまり自信ありませんが、基本的なロジックは同じはずです。
適用の際は、十分に動作確認をお願い致します。 データ量よりも、PHPの処理スピードが問題になっている気がしますので、規格1を減らすことは有効だと思います ちなみに、さくらのレンタルサーバーでは、モジュールモードのPHPとCGIモードのPHPがありますが、どちらをご利用でしょうか? CGIモードをご利用でしたら、モジュールモードにすることで改善する可能性はあります。 |
horai |
投稿日時: 2020/6/25 17:16
対応状況: −−−
|
半人前 登録日: 2013/3/20 居住地: 投稿: 15 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら >nanasessさん
ご回答ありがとうございます。 頂いた回答を踏まえたうえで、規格1から不要な企画を削除し(107個→55個)まで減らし、念のために不要な商品も削除し(212→160)して、ご教授頂いただいた data/class/pages/admin/order/LC_Page_Admin_Order_Edit.php data/class/pages/admin/products/LC_Page_Admin_Products_ProductClass.php の修正を当ててみました。 当ててからの動作はシステムエラーなどなく動いています。 何となくかもしれませんが、動作が早くなった気もします。 ただ、やはり規格メニューからの在庫入力保存処理(テストなので変更せずにそのまま保存)を行ったところ、確認画面から「保存を行う」からの処理で長くかかり、タイムアウトを起こしてシステムエラーが出ました。 念のためにPCの再起動もかけて再度確認しましたが、状況変わらず。 保存ボタンを押す前に在庫数を変更してみたのですが、 エラー後確認したところその変更は反映していませんでした。 なお現時点のさくらのphp.iniは max_input_vars = 5000000 memory_limit = 128M post_max_size = 120M max_execution_time = 1000 としています。 ※アドバイス頂いたPHPのモジュールモード変更ですが ほかのサイトも入っているのですぐには対応が難しい内容のため、 今回は行っておりません。 以下、ECcubeのエラーログに出た内容を転載します。 ↓↓↓↓↓↓↓↓↓↓↓↓↓↓ ※規格1×規格2の組み合わせ1個を保存した時のエラー /shop/admin/products/product_class.php Fatal error(E_USER_ERROR): DB処理でエラーが発生しました。 SQL: [PREPARE mdb2_statement_mysql_151009eee17ba12a4079085612d790c097bdaf4bdf FROM 'DELETE FROM dtb_products_class WHERE product_class_id = ?'] PlaceHolder: [array ( 0 => '8600199', )] MDB2 Error: unknown error _doQuery: [Error message: Could not execute statement] [Last executed query: EXECUTE mdb2_statement_mysql_151009eee17ba12a4079085612d790c097bdaf4bdf USING @0] [Native code: 1205] [Native message: Lock wait timeout exceeded; try restarting transaction] on [/home/●/www/▲/shop/data/class/SC_Query.php(1008)] from ***.***.*** login_id = ●(0)[77fcc0a54452bafc63a717724b34f535] /home/●/www/▲/shop/admin/products/product_class.php(34): LC_Page_Admin_Products_ProductClass_Ex->process /home/●/www/▲/shop/data/class_extends/page_extends/admin/products/LC_Page_Admin_Products_ProductClass_Ex.php(56): LC_Page_Admin_Products_ProductClass->process /home/●/www/▲/shop/data/class/pages/admin/products/LC_Page_Admin_Products_ProductClass.php(63): LC_Page_Admin_Products_ProductClass->action /home/●/www/▲/shop/data/class/pages/admin/products/LC_Page_Admin_Products_ProductClass.php(148): LC_Page_Admin_Products_ProductClass->registerProductClass /home/●/www/▲/shop/data/class/pages/admin/products/LC_Page_Admin_Products_ProductClass.php(292): SC_Query->delete /home/●/www/▲/shop/data/class/SC_Query.php(746): SC_Query->query /home/●/www/▲/shop/data/class/SC_Query.php(814): SC_Query->execute /home/●/www/▲/shop/data/class/SC_Query.php(971): SC_Query->error /home/●/www/▲/shop/data/class/SC_Query.php(1008): trigger_error ↓↓↓↓↓↓↓↓↓↓↓↓↓↓ ※規格1×規格2の組み合わせ2個を保存しようとしたときのエラー /shop/admin/products/product_class.php Fatal error(E_USER_ERROR): DB処理でエラーが発生しました。 SQL: [PREPARE mdb2_statement_mysql_15ab029d22af1522c88ccd52f073dd0e899cdeef09 FROM 'UPDATE dtb_products_class SET classcategory_id1= ?, classcategory_id2= ?, product_code= ?, stock= ?, price01= ?, product_type_id= ?, down_filename= ?, down_realfilename= ?, product_id= ?, sale_limit= ?, deliv_fee= ?, point_rate= ?, stock_unlimited= ?, price02= ?, creator_id= ?, update_date= CURRENT_TIMESTAMP, del_flg= ?, create_date= CURRENT_TIMESTAMP WHERE product_class_id = ?'] PlaceHolder: [array ( 0 => '3', 1 => '13', 2 => '10835', 3 => '99', 4 => '24000', 5 => '1', 6 => '', 7 => '', 8 => '718', 9 => NULL, 10 => NULL, 11 => '0', 12 => 0, 13 => '24000', 14 => '2', 15 => 0, 16 => '8386994', )] MDB2 Error: unknown error _doQuery: [Error message: Could not execute statement] [Last executed query: EXECUTE mdb2_statement_mysql_15ab029d22af1522c88ccd52f073dd0e899cdeef09 USING @0, @1, @2, @3, @4, @5, @6, @7, @8, @9, @10, @11, @12, @13, @14, @15, @16] [Native code: 1205] [Native message: Lock wait timeout exceeded; try restarting transaction] on [/home/●●●/www/▲▲▲/shop/data/class/SC_Query.php(1008)] from ***.***.*** login_id = ●●●(0)[77fcc0a54452bafc63a717724b34f535] /home/●●●/www/▲▲▲/shop/admin/products/product_class.php(34): LC_Page_Admin_Products_ProductClass_Ex->process /home/●●●/www/▲▲▲/shop/data/class_extends/page_extends/admin/products/LC_Page_Admin_Products_ProductClass_Ex.php(56): LC_Page_Admin_Products_ProductClass->process /home/●●●/www/▲▲▲/shop/data/class/pages/admin/products/LC_Page_Admin_Products_ProductClass.php(63): LC_Page_Admin_Products_ProductClass->action /home/●●●/www/▲▲▲/shop/data/class/pages/admin/products/LC_Page_Admin_Products_ProductClass.php(148): LC_Page_Admin_Products_ProductClass->registerProductClass /home/●●●/www/▲▲▲/shop/data/class/pages/admin/products/LC_Page_Admin_Products_ProductClass.php(289): SC_Query->update /home/●●●/www/▲▲▲/shop/data/class/SC_Query.php(589): SC_Query->query /home/●●●/www/▲▲▲/shop/data/class/SC_Query.php(814): SC_Query->execute /home/●●●/www/▲▲▲/shop/data/class/SC_Query.php(971): SC_Query->error /home/●●●/www/▲▲▲/shop/data/class/SC_Query.php(1008): trigger_error |
nanasess |
投稿日時: 2020/6/25 17:33
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2303 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら Lock wait timeout exceeded と出ていますので、MySQLがデッドロック状態になっているようです。
在庫更新と同時に、フロント側で商品購入されているといった状況になっていませんでしょうか? |
horai |
投稿日時: 2020/6/25 18:28
対応状況: −−−
|
半人前 登録日: 2013/3/20 居住地: 投稿: 15 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら >nanasess 様
ご回答ありがとうございます。 頂いた回答から、今一度テストしてみました。 かなり処理の時間をかけたのち、サーバーから Gateway Timeout The gateway did not receive a timely response from the upstream server or application. が返ってきました。 二つ前のエラー内容の時間帯のアクセス状況を確認したところ ページへのアクセスはありましたが、購入動作のログは残っていませんでした。(受注記録もなし) やはり肥大化したデーターベースが原因でしょうか。 |
nanasess |
投稿日時: 2020/6/25 18:38
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2303 |
Re: 大量の規格登録でエラーが出るが、規格を削除したら データベースの肥大化より、何らかの処理が競合しているのだと思います。。。
あまり見ないケースですので、プラグインや独自カスタマイズが原因の可能性もあります。 |
(1) 2 » |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |