В настоящее время я испытываю проблемы во время большой проверки полного хранилища 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".
Недавно мы столкнулись с этой проблемой. До сих пор я думаю, что это связано с более новыми клиентами подрывной деятельности.
Директива Apache dav_svn_module
SVNAllowBulkUpdates Prefer
Кажется, поможет. После добавления в apache conf проблем не обнаружено. До этого большая часть больших проверок не удалась.
Я нашел дискуссионный поток, который объясняет проблемы, связанные с клиентами subversion, которые новее, чем версия 1.8.x. См. раздел списка рассылки.
У меня были следующие ошибки:
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
Это, по-видимому, проблема с кодировкой файлов в соответствии с этот пост в списке подкатегорий subversion. Вы можете искать записи AddEncoding x-gzip .gz в своей конфигурации apache и удалять их или добавлять в свою запись <Location /svn>…</Location>:
RemoveEncoding .gz
RemoveEncoding .Z
Это было актуально упомянуто в журнал изменений, но я тоже не хотел читать это и усвоил этот трудный путь...
Я столкнулся с той же проблемой, которая пыталась выполнить проверку 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, так и на хосте обратного прокси.
Проблема может быть связана с "дефляцией", но я также отключил ее, как предложил Тим С., и это также не повлияло. Причина, по-моему, может быть связана с тем, что после устранения ошибки я заметил, что количество переданных байтов значительно больше, чем раньше.