I have finally found the culprit. By coincidence, I had the same configuration running on two servers, one backed with a SSD, the other with a HDD.
The same commit worked on the SSD-backed server, and always failed on the HDD one with the described error.
Monitoring the process revealed that after the file transfer of the commit completes, server starts finalizing. Not sure what exactly happens during that period serverside (maybe someone can explain?), but for a 40k files commit, it took the SSD-backed one to complete in about 30 seconds, while the HDD-backed one struggled more than 30 minutes. During those 30 minutes, the client got no response, so it timed out, which resulted in the described error on the server side.
Anyway, setting http-timeout = 3600 in the "servers" file fixes the issue permanently (tested it 2 times to make sure). I think the default is 10 minutes.
Also, I am quite surprised at the performance penalty when using a HDD at this stage. Any way to tweak this for low memory servers?
On 21 February 2018 at 16:27, Philip Martin <philip_at_codematters.co.uk<mailto:philip_at_codematters.co.uk>> wrote:
Davor Josipovic <davorj_at_live.com<mailto:davorj_at_live.com>> writes:
> You make the PID sound very important, and with good reason too! I
> just went back through the logs to make sure that I didn't mess up the
> PID before posting. I didn't. In each case, the PID was
> different. This might explain the time difference.
The Subversion client can make multiple http connections, particularly
when a commit involves a large number of files. It is not unusual for
multiple PIDs to handle the requests for any one commit.
> I'll look further into this later. The default Debian apache2 install
> came with mpm_event enabled. According to my logs I switched to
> mpm_prefork later (due to performance reasons recommended for an other
> module).
Prefork is typically the lowest performace for Subversion. Subversion
server performance will generally be better with a small number of
processes each with a large number of threads as this allows you to
increase the size of the per-process Subversion cache.
--
Philip
Received on 2018-05-21 22:12:54 CEST