Крошится на сервере, на сервере.
Linux Centos 7 / 16G / E-2236 CPU 12 cores
Как только разделю индекс на 2 и более, то crashed SphinxQL:
index dist_test
{
type = distributed
local = chunk1
local = chunk2
local = chunk3
local = chunk4
}
searchd
{
dist_threads = 4
}
ИЛИ делаю FROM myindex,myindex2:
SELECT * FROM myindex,myindex2 WHERE id IN (1,23,22…334,5677) GROUP 100
by collection WITHIN GROUP BY ORDER by price ASC
order by price ASC
Без разделения индекса работает стабильно!
Предполагаю что это настойка OS или Nginx, т.к. sphinx и manticoresearch падают, с той разницей что manticoresearch restarted , а sphinx отваливается или “502 Bad Gateway”.
Какие настойки или ограничения OS или Nginx могут влиять на работу manticoresearch ?
— crashed SphinxQL request dump —
SELECT id,title,kolecia,vendor,h,g,w,d,di,price,price_old,art,nal,baza,date,top100,
pak,foto,ff,c,la,kolecia_ost_karta,kolecia_ost_count,categories FROM products1
where id>0 AND categories = 456 AND opcii IN (432) AND id>0
GROUP 550 BY vendor,kolecia WITHIN GROUP ORDER BY price ASC ORDER BY price
ASC LIMIT 40,40 option max_matches = 120,sort_method=kbuffer, ranker=none
— request dump end —
— local index:products1
Manticore 3.4.2 6903305@200410 release
Handling signal 6
-------------- backtrace begins here ---------------
Program compiled with 4.8.5
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=rhel7 -DUSE_SSL=ON -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.2 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.18 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DLOCALDATADIR=/var/data -DFULL_SHARE_DIR=/usr/share/manticore -DUSE_ICU=1 -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=1 -DWITH_ICONV=ON -DWITH_MYSQL=1 -DWITH_ODBC=ON -DWITH_PGSQL=1 -DWITH_RE2=1 -DWITH_STEMMER=1 -DWITH_ZLIB=ON -DGALERA_SOVERSION=31 -DSYSCONFDIR=/etc/manticoresearch
Host OS is Linux runner-ed2dce3a-project-3858465-concurrent-0 4.19.78-coreos #1 SMP Mon Oct 14 22:56:39 -00 2019 x86_64 x86_64 x86_64 GNU/Linux
Stack bottom = 0x7f2ae35fad7f, thread stack size = 0x100000
Trying manual backtrace:
Something wrong with thread stack, manual backtrace may be incorrect (fp=0x9)
Wrong stack limit or frame pointer, manual backtrace failed (fp=0x9, stack=0x7f2ae3600000, stacksize=0x100000)
Trying system backtrace:
begin of system symbols:
/var/www/domen/data/manticore/bin/searchd(_Z12sphBacktraceib+0x90)[0x710e50]
/var/www/domen/data/manticore/bin/searchd(_ZN16SphCrashLogger_c11HandleCrashEi+0x1fe)[0x58409e]
/lib64/libpthread.so.0(+0xf5f0)[0x7f2af7e015f0]
/lib64/libc.so.6(gsignal+0x37)[0x7f2af6548337]
/lib64/libc.so.6(abort+0x148)[0x7f2af6549a28]
/lib64/libc.so.6(+0x78e87)[0x7f2af658ae87]
/lib64/libc.so.6(+0x81679)[0x7f2af6593679]
/var/www/domen/data/manticore/bin/searchd(_ZN23CSphKBufferNGroupSorterI16MatchGeneric2_fnLb0ELb0EE7FlattenEP9CSphMatchi+0x213)[0x7c6573]
/var/www/domen/data/manticore/bin/searchd(_Z15sphFlattenQueueP15ISphMatchSorterP15CSphQueryResulti+0x8e)[0x71db6e]
/var/www/domen/data/manticore/bin/searchd[0x5afad2]
/var/www/domen/data/manticore/bin/searchd(_ZN15SearchHandler_c16RunLocalSearchesEv+0xb07)[0x5bc917]
/var/www/domen/data/manticore/bin/searchd(_ZN15SearchHandler_c9RunSubsetEii+0xca7)[0x5ced77]
/var/www/domen/data/manticore/bin/searchd(_ZN15SearchHandler_c10RunQueriesEv+0xb5)[0x5cfaf5]
/var/www/domen/data/manticore/bin/searchd(_Z17HandleMysqlSelectR11RowBuffer_iR15SearchHandler_c+0x1b0)[0x5d0180]
/var/www/domen/data/manticore/bin/searchd(_ZN16CSphinxqlSession7ExecuteERK10CSphStringR11RowBuffer_iRN7Threads9ThdDesc_tE+0x1411)[0x5f45c1]
/var/www/domen/data/manticore/bin/searchd(_Z15LoopClientMySQLRhR16CSphinxqlSessionR10CSphStringibRN7Threads9ThdDesc_tER13InputBuffer_cR16ISphOutputBuffer+0x322)[0x5d1022]
/var/www/domen/data/manticore/bin/searchd(_ZN10ThdJobQL_t4CallEv+0x25f)[0x65af8f]
/var/www/domen/data/manticore/bin/searchd(_ZN11CSphThdPool4TickEPv+0xa0)[0x719270]
/var/www/domen/data/manticore/bin/searchd(_Z20sphThreadProcWrapperPv+0x23)[0x7149d3]
/lib64/libpthread.so.0(+0x7e65)[0x7f2af7df9e65]
/lib64/libc.so.6(clone+0x6d)[0x7f2af661088d]
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (Issues · manticoresoftware/manticoresearch · GitHub)
and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter ‘Reporting bugs’ in the documentation
(Manticore Search Manual: Reporting bugs)
Dump with GDB via watchdog
[Fri Apr 17 14:17:13.979 2020] [2347] watchdog: got USR1, performing dump of child’s stack
Will run gdb on ‘/var/www/domen/data/manticore/bin/searchd’, pid ‘17622’
— 1 active threads —
thd 0, proto sphinxql, state query, command select
Решено!
Проблема была в запросе и именно только в type = distributed
SELECT * FROM myindex WHERE id IN (1,2,3,4,5…500) GROUP 100
by collection WITHIN GROUP BY ORDER by price ASC
order by price ASC max_matches = 120,sort_method=kbuffer, ranker=none
Запрос получал данные в id IN 500 айдишников.
Если в max_matches = 120 то CRASH
Если max_matches = 500 по числу входящих id, то работает
лучше было бы создать тикет в GitHub где приложить запрос который вызывает креш и стек с крешем, а так же залить на наш FTP данные индексов на которых можно повторить этот креш локально
В следующий раз выложу, пока тестирую manticoresearch еще на одном проекте.
На проекте где была ошибка сделал следующие выводы:
type = distributed при маленьком индексе, а у меня всего 300К товаров + 4М attributes
распределительный поиск не принес прирост скорости, а наоборот увеличилось время отдачи, пробовал dist_threads от 2 до 12.
Так же пока остался на Sphinx 2.2.11-release т.к. в моем случаи Sphinx 2.2.11 работает быстрее на 20-30%, и потребляет в 2 раза меньше памяти.
Я использую manticoresearch и Sphinx только в фильтре товаров и выдача с группировками и очень мало MATCH()
Можете показать ls -la индексов и кусок из query log’а, чтоб понять на каких запросах Мантикор медленнее? И насколько холодные/прогретые были Manticore/Sphinx при тестах?