Большая проверка SVN происходит спорадически

В настоящее время я испытываю проблемы во время большой проверки полного хранилища SVN (20 ГБ +), где процесс проверки останавливается случайным образом. Репозиторий состоит из множества небольших текстовых файлов и нескольких больших файлов CSV.

Трудно было сузить вопрос, поскольку ошибка выходила всего на несколько часов в кассе. Из того, что я видел, это не определенный файл, который останавливает процесс и проверяет использование svnadmin, не возвращает никаких ошибок.

Ошибка:

Типичный журнал ошибок Apache:

Unable to deliver content.  [500, #0]
Unable to deliver content.  [500, #0]
Could not write data to filter.  [500, #175002]
Could not write data to filter.  [500, #175002]
Provider encountered an error while streaming a REPORT response.  [500, #0]
A failure occurred while driving the update report editor  [500, #730053]

Технические характеристики:

Сервер: Windows Server 2003 с XAMPP v1.8.2-5, Apache v2.4 и SVN v1.8.9. Он был недавно обновлен с Apache v2.2 и SVN v1.5.3, который испытывал подобные проблемы.

Клиенты: в Windows 7 запущена TortoiseSVN v1.8.8 x64, недавно обновленная с v1.8.3 x64, которая испытывала подобные проблемы. Командная строка SVN v1.8.9.

Я использую протокол HTTP для выполнения проверки.

Что я пробовал:

Установка директивы "TimeOut" на Apache на более высокое значение (до 30000 секунд).

Установка директивы "SVNAdvertiseV2Protocol" на выключение.

Отключение директивы "SVNPathAuthz".

Настройка директивы SVNCompressionLevel на "0".

Ответ 1

Недавно мы столкнулись с этой проблемой. До сих пор я думаю, что это связано с более новыми клиентами подрывной деятельности.

Директива Apache dav_svn_module

SVNAllowBulkUpdates Prefer

Кажется, поможет. После добавления в apache conf проблем не обнаружено. До этого большая часть больших проверок не удалась.

Я нашел дискуссионный поток, который объясняет проблемы, связанные с клиентами subversion, которые новее, чем версия 1.8.x. См. раздел списка рассылки.

Ответ 2

У меня были следующие ошибки:

Unable to deliver content.  [500, #0]
Could not write data to filter.  [500, #175002]

Я даже не использовал mod_deflate, чтобы этого не могло быть. В моем случае это оказалось аутентификацией (auth_digest_module), вызвавшей ошибку. Если a checkout длится более 300 секунд, я бы зарегистрировал ошибку выше в моем журнале сервера Apache.

Проблема - это директива по умолчанию AuthDigestNonceLifetime 300. См. здесь. Мое решение состояло в том, чтобы установить эту директиву в бесконечность: AuthDigestNonceLifetime -1

Ответ 3

Это, по-видимому, проблема с кодировкой файлов в соответствии с этот пост в списке подкатегорий subversion. Вы можете искать записи AddEncoding x-gzip .gz в своей конфигурации apache и удалять их или добавлять в свою запись <Location /svn>…</Location>:

RemoveEncoding .gz
RemoveEncoding .Z

Это было актуально упомянуто в журнал изменений, но я тоже не хотел читать это и усвоил этот трудный путь...

Ответ 4

Я столкнулся с той же проблемой, которая пыталась выполнить проверку snv в репозитории с умеренным размером (500 МБ), используя сервер, состоящий из клиентов Centos 7.4.1708, Apache 2.4.6, Subversion 1.9.15 и Windows 10 с использованием TortoiseSVN 1.9. 7 из-за обратного прокси-сервера Apache.

Решение для меня заключалось в том, чтобы добавить SVNAllowBulkUpdates Off, аналогичный ответу teori. Я попытался использовать "SVNAllowBulkUpdates Prefer", но когда я перезапустил httpd, он высказал ошибку: "SVNAllowBulkUpdates должен быть включен или выключен". Мой последний файл конфигурации SVN/Apache:

<Location /svn >
    DAV svn
    SVNParentPath /svn
    SVNAllowBulkUpdates Off
    AuthType Basic
    AuthName "SVN Repo"
    AuthUserFile /var/svn/svn-auth-user
    Require valid-user
</Location>

Другие мысли: Я не верю, что настройки Timeout и AuthDigestNonceLifetime напрямую связаны с проблемой. Я пытался их использовать, но ни один из них не имел никакого эффекта. Я специально экспериментировал с настройками Timeout, keepalive и keepalivetimeout как на хосте SVN, так и на хосте обратного прокси.

Проблема может быть связана с "дефляцией", но я также отключил ее, как предложил Тим С., и это также не повлияло. Причина, по-моему, может быть связана с тем, что после устранения ошибки я заметил, что количество переданных байтов значительно больше, чем раньше.