d4d564c8e7
after the request. This way, we could release the project referred from the controller, which potentially referred a repository which potentially allocated a lot of memories. Before this change, we could hold the last request data and cannot release the memory. After this change, the largest request data should be able to be collected from GC. This might not impact the instances having heavy load, as the last request should be changing all the time, and GC won't kick in for each request anyway. However it could still potentially allow us to free more memories for each GC runs, because now we could free one more request anyway. |
||
|---|---|---|
| .. | ||
| api | ||
| backup | ||
| banzai | ||
| bitbucket | ||
| constraints | ||
| container_registry | ||
| gitaly | ||
| gitlab | ||
| google_api | ||
| json_web_token | ||
| mattermost | ||
| microsoft_teams | ||
| rspec_flaky | ||
| system_check | ||
| additional_email_headers_interceptor_spec.rb | ||
| after_commit_queue_spec.rb | ||
| disable_email_interceptor_spec.rb | ||
| event_filter_spec.rb | ||
| expand_variables_spec.rb | ||
| extracts_path_spec.rb | ||
| feature_spec.rb | ||
| file_size_validator_spec.rb | ||
| gitlab_spec.rb | ||
| milestone_array_spec.rb | ||
| repository_cache_spec.rb | ||
| system_check_spec.rb | ||