We recently migrated our few HG repositories to RhodeCode community server. It’s very small installation: 5 repositories and 2 registered users.
After repositories migration we also change VCS roots in our TeamCity build server.
After that we were observing that RhodeCode is almost unusable: webpage was unresponsive (sometimes didn’t load at all), push/pull requests sometimes took tens of seconds…
By checking machine health, I found out that VCS Server process almost constantly hands one CPU. It also ate all memory and swap. (see screenshot attached)
Hardware configuration: Intel Xeon @ 2 GHz, 2 GB RAM, 2 GB swap, SAS disk (all virtualized), OS Ubuntu Server 16.04
RhodeCode configuration:
we use sqllite (tried postgre, same issue)
we use anonymous access to repositories (it’s inside of VPN network)
5 repositories (2 are quite big - 850 and 300 megabytes)
TeamCity server checks 4 of this repositories, every 60 seconds.
Is that normal behavior? Can I do anything about it? Can I send some logs or something?
It’s not normal. I think it’s easily fixable by changing the workers configuration. Please check inside rhodecode.ini how many workers you have ? I’d recommend using 5-6 workers, for you setup.
Then you have to increase threadpool on vcsserver config based on the formula specified there.
ps, on a side note we’d be shipping much more efficient backend in 4.3 release that would additionally speed things up. Until then the configuration i posted should help.
However, I was not very successful with setting up configs you mentioned. I set number of workers to 5 and thread pool to 240 (I was experimenting with this number, but seems it does not affect my problem).
See last screenshot from htop. It ate all available memory and almost both CPU (see ‘Load average’ part).
I also noticed that supervisord takes a lot of CPU…
I did all steps, but in supervisord.ini config for VCS server is vcsserver_http.ini (I suppose you meant that).
What I get now is HTTP Error: 500 (Internal Server Error).
I can see from logs that community service is not able to connect to VCS server. And in vcsserver.log I see that is listening on port 9900, instead of 10001 (defined in config file).