Медленная работа NextCloud с большим количеством маленьких файлов

А как Некстклауд разворачивал? В Докере? А МарияДБ где? В другом докере? А опции запуска какие? Короче, больше технической информации нужно. А то знающие люди не подтянутся. (я не знающие люди, я просто рядышком посижу с тетрадочкой)

Некстклауд разворачивал вручную из архива, не из snap, апач2, php 7.2 со всеми модами, mariadb. Не понял насчет «Докера», хто это ? В каком другом «Докере» ? Опции запуска чего ? Там строчка про котёнка была...

Сейчас просто мода всё в докерах делать. Вот я и подумал.

Вообще, с маленькими файлами даже при копировании с диска на диск может люто тормозить. Периодически всплывают такие темы, но решения я что-то не вижу, только «смени ФС», «смени хард», «смени дистрибутив», да «смени ОС».

Не уверен, что проблема в базе данных, или сети. А какие опции монтирования ФС?

Хранилище потихоньку нарастает

Если есть «статичные» папки в твоём хранилище, мож их за-squashfs-ить и примонтировать образы вместо самих папок. Файлово-инодные таблицы squashfs значительно производительней таблиц любых др. фс.

Я понимаю что маленькие файлы - это больше нагрузки на ФС, и действительно за всю мною изученную историю этого вопроса боле менее внятного решения предложено не было, насчет базы данных это свои соображения, потому-что, повторюсь, при прямой записи на сервер минуя работу некстклоуда проблем со скоростью нет, и на мой недалёкий взгляд отличие как раз вмешательство работы БД, или же какой-то скрипт лишний синхронизации самого некстклоуда. Насчет опций монтирования совсем не понимаю, какие опции, при установке убунту поставил во все разделы системного диска (/, /swap, /home ) ехт4 и сразу там же смонтировал райд1 в ехт4, при запуске системы сделал синхронизацию дисков и все.

Для начала я бы сравнил наливание, скажем, 10000 4k файлов через NextCloud и, например, через SCP/SFTP

гиговая папка с парой тысяч файлов может 4-5 часов заливаться

Для каждого файла делается один и тот же процесс

- открыть файл для записи - ... - закрыть файл - записать про файл в базу данных

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

Во-вторых, если у тебя прям тыщщи файлов - может диск сильно фрагментирован?

В-третьих, какие еще процессы запущены на этом сервере? Торренты качаются/раздаются? Менял ли в настройках inotify циферки?

Nginx+phpfpm с небольшим тюнингом скорее всего будет работать побыстрее. Плюс проверь включен ли кэш записи на диске. В идеале иметь ssd или raid10.
А вообще, потыкай seafile - он по скорости куда лучше.

Диск, точнее рэйд,из абсолютно новых дисков, пару раз переформатировались при экспериментах с разным типом хранилища и ошибочными действиями, фрагментация исключена.Пока в системе только ламп + некстклоуд, чуть позже подсядут пара сайтиков. Опять же, пока стояла самба, вопроса о скорости вообще не возникало, обмен данными происходил ну может чуть медленнее хорошей флэшки, и скорость практически не зависела от количества файлов, по крайней мере визуально все было приемлемо. Но от самбы и фтп пришлось отказаться, сложно блондинке с разных компов, к которым у меня доступа нет, фтп туннели строить, а заниматься всякими синхронизациями постоянно да хлам разгребать тоже особого желания нет. Вопрос про базу данных возник из теста из первого поста по ссылке. Но не понимаю механику работы БД в некстклоуде, толи он ее использует как и положено только для хранения данных об аккаунтах, толи в каждом аккаунте каждый файл еще прописывает. Inotify не трогал, слишком страшный зверь для меня.

Потыкал теорию seafile, вкусный конечно, но безфайловое хранилище ставит для меня многие ограничения, к примеру как отсутсвтие шары отдельного файла,а с надстройкой seaf-cli становится слишком сложной и тяжелой ношей, это скорее для профессионалов с их корпоративными хранилищами. Насчет Ngnix тоже много букав прочитал, может и будет профит, но не думаю что настолько весомый, ну будет он не 5 часов качать а 4.5, хотя пожалуй попробую, пока заливаю только для проверки, основная масса лежит по всем углам на 10-15 летних хардах, да и родственники уже ложками стучат когда открою врата помойки. Рэйд 10 как и SSD никак не укладывается в мое представление о бюджете домашнего сервака, 12к за пару 2-терабайтника и так слишком тяжелая покупка была, да и, как и писал выше, реальная скорость дисков высока и никак не является ботлнеком, вот единственное выяснить бы точно, что именно запись и синхронизация данных с БД, которая висит на отдельном системном ноутбучном диске, так тормозит загрузку, тогда под систему можно было бы взять ССД простенький, ну и плюс изучаю знания о тюнинге MySQL. И, простите за нескромный вопрос... А как проверить включен ли кэш на дисках ? Тестирование скорости диска показывает что кэш есть и скорость его огромна, но работает ли он в рэйде при обычной нагрузке я не знаю.

Решил проверить на своем Nextcloud 15 загрузку в него мелких фалов где-то 600МБ. Проц G4560, raid1 из двух 4TB 5200 WD RED. Система и БД на SSD, Apache и сам Nextcloud в рейде. Канал 1GB.

Когда загружаю папку с файлами через браузер - пишет 4 часа. И htop выглядит как-то так: https://i.ibb.co/R7kx73f/Screenshot-1.png Видно, что по сути только 1 процесс Mysql и Apache загружены.

Но когда через Nextcloud Client (под виндой) загружаю ту же папку - ситуация другая: https://i.ibb.co/vsTp6FD/Screenshot-2.png Загрузка 30-40 минут.

Так что юзать нужно клиент, и все будет отлично.

в общем случае проблема нерешаемая, так как все это дело работает поверх https/http. оверхед на каждый мелкий файл очевиден.

Вот бы кто с нжинксом проверил бы. Интересно было бы.

Если очень хочется много маленьких файлов, то цепляйте хранилище некстклауда по самбе/нфс/ссш и заливайте. После успешного залива есть консольная команда для обновления файлового индекса, которая ищется в манах. Наверное это можно как-то автоматизировать. Сам использую клиент некстклауда. Можно подцепить вебдав, но он тоже тормозной.

Спасибо конечно за совет, но клиент крайне неудобен, мне не нужно синхронизировать папки, мне нужен просто файл менеджер для закачки из разных мест, в этом клиенте простую выгрузку из папки А в папку Б я не нашел, а вот мысль насчет мониторинга помогла. Перебрал несколько WebDav клиентови остановился на киберутке, которая оказалась быстрее тоталкоммандера с плугином. Сравнил скорость закачки одной папки 60мБ 150 разносортных файлов, встроенный в винду webdav клиент netuse заливал 3 минуты ровно (и тут возникает много негатива, причем за много лет как оказалось ничего особо не меняется у мелких, зачем за то что удобно платить вечно горящим стулом не понятно), через утку чуть менее 30 секунд, синхронизация через браузер около 5 минут, соответственно по мониторингу видно скорость запуска процессов и нагрузку на БД и апач, ссд под системой конечно бы не помешал. Думаю надо все же попробовать ngnix с его хваленой многопоточной структурой. В любом случае это практичнее чем мешать на сервере разные хранилища. Остается открыт вопрос. Стоит ли заморачиваться насчет ФС под БД основываясь на этом тесте в SQlite d chfdytybb ext3 b ext4 http://zenux.ru/articles/2/

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

Можно конечно сильно увеличить производительность для твоего случая отключив синхронную запись mysql, но сам понимаешь, в случае какого-нибудь сбоя есть шанс потерять всю бд. Если в клауде будут шары и более одного юзера, то это будет реальная потеря потерь.

Конечно это фаталити, на одном англоязычном ресурсе описывали случай когда просто после перезагрузки все данные были утеряны после такой «оптимизации». На сервак полетят в единичном варианте фоточки детей ссущих под стол и документы довольно значительного уровня (однажды лицезрел истерику жены когда сыночка удалил пару папок чтобы варфейс поставить, хорошо тогда интернет слабенький был успел остановить установку и большинство документов восстановил), ну собсна кк и у родственников , к сборке сервака и сподвигло осознание что на древних лежащих на полках хардах просрать все и навсегда вполне реальная перспективка, а вот облакам с белогривыми лошадками совсем доверия нет, а-ля ноукоммент. До сих пор интересует этот вопрос, насчет ФС, стоит ли запариваться и пересобрать систему с нуля на ехт3 или-же это все мертвому коню вакцина и стоит упираться в надежность ? Батлы ext3 vs ext4 до сих пор не утихают... http://zenux.ru/articles/2/

Сами файлы не потеряются при повреждении базы. На ext4 ни разу не ловил проблем, вот на ext3 было дело при внезапной потере питания.
Настоятельно рекомендую опции монтирования фс оставить по дефолту, кроме noatime.
upd:со времен появления этой статьи 10 лет прошло.

