Access MySQL on AWS RDS
When adding API (Apache+Fuel PHP) and performing load test
While Apache stopped accepting connections,
Waiting for RDS logs on RDS performance insights
synch/cond/mysys/my_thread_var::suspend
It seems that the lock has occurred.
The new MySQL code is as follows
INSERT INTO user_states
(user_id, x, y, state)
VALUES ('xxxxxxxx', 100, 200, 0)
ON DUPLICATE KEY UPDATE
x = VALUES(x), y = VALUES(y), state = VALUES(state)
If you have a record of user_id, use the code
Create if you don't update x,y,state.
This will flow asynchronously to the API for multiple user_ids containing duplicates
Table DDL has a unique index of user_id apart from PK below
CREATE TABLE `user_states`(
`id`int(11) NOT NULL AUTO_INCREMENT,
`user_id`varchar(255) NOT NULL,
`x`decimal(9,6) NOT NULL,
`y`decimal(9,6) NOT NULL,
`state`int(11) NOT NULL DEFAULT '1',
`created_at`datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at`datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY(`id`),
UNIQUE KEY `index_user_states_on_user_id`(`user_id`)
ENGINE=InnoDB AUTO_INCREMENT=nnnnn DEFAULT CHARSET=latin1
I don't know if this query is the cause, but it's one of the features that I recently added. Is there a way to determine the cause of the lock on the RDS?
Also, if there is any problem with SQL or tables, please let me know
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html
sync/cond/mysys/my_thread_var:suspend
For this wait event, the thread is stopped while waiting for the condition.For example, this event occurs when a thread is waiting for a table-level lock.It is recommended that you examine the workload to see which threads might get the table lock for the database instance.MySQL
For more information about table locking in , see Table Lock Problems in the MySQL document.
sync/cond/mysys/my_thread_var:suspend
It's not like a deadlock has occurred.
Wait event indicating that the thread is suspended due to another lock occurring.
Once unlocked, it will automatically resume and process.
In parallel testing performed by the questioner
"Since ""Insert may come from user ID at the same time,"" it seems that INSERT processing is running in parallel for the same user_id, so it's a line lock level, but I think there will be a lock waiting."
This is not something that can be eliminated, and I think we have to accept it with this production.
If the requirement is that you can't even wait for the line lock waiting time at INSERT,
If the unique constraint of user_id has been stopped, why don't you try to INSERT it all the time to refer to the latest created_at on the SELECT side instead of UPDATE it?
This increases the amount of data and the load during SELECT, but eliminates the line lock latency during INSERT.
© 2024 OneMinuteCode. All rights reserved.