Ftbasepath На 8.5.3

[rinsk]

ну а настройки сервера:
дока - начните с AI - там дальше будет пояснение что откуда и куда

AI при настройке сервера вообще не в кассу. Это некие попугаи - отраженные в цифирях, которые не поддаются наморщенному сознанию.
Единственное предназначение этих попугаев - сравнение межсобой строго одинаковых N серверов в кластере и подбор 2-х параметров в ини для балансировки нагрузки.

 

[ToxaRat]

AI при настройке сервера вообще не в кассу. Это некие попугаи - отраженные в цифирях, которые не поддаются наморщенному сознанию.
Единственное предназначение этих попугаев - сравнение межсобой строго одинаковых N серверов в кластере и подбор 2-х параметров в ини для балансировки нагрузки.

когда АИ равено 0 как-то даже чувствуется физически как он тормозит

Добавлено:

А вы думаете нету? Напомню, что речь про индексы видов и кеширование тут тоже ни при чем.

а тут от первоночальной ситуации зависит

Пример 1 - одна база и 100 юзеров мало изменений
один пересохранил док
один раз дернулся индексер
всё у всех открывается быстро так как кешь

Пример 2 - 100 баз и 100 юзеров
каждый пересохранил док
100 раз дернулся индексер
всё у все еле открывается так как индексеров в потоке только 2

Пример 3 - 10 баз, 100 юзеров
каждый пересохранил док
10 раз дернулся индексер
всё у всех в общем-то открылось


чувствуете разницу от количества задач, настроек сервера, и правильного затачивания?

 

[am4]

когда АИ равено 0 как-то даже чувствуется физически как он тормозит

Добавлено:
а тут от первоночальной ситуации зависит

Пример 1 - одна база и 100 юзеров мало изменений
один пересохранил док
один раз дернулся индексер
всё у всех открывается быстро так как кешь

Пример 2 - 100 баз и 100 юзеров
каждый пересохранил док
100 раз дернулся индексер
всё у все еле открывается так как индексеров в потоке только 2

Пример 3 - 10 баз, 100 юзеров
каждый пересохранил док
10 раз дернулся индексер
всё у всех в общем-то открылось


чувствуете разницу от количества задач, настроек сервера, и правильного затачивания?

Речь про:
Пример 4 - N баз >100к документов и M*100 активных пользователей, каждый из которых постоянно пересохраняет доки.
Индексер (-ы) дергается в предсмертных конвульсиях, и ничем ему уже не помочь Единственный вариант - вынос индексов видов за пределы баз на отдельный быстрый раздел.

А еще интересный пример 5 (про оптимизацию и приоритет индексера) - база >100к документов, N х 10 Гб. Убиваем индексы видов (new copy например), открываем на клиенте:
- использование ресурсов на сервере и на клиенте <1%
- клиент N минут открывает вид
- где индексер, за пивом пошел?

 

[ToxaRat]

Речь про:
Пример 4 - N баз >100к документов и M*100 активных пользователей, каждый из которых постоянно пересохраняет доки.
Индексер (-ы) дергается в предсмертных конвульсиях, и ничем ему уже не помочь Единственный вариант - вынос индексов видов за пределы баз на отдельный быстрый раздел.

то есть вы предлагаете сохранять изменения уже не на одном диске а на двух одновременно?

напомню процесс:
1) сохранение в ТЛ
2) сохранение в доке
3) перестройка индекса вида с сохранением в таблицы(вид) для юзера

если это "разнести" то получится что для "перестройки индекса" (а это по сути таблицы данных для юзера) нужно будет для записи в эти таблицы тоже создавать отдельный ТЛ, который к тому же будет как кластер постоянно реплицироваться с обычным ТЛ

не, задача конечно интересная, но я пока никак не вижу, чтобы это помогло ускорить конечный процесс

а вот элементарно 4-N базы разнести по разным дискам - замапить папки-базы определенно ускорит работу в 4-N раза - и это чисто настройка сервера

 

[ToxaRat]

объяснюсь, если я вдруг очень груб

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

а ведь это элементарное слабоумие админа или внедренца:
1) разнести системы на разные сервера
2) разнести диски
3) разнести сеть
4) отсутствие вменяемых требований от разработчиков
5) отсутствие инструкций по оптимизации
6) отсутствие визардов по диагностике
......


и как следствие обидно за что, что лотус чмырят

 

[rinsk]

не, задача конечно интересная, но я пока никак не вижу, чтобы это помогло ускорить конечный процесс

Очень просто - снизить конкурентную запись в файл.

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

 

[ToxaRat]

кстати благодаря этой дискуссии натолкнулся на интересную мысль, что порой применение Ftbasepath вредно

Пример:
у добропорядочного админа сохранилась база - динозавр - что-то старое, медленное, тяжелое но не сдохла
он, дабы его сервер слишком глубоко не проседал от этой базы и её фтпоиска подцепил рейдик чисто под неё
заметете так как он перенес базу с папкой то и фтиндекс тоже перенесся на этот рейд - чем способствовал улучшению работы всех других баз

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

не так весело получается как задумывалось