It seems that this is not limited to Maniphest, it applies to all search documents.

I applied the following change locally. I'm not convinced that it is the most correct solution, but it seems to have worked for our install:

Comparing the mappings before and after (with curl 'http://localhost:9200/phabricator/_mappings?pretty=true'):

I've made some small progress here.

I set this up recently and can probably flesh out some documentation.

Can you tell me the configuration setup that you guys are using:
OS, core#, memory (size, speed), SSD, php, mysql?

I don't know if it's worth noting, but Ubuntu 10.04 was end of life'd last month (it's 5 years old). What versions of PHP/MySQL are you running on it?

2 minute delays between prints.
Maybe an incorrect assessment, but I see there is a direct relationship to the my.conf vs how much mem/swap is used once I start phd; but always max CPU and obviously this impacts severely apache browsing and conduit api response

Where are the two-second delays occurring? Everything in that trace looks like it happens in no more than a few milliseconds.

git pull

remote: Counting objects: 19, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 19 (delta 15), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (19/19), done.
From git://github.com/facebook/libphutil
   4e0febf..672c0f7  master     -> origin/master
Updating 4e0febf..672c0f7
Fast-forward
 .arcconfig                                    | 1 -
 src/daemon/PhutilDaemon.php                   | 5 +++--
 src/daemon/PhutilDaemonHandle.php             | 7 +++++--
 src/future/exec/CommandException.php          | 2 +-
 src/moduleutils/PhutilLibraryMapBuilder.php   | 4 ++--
 src/serviceprofiler/PhutilServiceProfiler.php | 4 ++--
 6 files changed, 13 insertions(+), 10 deletions(-)

Can you update libphutil and retry that? The duration printouts are bugged until rPHU65819efa.

Can you run bin/phd debug taskmaster for a minute or so and show me the output?

I did the following:
/bin/phd stop

These numbers are wildly out of line with expectations. For comparison, I just ran a similar workload on this machine:

@epriestley , so is their a way to provide special configurartion ? Can you give me some basic hints ?

Thanks @fabe.
I resolved that issue after search init and change mysql config ( STRICT option ).
It works well but I found T6892.

just run

./bin/search init

first.
This will create the needed elasticsearch index.

Thank you for your answer. But I met this error message.
after "search index --all"

[HTTP/404] Not Found
{"error":"IndexMissingException[[phabricator] missing]","status":404}

Is it need more configuration for this?

https://secure.phabricator.com/T5282#62676

Is there a temporary way to resolve this issue? ( Just only for wiki search )

Presuming resolved by D10955, yell if I missed something or there's some followup.

Closed by commit rPc953c0fedc17.

Yeah, this is specific to ElasticSearch -- exact phrase search works on this install with the MySQL backend T6747.

One way of doing this is by adjusting the mapping for the elasticsearch index (actually way more powerful than a wildcard search).
I currently switched to the mapping below (added as a template expecting the index to be named 'phabricator' and with an english language setting).
Feel free to change the min/max ngrams setting (e.g. 4 instead of 3 letter ngrams) if you get too many / few results.
If you like to switch to another language the docs to do so are here: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/analysis-lang-analyzer.html
For it to take effect you have to delete the index and then reindex all objects (bin/index --all).

(I would like this tooooo)