質問 > 管理機能 > データベース(RDS)でのデッドロックについて |
管理機能
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
eichan0123 |
投稿日時: 2025/1/21 21:53
対応状況: −−−
|
新米 ![]() ![]() 登録日: 2024/12/17 居住地: 投稿: 5 |
データベース(RDS)でのデッドロックについて [EC-CUBE] 4.2.3、新規インストール
[レンタルサーバ] AWS EC2 [OS] AmazonLinux2023 [PHP] 8.1.29 [データベース] PostgreSQL 15.7 [現象] 販売フロントサイトに、アクセスが集中した時間帯において データベース・サーバー(RDS)のログに デッドロックのエラーがいくつか発生しております。 このアクセス集中した時間帯のサーバースペックは、かなり余裕のあるものを設定しており、CPU利用率も10%台に留まっていたのですが、フロントサイト側がほとんどアクセスできない状況(502や504エラー発生)で、このデッドロックも一因と考えております。 具体的なログ内容は次のとおりです。※一部時間帯やサイトを示す情報は伏字にしています 2025-01-XX XX:XX:10 UTC:XX.XX.XX.XX(38878):XXXXXXXXXX:[809]:ERROR: deadlock detected 2025-01-XX XX:XX:10 UTC:XX.XX.XX.XX(38878):XXXXXXXXXX:[809]:DETAIL: Process 809 waits for ShareLock on transaction 115329; blocked by process 937. Process 937 waits for ShareLock on transaction 115324; blocked by process 809. Process 809: UPDATE dtb_product_stock SET stock = $1, update_date = $2 WHERE id = $3 Process 937: UPDATE dtb_product_class SET stock = $1, update_date = $2 WHERE id = $3 在庫更新を行っている箇所で発生しているように見受けられます。 こちらの解決方法など、ご教示いただけますと幸いです。 |
mcontact |
投稿日時: 2025/1/22 15:33
対応状況: −−−
|
神 ![]() ![]() 登録日: 2022/1/22 居住地: 投稿: 1636 |
Re: データベース(RDS)でのデッドロックについて PostgreSQLのデッドロックの確認と解除であれば、下記のサイトを参考にしてみてください。
https://www.compiere-distribution-lab.net/2015/06/18/postgresql-0007-%E3%83%AD%E3%83%83%E3%82%AF-lock-%E3%81%AE%E7%A2%BA%E8%AA%8D%E6%96%B9%E6%B3%95%E3%81%A8%E3%83%87%E3%83%83%E3%83%88%E3%83%AD%E3%83%83%E3%82%AF%E3%81%AE%E8%A7%A3%E9%99%A4/
|
eichan0123 |
投稿日時: 2025/1/24 8:55
対応状況: −−−
|
新米 ![]() ![]() 登録日: 2024/12/17 居住地: 投稿: 5 |
Re: データベース(RDS)でのデッドロックについて > PostgreSQLのデッドロックの確認と解除であれば、下記のサイトを参考にしてみてください。
→ご返信ありがとうございます。参考にさせていただきます。 今回の主題と内容が変わってしまいますが、 フロントサイト側がほとんどアクセスできない状況(502や504エラー発生)に関して、引き続きDBのログを確認したところ 次の2種類のエラーも発生していました。 (1) Foreign key エラー 2025-01-XX XX:XX:XX UTC:XX.XX.XX.XX(50492):XXXXX:[10169]:ERROR: update or delete on table "dtb_shipping" violates foreign key constraint "fk_a0c8c3ed4887f3f8" on table "dtb_order_item" 2025-01-XX XX:XX:XX UTC:XX.XX.XX.XX(50492):XXXXX:[10169]:DETAIL: Key (id)=(1016) is still referenced from table "dtb_order_item". 2025-01-XX XX:XX:XX UTC:XX.XX.XX.XX(50492):XXXXX:[10169]:STATEMENT: DELETE FROM dtb_shipping WHERE id = $1 (2) not null エラー 2025-01-XX XX:XX:XX UTC:XX.XX.XX.XX(48820):XXXXX:[29527]:ERROR: null value in column "name01" of relation "dtb_order" violates not-null constraint 2025-01-XX XX:XX:XX UTC:XX.XX.XX.XX(48820):XXXXX:[29527]:DETAIL: Failing row contains (2177, null, null, null, null, null, 6, 10, 8480b8fd6615b7368d5b2049b430ca1817a8ba38, null, null, null, null, null, null, null, [email protected], null, null, null, null, null, 21360.00, 0.00, 0.00, 0.00, 0.00, 21360.00, 21360.00, コンビニ決済, null, 2025-01-XX XX:XX:XX+00, 2025-01-XX XX:XX:XX+00, null, null, JPY, null, null, 0, 0, 8, order, null, null, null, null, null, null, null). 2025-01-XX XX:XX:XX UTC:XX.XX.XX.XX(48820):XXXXX:[29527]:STATEMENT: INSERT INTO dtb_order (pre_order_id, order_no, message, name01, name02, kana01, kana02, company_name, email, phone_number, postal_code, addr01, addr02, birth, subtotal, discount, delivery_fee_total, charge, tax, total, payment_total, payment_method, note, create_date, update_date, order_date, payment_date, currency_code, complete_message, complete_mail_message, trans_code, gmo_epsilon_order_no, customer_rank_id, customer_rank_name, add_point, use_point, customer_id, country_id, pref_id, sex_id, job_id, payment_id, device_type_id, order_status_id, payment_status_id, regular_order_id, discriminator_type) VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20, $21, $22, $23, $24, $25, $26, $27, $28, $29, $30, $31, $32, $33, $34, $35, $36, $37, $38, $39, $40, $41, $42, $43, $44, $45, $46, $47) |
sw_sn |
投稿日時: 2025/3/1 21:44
対応状況: −−−
|
常連 ![]() ![]() 登録日: 2018/5/25 居住地: 投稿: 50 |
Re: データベース(RDS)でのデッドロックについて MySQLでもデッドロックが発生したことがありますので、lockするコードに課題があるのだと考えています。
https://github.com/EC-CUBE/ec-cube/blob/801f6704219831b22648ca52c5a7695e89e07228/src/Eccube/Service/PurchaseFlow/Processor/StockReduceProcessor.php#L81-L101 おそらく原因はここら辺りなのでコードを修正するか、try catchでエラーを捕捉して、エラーが発生したらリトライさせるのが良いと思いました。 |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |