Назад | Перейти на главную страницу

Как я могу настроить Artifactory 2.6.x на использование меньшего объема памяти?

Моя команда использует JFrog Artifactory 2.6.7.1 Pro. У нас есть планы по обновлению до 3.x, но они замедляются по нетехническим причинам.

В то же время наша установка 2.6.x использует более 190 ГБ диска. Большая часть этого находится в репо / данных / хранилище файлов.

Я уже выполнил следующие варианты обслуживания и освободил часть диска:

Я специально рассмотрел настройку «снимки для хранения» для репозиториев, которые могут иметь снимки. Было установлено разумное значение (менее 10) для этих репо.

Какие настройки мне следует проверить, чтобы освободить место на диске?

Некоторые из упомянутых вами операций (удаление кешей, удаление неиспользуемых данных и т. Д.) Являются разовыми операциями, которые могут иметь некоторый временный эффект, но я не уверен, насколько они полезны при нормальной работе. В конце концов, кеши есть не просто так.

Другие, такие как GC, по умолчанию запускаются Artifactory (например, GC запускается каждые 4 часа).

Все детали управления хранилищем перечислены в одном Страница руководства пользователя Artifactory.

На практике есть 5 вариантов конфигурации, которые помогут вам контролировать размер хранилища. на регулярной основе:

  • Настройте политику очистки снимков.
  • Удалите неиспользуемые кэшированные артефакты.
  • Удалите старые сборки с помощью подключаемого модуля Jenkins Artifactory.
  • Напишите сценарий, который использует вызовы очистки REST API.
  • Напишите пользовательский плагин, который реализует любую логику очистки, подходящую для вашего случая. вот несколько примеров чтобы вы начали.
  1. вам нужно переместить резервную копию сервера artifactory с другого сервера, это даст вам больше места.
  2. ИСПОЛЬЗУЙТЕ AQL для управления проблемами очистки.

Сначала давайте найдем старые артефакты, созданные более года назад (при условии, что сегодня 18 мая 2015 г.). С AQL это просто: items.find({"type":"file", "created":{"$lt":"2014-05-18T"}})

Обратите внимание, как мы можем использовать операторы сравнения, такие как «$ lt», с датами, и что мы пользуемся преимуществом встроенного в AQL значения по умолчанию, согласно которому несколько критериев объединяются с использованием «$ и».

хочет удалить что-то, если оно не загружалось в течение последних 6 месяцев: давайте добавим еще один критерий к нашему запросу, на этот раз используя поле «скачано» в домене «stat»:

items.find({"type":"file", "created":{"$lt":"2014-05-18T"}, "stat.downloaded":{"$lt":"2014-11-18T"}})

если вы хотите убедиться, что ничего важного не удалено, он пропустит «освободить» репозитории. items.find({"type":"file", "created":{"$lt":"2014-05-18T"}, "stat.downloaded":{"$lt":"2014-11-18T"}, "repo":{"$nmatch":"*release*"}})

Здесь мы добавили критерий, согласно которому имя репозитория не включает шаблон «релиз». Обратите внимание: если у вас есть репозиторий, в названии которого есть слово «release», но это не репозиторий выпуска… он также будет пропущен, и вы можете пересмотреть свое соглашение об именах.

«Большие» артефакты размером более 1000 байт.

Итак, вот последний запрос AQL, который находит в системе все артефакты, отвечающие всем этим критериям: items.find({"type":"file", "created":{"$lt":"2014-05-18T"}, "stat.downloaded":{"$lt":"2014-11-18T"}, "repo":{"$nmatch":"*release*"}, "size":{"$gt":"1000"}})