Решение найдено! После многих тестов, смен БД я наконец то нашел причину долгого поиска. Проблема была действительно в БД., а точнее напишу чуть ниже. Включив логирование медленных запросов
SET GLOBAL slow_query_log=1; я отследил какой запрос формируется через веб поиск
SELECT `filecache`.`fileid`, `storage`, `path`, `path_hash`, `filecache`.`parent`, `name`, `mimetype`, `mimepart`, `size`, `mtime`, `storage_mtime`, `encrypted`, `etag`, `permissions`, `checksum`, `metadata_etag`, `creation_time`, `upload_time` FROM `oc_filecache` `filecache` LEFT JOIN `oc_filecache_extended` `fe` ON `filecache`.`fileid` = `fe`.`fileid` WHERE (`storage` = 2) AND (`name` COLLATE utf8mb4_general_ci LIKE '%namefile%');
выполнив этот запрос непосредственно в консоли mysql я убедился, что запрос также выполняется около минуты, это сразу сняло подозрения на всевозможные домыслы в сторону проблем веб интерфейса, ранее когда я писал что через консоль бд я делал запрос и он выполнялся за доли секунды, то я оформил абсолютно не верный запрос, не такой какой формируется самой системой через веб поиск, это и сбило меня столку.
немного погуглив я познакомился с параметром
mysql> SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.01 sec)
mysql>
он дает представление от том какой размер памяти выделяется для хранения данных и индексов таблиц.
134217728 это значение равное
128 Мб. Логично предположить для того чтобы выделить достаточное кол-во памяти для хранения данных и индексов таблиц надо знать сколько эти данные занимают места, для этого выполним команду
mysql> SELECT table_schema "nextcloud",
-> Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
-> FROM information_schema.tables
-> GROUP BY table_schema;
+--------------------+---------------+
| nextcloud | DB Size in MB |
+--------------------+---------------+
| information_schema | 0.2 |
| mysql | 0.8 |
| nextcloud | 415.6 |
| performance_schema | 0.0 |
| sys | 0.0 |
+--------------------+---------------+
5 rows in set (0.13 sec)
Где видно что уже занято
415 Мб, соответственно нам надо задать параметр
innodb_buffer_pool_size более того что занимает у нас БД, к примеру дадим
1 Гб
mysql> SET GLOBAL innodb_buffer_pool_size=1073741824;
Query OK, 0 rows affected (0.00 sec)
Проверим изменился ли параметр
mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
| 1073741824 |
+---------------------------+
1 row in set (0.00 sec)
Теперь идем в веб интерфейс и обновляем страницу и проверяем поиск. И конечно убеждаемся что все ищется очень быстро.
Все конечно хорошо , но после перезагрузки сервера наши изменения по параметру
innodb_buffer_pool_size не сохранятся так как в snap версии не редактируется конфигурационный файл БД
/snap/nextcloud/current/my.cnf вот этот файл и он только для чтения
Как его поправить я пока не знаю, пишите если знаете.
PS. chmod не рабоатет. Я так понимаю nextcloud монтирует какой то раздел вместе с этим фалом только для чтения.
прошлые рассуждения в поиске решения проблемыСпасибо, но я так понимаю это инструмент для поиска внутри файлов текстовой информации, если в настройках есть сканирование имен файлов, то это возможно поможет, отпишусь. Сейчас пробую запустить NextCloud на БД Postgresql, хочу посмотреть результат времени поиска стандартным инструментом, отпишусь.
Кстати отключение hyper threading в CPU увеличило время поиска всего 05 секунд :(
Пока незнаю точно о чем это может говорить, но есть предположение что смена CPU на более производительный не сильно поможет решении проблемы, всё-таки лишившись двух потоков из четырех время поиска практически не изменилось. Хотя надо все тестировать..
Сложный
Простой
Простой
