Defect #40963
open
Redmine freezes when receiving certain requests.
0%
Description
We have updated the redmine version.
We have moved from 4.0.5.stable to 5.1.3.stable.
The migration process has been:
1. Debian GNU/Linux 12 (bookworm)
2. Rails 6.1.7.8
3. Puma version: 6.4.2 (ruby 3.2.4-p170)
4. Download the new version
5. Replacement with previous files (config, files)
6. Database deployment in mysql 5.7
7. Change of parameter "transaction_isolation="READ-COMMITTED" in DB.
8. Downloading updated versions of the plugins
9. Download updated version of theme
10. Execution of update processes:
bundle exec rake db:migrate RAILS_ENV=production
bundle exec rake redmine:plugins:migrate RAILS_ENV=production
After this, the installation seems to work correctly but there are times when some requests freeze.
I have identified a request that always gets stuck.
When I access the "time spent" section of a specific task (it has many imputed hours > 8000) the response takes about 5s.
Two "puma" processes arise, occupying 100% of the CPU and end up responding correctly but after that 5s delay.
Files
Updated by Aziz El Bahyaoui about 1 month ago
- File redmine-40963.pdf redmine-40963.pdf added
Santiago Bellas Carballo wrote:
We have updated the redmine version.
We have moved from 4.0.5.stable to 5.1.3.stable.
The migration process has been:1. Debian GNU/Linux 12 (bookworm)
2. Rails 6.1.7.8
3. Puma version: 6.4.2 (ruby 3.2.4-p170)
4. Download the new version
5. Replacement with previous files (config, files)
6. Database deployment in mysql 5.7
7. Change of parameter "transaction_isolation="READ-COMMITTED" in DB.
8. Downloading updated versions of the plugins
9. Download updated version of theme
10. Execution of update processes:
[...]After this, the installation seems to work correctly but there are times when some requests freeze.
I have identified a request that always gets stuck.
When I access the "time spent" section of a specific task (it has many imputed hours > 8000) the response takes about 5s.
Two "puma" processes arise, occupying 100% of the CPU and end up responding correctly but after that 5s delay.
Updated by Santiago Bellas Carballo 26 days ago
I have researched this topic more.
The problem is that the main task view loads all assigned time entries by default, without pagination.
This process blocks the application when there are many entries (> 8000 in this case)
The loading of assigned hours is only done by default if the task does not have comments or history since if it has any of these elements the initial loading is done with the comments and the assigned time is not requested.
The time spent tab should have some type of pagination to avoid causing this problem.