Производительность создание/сохранение документов

[lmike]

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

предположим вариант - на нужно 100000 доков, а потом и сохранить в них изменения
варианты действий (гипотетически):
- создаем их локально (может быстрее, чем по сети, если комп "достаточный")
- неким образом отправляем их на сервер (вот тут вопрос)
- форму не задаем! - чтобы избежать активного участия индексера, на этот момент
- а вот потом

Ссылка скрыта от гостей

поля формы

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

 

[Мыш]

lmike, немного не в тему, но... А если просто запретить индексирование базы?
Я тут игрался с этой опцией - запретил индексирование на почтовых базах пользователей, индексы перестраиваю периодически с помощью DBMT. Из пользователей никто пока не жаловался.
Точной статистики у меня нет, но sar стал показывать более низкую среднюю нагрузку на диски. Естественно, она (нагрузка) возрастает в момент работы DBMT - ну чудес не бывает. Зато это периодические всплески, а не "среднее торможение".
ЗЫ. По-моему, индексер при N-ых объемах данных тупо перестает справляться.

 

[ToxaRat]

я правильно понял, пока есть "очередь изменени" индексер может успеть пару раз "чихнуть"

ну дык - пусть это делает агент на сервере "локально" индексер как раз когда в очередь встанет агент закончит

 

[lmike]

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

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

 

[ToxaRat]

мне тоже интересно как ведёт себя индексер
так как есть базы где индекс одного только вида под 4 гига

и вот тут я напоролся на конфликт рекомендаций от ИБМ редбука - где требуется по одному индексеру процессу на ядро - на сервере 8 ядер
в базе несколько лямов доков

когда агенты начинают что-то делать индексеры просто рвут очередь чтения/запись...