Discussion for Merge Request is not shown

Summary

Discussion for Merge Request is not shown

Steps to reproduce

Open: Project - Merge Requests - Request - Discussion

Example Project

What is the current bug behavior?

If Discussion has a lot of comments (over 60), error appeares: and comment count start to show 0 instead of real. If less (15-20), everything work OK and I can see all comments.

What is the expected correct behavior?

All comments are visible

Relevant logs and/or screenshots

unicorn_stderr.log

E, [2018-10-16T09:55:19.562853 #813] ERROR -- : worker=4 PID:9858 timeout (61s > 60s), killing
E, [2018-10-16T09:55:19.602713 #813] ERROR -- : reaped #<Process::Status: pid 9858 SIGKILL (signal 9)> worker=4
I, [2018-10-16T09:55:19.876512 #12748]  INFO -- : worker=4 ready

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:         Debian 9.5
Current User:   git
Using RVM:      no
Ruby Version:   2.4.4p296
Gem Version:    2.7.6
Bundler Version:1.16.2
Rake Version:   12.3.1
Redis Version:  3.2.11
Git Version:    2.18.1
Sidekiq Version:5.1.3
Go Version:     unknown
GitLab information
Version:        11.3.5
Revision:       c74e8d9
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
URL:            http://gitlab.t1.tenet
HTTP Clone URL: http://gitlab.t1.tenet/some-group/some-project.git
SSH Clone URL:  git@gitlab.t1.tenet:some-group/some-project.git
Using LDAP:     yes
Using Omniauth: no
GitLab Shell
Version:        8.3.3
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

@taras.scherban The request is timing out, this shouldn't be the case for a 60 comment thread. What are the available resources on this host?

added awaiting feedback support request labels

Hardware conf: 8 Core x Inlel Xeon 5650 24Gb RAM And of course, I have enough free space on disk.

Server is not highly loaded

Are you able to provide the GitLab config file? /etc/gitlab/gitlab.rb Please ensure that any sensitive information is removed before posting it.

Please also perform the check as requested in the bug template:

Run a diagnostic check of GitLab and it's components:

sudo gitlab-rake gitlab:check

check.txt

gitlab.rb

Is any update for this problem? Today I installed 11.3.6 but nothing changed.

You should be able to make it work by increasing the unicorn timeout threshold, but there must be something else going on with this instance to be causing a timeout for such a small discussion:

• https://docs.gitlab.com/omnibus/settings/unicorn.html

We had a MR with just 14 comments and encountered the same error. I increased the unicorn worker_timeout to 120s and now we can view the discussion again.

unicorn['worker_timeout'] = 180 helps me too. For 129 comments in discussion. But fetching is too slow, keeps more then 2 minutes to show discussion content. Is there any posibility to fix this situation?

added Create [DEPRECATED] bugperformance devopscreate merge requests labels

You could enable the performance bar and share the query:

• https://docs.gitlab.com/ce/administration/monitoring/performance/performance_bar.html

SQL queries screen not scrollable and permanent "grey", but I can give you first screen: gitaly calls

The ruby gc processes to build the discussions.json takes the most time. Everything else is neglectable. The wall clock though is about 70 to 80 seconds until the discussion posts are displayed.

During rendering the page one unicorn worker process runs at 100%.

@oswaldo Please could you take a look in on this issue?

mentioned in issue #52784 (moved)

Out of curiosity, do you have Prometheus enabled on this instance @mir06 @taras.scherban? Have you noticed this happening after any particular release?

I've created https://gitlab.com/gitlab-org/gitlab-ce/issues/52950 which might help here.

marked this issue as related to #52950 (closed)

No. We are using Zabbix. It happened (users began to complain) after update to 11.3.5

Thx @oswaldo Yes, we have prometheus enabled but there is no difference if I temporarily disable it. In the meantime the discussion has 30 posts and 120s is to short to build the discussions.json. Therefore I cannot provide the statistics from the progress bar.

Unfortunately I don't know when this behavior occurred the first time. It happened already in 11.2.3.

Thanks for the information! So I guess this predates the Gitaly switch (the usage of our git service). We've been continuously improving ~performance on these pages and in 11.4 we've done https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22153. I'd be happy to see if that positively impacts the loading time in your instances.

Additionally, we should be able to considerably improve the loading time with https://gitlab.com/gitlab-org/gitlab-ce/issues/52950.

@DouweM FYI: this is related to https://gitlab.com/gitlab-org/gitlab-ce/issues/52950

@oswaldo Are you confident that highlighting the diff discussion diffs is what's slowing down these discussions.json requests so much? I thought we recently started loading the diffs asynchronously.

mentioned in merge request gitlab-com/gitlab-profiler!43 (merged)

@DouweM Yep, we're talking about the discussions.json request (which still handles highlighting). Stan left an interesting profile here and I'm adding a new url to the profiler with this MR gitlab-com/gitlab-profiler!43 (merged). Let's confirm :)

@oswaldo We updated to 11.4 but there is no improvement at all. With increased number of disussion posts I even had to increase the worker_timeout again.

Sorry about that @mir06. We're looking forward to improve that as soon as possible with https://gitlab.com/gitlab-org/gitlab-ce/issues/52950.

Dear @oswaldo, I did not follow the development in the last weeks but now I can confirm that the discussions are displayed very quickly. I am running version 11.6.1-ce.0. Many thanks for your support.

11.7.5, still able to reproduce 502 on discussions.json. MR has 143 comments. What's the plan to address? Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/42493?

We are experiencing a similar issue in our local installation.

The gitlab-rails/production.log reads:

Completed 500 Internal Server Error in 1310ms (ActiveRecord: 40.1ms)

NoMethodError (undefined method `index' for nil:NilClass):

app/models/concerns/discussion_on_diff.rb:48:in `truncated_diff_lines'

Currently the refferenced line in source code reads:

initial_line_index = [diff_line.index - diff_limit + 1, 0].max

So it seems that diff_line.index can be nil under certain circumstances.

Maybe this can help to track down the issue.

added [deprecated] Accepting merge requests label

added groupsource code label

removed [deprecated] Accepting merge requests label

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue