StaticDB: удручающая производительность при поиске

[storm]

Установил недавно новый архивный сервер на который будут переливаться тикиты за прошлые годы.
Версия OTRS 2.4.9. Чистая установка с переливом дампа со старого архивного сервера, а также дампа с "REPLACE INTO" с промышленного.

Зашел значит в [ Support Assessment ] а там очень много красных ошибок и предупреждений. Некоторые из которых касались использования StaticDB.
Убрал я почти все ошибки и перевел OTRS на StaticDB. После перестроил индексы.
Менял следующие параметры:

Код: Выделить всё

Core::Ticket - Ticket::IndexModule: StaticDB

После изменения перестроил индексы запустив файл bin/RebuildTicketIndex.pl

Код: Выделить всё

Core::Ticket - Ticket::StorageModule: ArticleStorageFS

(на промышленном и так используется)

Код: Выделить всё

Core::FulltextSearch - Ticket::SearchIndexModule: StaticDB

После перестроил индексы запустив файл bin/otrs.RebuildFulltextIndex.pl. Индексы перестраивались очень долго.

Результат манипуляций выше - отвалился поиск по тикитам - забиваю слово test в поле subject и висит запрос минуту, две и ничего.
На изначальном архивном сервере где OTRS вопит мол слелайте мне хорошо - используйте StaticDB, и где я ингорю эти просьбы все ищется более-менее быстро.

Вот и вопрос собственно. Отчего не работает поиск?

И какой профит от использования StaticDB? Документация естественно описывает, что необходимо использовать именно StaticDB при огромном колличестве тикитов. Но вот запустил значит я тест производительности с RuntimeDB и StaticDB:

Код: Выделить всё

# RuntimeDB
Ключ 	Значення 	Час 	Коментар
Insert Time: 	50000 	5 s -:-) 	Looks fine!
Update Time: 	50000 	16 s -:-) 	Looks fine!
Select Time: 	50000 	18 s -:-) 	Looks fine!
Delete Time: 	50000 	14 s -:-) 	Looks fine!
Multiplier: 	* 5 	

Код: Выделить всё

# StaticDB
Key 	Value 	Time 	Comment
Insert Time: 	50000 	6 s -:-) 	Looks fine!
Update Time: 	50000 	16 s -:-) 	Looks fine!
Select Time: 	50000 	23 s -:-) 	Looks fine!
Delete Time: 	50000 	22 s -:-| 	Ok
Multiplier: 	* 5 	

[storm]

Вообщем проблема наблюдаются только с полнотекстовым поиском. Обычный работает нормально. Полнотекстовый же тупит минут 5-10 и после выводит результат.
При поиске если заглянуть в консоль mysql, то можем наблюдать запрос со статусом

Код: Выделить всё

Copying to tmp table

Если запрос на полнотекстовый поиск повторить, то результат выводит буквально за несколько секунд.

Значит я увеличивал такие параметры mysql
# Временные таблицы
max_heap_table_size=256M
tmp_table_size=256M

Но результата это не дало.
Да и памяти на сервере не так много как хотелось

Код: Выделить всё

[root@otrs-old-new mysql]# free -m
             total       used       free     shared    buffers     cached
Mem:          3038       2944         93          0          6       2277
-/+ buffers/cache:        660       2377
Swap:         1023         15       1008

Да и ОС 32-bit

Какие будут предложения как же ускорить полнотекстовый поиск?

[storm]

Случайно нашел свою старую тему
Вообщем там была проблема то ли с HDD, то ли с RAID.
Вот давеча юзал полнотекстовый поиск на StaticDB на 100 тыс. тикитов. Время поиска пара секунд.

[alexus]

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