У самбы свои юзеры, а у системы свои. Если правильно помню то некстклауд требует юзера веб-сервера, и их надо мапить друг на друга, плюс прикручивать скрипт пересканирования хранилища, либо по событию, либо по таймеру. У консольной версии есть опция аля рсинк, копируем локальную папку в папку на некстклауде, но я не пользовался таким способом.

Небольшой отчет и итог. Провел небольшой простенький тюнинг БД, небольшой риск есть конечно, но, думаю, оно того стоит. Скорость записи увеличилась практически в 2 раза. Та же папка залетает через утку за 16 секунд (после 30 в стоке), через виндопроводник за 1:50 (против 3 минут). Как вариант ставить NetDrive2 (его можно закейгенить да и в триале он вполне работоспособен с 1 диском) - имеет такой же вид сетевого диска, закачка средняя - около 1 минуты. Всякие морковки и тотал коммандеры и прочий шлак не стоит того чтобы их устанавливать, скорости посредственные, а дополнительный интерфейс не нужен. Вывод. Как и подозревал, действительно на скорость записи NC очень влияет база данных в сравнении с прямым методом записи через FTP/samba/ssh , небольшой тюнинг конечно необходим, хоть и не доведет скорости до идеала, но поможет прилично. И конечно ССД под базу еще больше ускорит работу с файлами. Для себя определился - закачку основных массивов из дома на сервер буду делать через кибер утку,как максимально быстрое приложение, а доступ с других компов через сетевой диск или браузер, это кому будет как удобнее. Единственный вопрос - насчет циферки 2, насколько критично отдать сохранение кэша на волю ОС... Ну и сам тюнинг сет, для тех кто с тетрадкой :D innodb_buffer_pool_size = 1G innodb_log_file_size = 256M innodb_flush_log_at_trx_commit = 2 <=== innodb_flush_method = O_DIRECT

Мхм, включить сброс лога через кэш оси. Записал. Спасибо.

Жаль, не нахожу нигде сравнений некстклауда на апаче с мускулем, на нжинксе с мускулем, на апаче с постгресом и на нжинксе с постгресом. Неужели никто не проводил прямого сравнения?

Глянь raidrive под винду. Не требуется кейгенить (бесплатно до 8 одновременно подключенных дисков). Мб по скорости будет не хуже.

Спасибо, неплохое приложение, но.. увы.. 41 секунда, за уткой не угнаться :D, и конечно не в сравнении с нетдрайвом и тем более встроенным в венду хламом. Как повседневное решение в виде сетевого диска идеально. Как же все таки алгоритм действий создает пропасть между приложениями для одних и тех-же задач.

Тут https://www.techandme.se/we-migrated-to-postgresql/ народ переполз с мускуля на постгрес и остался довольным. Кто-нибудь еще пробовал постгрес для некстклауда?

Это я видел. Стаааарое. С того времени Постгресс апнули несколько раз, да и Машка на месте не стояла. И у них основная претензия там в поддержке utf8.

Хотя, все эти технологии так достают, что ты уже рад, что просто запустил Некстклауд и он даже коннектится по https. Какое там сравнивать, лишь бы не падало :)

У меня похожая ситуация с тормозами и бОльшим количеством файлов, да и ввобще с «хранением хозяйства» как таковым.
Пришел к следующему:

1. Объективно глядя, 90% файлов мне не нужны для юзания каждый день через модное «облако», поэтому неактуальные данные пакуются в архиве (zip/tar), например что-то древнее.
   Файло при необходмости легко извлекается.

2. Отказался от сказочного рейда.
   Заменил его на «холодный бекап», то есть регулярный слив инфы на отдельный диск, который не подключен к серваку.
   Писал тут - https://www.ixbt.com/live/romanram/nas-raid-vs-holodnoe-hranilische-vnutri-nasa-chast-1.html
   Если рейд рассыпится, то моих (линукс) комптенций не хватет его собрать, уж лучше бекап.

3. Делаю еще бекап на отдельный диск 1 раз в год.
   У меня диски летели… 3 раза, поэтому я делаю бекапы.
   Фоточки 1 раз в год пишу на DVD диски.

Я тоже слез с марии на пострес и доволен. Слез именно из-за тормозов.

Майскл блокировочник, а постгрес - версионник. Наверное из-за этого такая разница. Но я в субд не шарю.