Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000485 [Sphinx] general major always 2010-03-03 21:37 2010-08-31 20:24
Reporter Markus View Status public  
Assigned To tomat
Priority normal Resolution fixed  
Status resolved   Product Version 0.9.9-rc2
Summary 0000485: Wrong (additional) results when rotating
Description Its actually sphinx 0.9.9-release (r2117)

I have two indices (main and delta). Now, as documents become added, I run an "indexer --rotate delta". Search is done over both indices.

Now I sometimes get results which actually are none. They are not related at all. But most wrong results have a id (auto inc in mysql) close together.

I noticed it, because I have a rss feed to check for new results and my reader is archiving all results.
Knowing this I made script, always doing the same query and waiting for a change in the results. And so I got this example:

ids ok: 62192152, 61614749, 61169581, 60865306, 57267807

wrong additional ids in one search:
63297709, 63297710, 63297711, 63297712, 63297713,
63297721,
63297733,
63297779, 63297780, 63297781, 63297782, 63297783, 63297784,
63297714, 63297715, 63297716, 63297717, 63297718

Database and index is far too big to upload. But it should be reproduceable with smaller datasets.
Additional Information
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0000761)
tomat (manager)
2010-06-01 11:48

Could you post smaller dataset which causes this issue?
(0000804)
maser (reporter)
2010-07-16 16:11

We have run into the same issue. Our customers are complaining about unrelated results. After examining the problem I found out that the unrelated results are always returned during index rotation. I have tried disabling seamless rotation with no success.

I will try to reproduce the problem with a smaller database and upload the data.
(0000805)
Markus (reporter)
2010-07-16 18:03

I tried to build a smaller dataset with the problem. But I wasn't successfull.

The data has bigint indices, but the max index would still fit in a 32-bit signed int. The system is 64 bit.

The problem seems to be when the index gets rotated. searchd removes the old index and inserts the new one. And in between it somehow searches the index.
(0000806)
maser (reporter)
2010-07-16 18:56

That is why I tried using seamless_rotate = 0. It says in the documentation that searchd waits for all running queries to finish and stops accepting new connections, but although I had dozens of "server maxed out" responses, I still got wrong results.

Could this be a synchronization problem between the parent searchd process and its children?

If anyone can give me any advice on what information I can provide to help solve this issue, I would be very grateful. I will still try to create a dataset with which the problem can be reproduced, but I find it hard enough to reproduce it on our production system (without continually querying Sphinx for half an hour anyways).
(0000848)
maser (reporter)
2010-08-31 15:26

setting preopen = 1 solved this for us

- Issue History
Date Modified Username Field Change
2010-03-03 21:37 Markus New Issue
2010-06-01 11:48 tomat Note Added: 0000761
2010-06-01 11:48 tomat Assigned To => tomat
2010-06-01 11:48 tomat Status new => assigned
2010-06-01 11:48 tomat Resolution open => unable to reproduce
2010-07-16 15:57 maser Issue Monitored: maser
2010-07-16 16:11 maser Note Added: 0000804
2010-07-16 18:03 Markus Note Added: 0000805
2010-07-16 18:56 maser Note Added: 0000806
2010-08-31 15:26 maser Note Added: 0000848
2010-08-31 20:24 tomat Reproducibility sometimes => always
2010-08-31 20:24 tomat Status assigned => resolved
2010-08-31 20:24 tomat Resolution unable to reproduce => fixed


Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker