Nexus Repository Manager 3.14 с производительностью хранилища больших двоичных объектов Ceph

Я настроил NXRM 3.14 с ceph (совместимым с S3) хранилищем больших двоичных объектов. Я тестировал его как на физическом оборудовании, так и внутри док-контейнера.

Это «работает», но намного, намного медленнее, чем загрузка напрямую в корзину (2-секундная загрузка напрямую в корзину может занять 2 минуты через NXRM).

Я не нашел никаких ошибок или жалоб по этому поводу, поэтому я предполагаю, что это специфично для ceph и что производительность может быть хорошей с S3. Загрузка в локальную файловую систему также очень быстрая.

Я не нашел в файлах журналов ничего, что указывало бы на проблемы с производительностью.

Извините, этот вопрос крайне расплывчатый, но есть ли у кого-нибудь рекомендации по отладке производительности NXRM или, может быть, кто-нибудь использует аналогичную настройку? Спасибо.


person Kendall Trego    schedule 10.12.2018    source источник


Ответы (1)


В конце концов я отследил это в открытом исходном коде NXRM, текущий MultipartUploader является однопоточным (https://github.com/sonatype/nexus-public/blob/master/plugins/nexus-blobstore-s3/src/main/java/org/sonatype/nexus/blobstore/s3/internal/MultipartUploader.java) и последовательно загружает фрагменты.

Для файлов размером более 5 МБ это приводит к значительному замедлению времени загрузки.

Я отправил предложение по улучшению их системы отслеживания проблем: https://issues.sonatype.org/browse/NEXUS-19566

person Kendall Trego    schedule 02.04.2019