Hi Joe,
How is it going ?
Have you moved the needle forward ?
Seeing you're running on a VPS, my guess would be an I/O saturation or
big latency, causing subversion taking a very long time to acknowledge
the file has securely been written down on the "hard drive". I've
experienced this quite a lot, and this might be related and due to
many things. I will briefly explore some of them, but I'm still
puzzled this might take up to 15 minutes to commit something to your
server. This is hugely slow.
So, it could be that your neighbor makes a strong usage of the I/O
subsystem, putting the host to their knees. This might be due to the
neighbor's VPS swapping very much because they don't have enough RAM
in their instance. This may also be tied to their specific use of the
VPS, which might be I/O bound.
Also, it could be that the physical host doesn't have a physical drive
enclosed. I've used VPS at a provider where the I/O subsystem is over
some specific block-based low-latency network. This enables them to
switch hosts where your VPS runs without having to move nor backup the
base system of your VPS. This is very convenient, but also brings a
lot of downside, depending on your use case. The latency might be much
more high than direct access. Performance wise, it is also less stable
and predictable. It might stall or slow down if a lot of hosts access
their storage system.
This also brings to a key point that svn extensively uses the
synchronization directive to ensure that the data is really written on
the hard disk. We don't want a power outage to happen during a commit,
while the svn report the commit succeeded, but the hard drive lost the
data, as the data was just on the write cache, not on the hard disk.
Take this requirement and put it on a networked storage system playing
around with tens of VPS per host, on tens to hundreds of hosts, and it
becomes hard, and long, to get the guarantee back that your write
request is successfully fulfilled. Also, I've noticed, in one of my
providers at least, that these network storage systems are
block-based. This is sound. But if you now send a "relatively big
file" across a cluster of storage servers, and ask for
acknowledgement, each block has to be acknowledged. This might also
cause delay. Yet, this doesn't explain the 15 minute delay.
On top of that, what is the filesystem used on your VPS ? Some might
not handle gracefully a lot of files. How much commit do you have in
your repositories, and thus, how much files ? I don't know if it might
be an issue as well, but who knows, some VPS get strange initial
setups. You might give a look at this direction too.
This is just some clues (on the operating system side) and would
require more investigation on your VPS, both on the subversion
configuration and on the operating system configuration. I know you
don't want to spend time on it and would prefer to contract it away,
just to get it solved. I don't know the thing like the back of my
hand, but I believe to be quite knowledgeable on the subject. I don't
have time right now, but I've planned to reinstall three svn servers
by February 2021, which one targeted for big files retention, and
definitively could cram in some hours to take care of your server, if
you haven't found a solution by then.
Regards,
Pierre
Le ven. 4 déc. 2020 à 18:33, William Muriithi
<william.muriithi_at_gmail.com> a écrit :
>
> Hi Joe,
>
> Other things you should look into:
> - Do you have svn triggers that could be taking too long to execute?
> - Is your authentication setup sufficient/quick?
> - Apache has enough resources or is it swapping?
>
> Regards,
> William
>
> On Fri, 4 Dec 2020 at 08:41, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> >
> > On Thu, Dec 3, 2020 at 4:53 PM Joe Strout <joe_at_luminaryapps.com> wrote:
> > >
> > > I've got a svn server running on a linux VPS. It works, but it is often
> > > very very slow... like, 15 minutes to commit a 5 MB file. Often it
> > > times out completely, and we have to svn cleanup and try again.
> >
> > Which Subversion verison? Which Linux operating system? And how big is the repo?
> >
> > One of the difficulties with Subverison is the difficulty of expunging
> > bulky old commits, even from branches or files that have been deleted.
> >
> > > There is nothing else running on that virtual machine, and we've checked
> > > with the hosting company, and they claim they are not throttling our
> > > bandwidth. I believe it's probably something wrong with our
> > > configuration. Also we're connecting via https, because that's the
> > > protocol I'm most familiar with, but some other protocol might be better
> > > (I know the http layer brings its own limitations). I lack the time,
> > > and mostly lack the background, to figure this out myself.
> >
> > HTTPS has advantages of being readily available, well supported, and
> > rarely throttled. It has the disadvantage that it's often intermingled
> > with a lot of other peculiar web setups.
> >
> > > I'm looking to hire somebody who knows this stuff like the back of their
> > > hand, to spend a few hours checking our setup, maybe helping us switch
> > > to another protocol, and generally making svn run like the champ that I
> > > know it can be.
> >
> > Can't take it on, I have a job. But if you provide a few details, such
> > as the Subversion releases and the *size* of the repository in
> > question, it might provide some hints.
> >
> > > (For what it's worth, I use command-line svn on Macs, and others on the
> > > team are using TortoiseSVN on Windows.)
> >
> > Right, you have contemporary clients. Do you have shell access to the
> > Subversion server itself to audit it for the subversion repositories,
> > their size, and their subversion version? Those are the questions a
> > sensible consultant would want to ask.
> >
> > > Thank you,
> > > - Joe
> > >
> > > --
> > > Joe Strout
> > > Luminary Apps, LLC
> > > http://www.LuminaryApps.com
Received on 2020-12-08 21:50:26 CET